OpenEuphoria

2. Re: Promote Euphoria - MAKE A PAGE ON WIKIPEDIA

• Posted by petelomax Sep 10, 2020
• 1742 views
• Last edited Sep 13, 2020

What's this then?! (It is linked here)

UPDATE: There's also this, maybe that needs linking[ok, done that] and populating with a full translation.
UPDATE2: Added a request/link for update/translation.

However there is no page for Phix...

4. Re: Promote Euphoria - MAKE A PAGE ON WIKIPEDIA

• Posted by ghaberek (admin) Sep 13, 2020
• 1626 views

Wikipedia has rules against self-promotion and advertising, marketing, or public relations: https://en.wikipedia.org/wiki/Wikipedia:What_Wikipedia_is_not#PROMO

So the members of this community aren't really the best candidates for writing or maintaining Wikipedia articles about Euphoria. This should really be done only by a third party.

-Greg

6. Re: Promote Euphoria - MAKE A PAGE ON WIKIPEDIA

• Posted by SDPringle Sep 20, 2020
• 1397 views

A team that's motivated to contribute to a language should have a vision to what Euphoria is. What might be a good change for one developer would be a regression for another. Motivated developers need to first agree with a list of features. Then they can work as a team toward that goal. For me prior to Euphoria 4.0, EUPHORIA had always been and mostly still is:

• always well defined behavior. You'll wont find the phrase "undefined behavior" for anything apart from interfaces to machine language or C function calls.
• No special rules for differing number types. The 2.5 * 2 is identical to the integer 5.
• declare before use.
• a minimalist built-in declared type-system.
• types defined by run-time functions rather than declarative statements.
• pass-by-value semantics. (References are used internally but that is an implementation detail.)
• strict checking everywhere. Never should there ever be a crash without an ex.err file generated. Although not possible for calling C or machine code.
• words rather than punctuation
• no need for pointers and no pointers.
• characters are not length 1 strings.
• really good explanations for errors

Euphoria 4.1 brought us many flow control statements and other statements (most notably enum) that improves the user experience, but it also broke some of these things above.

There are some routines in the standard library which work around not having pointers. Imagine having to assign a map value to itself when you did a map put:

Instead of pass by value semantics like this

include std/map.e as map 
map:map p = map:new() 
p = map:put(p, 2, "two") 
p = map:put(p, 3, "three") 
p = map:put(p, 5, "five") 

We instead only need to type:

include std/map.e as map 
map:map p = map:new() 
map:put(p, 2, "two") 
map:put(p, 3, "three") 
map:put(p, 5, "five") 

Now p is one level removed from the user. p is not a map it's a reference value to a map. The standard library added a reference system. Pointers were not added to the language but added to a library. This breaks the slogan, Euphoria doesn't need pointers. Also, the user can't just save p to a file as if it's a EUPHORIA object with the data in it.

The way map works and a couple of others goes against the ethic that Euphoria doesn't need pointers. It turns out there are certain algorithms that need pointers. There are some involving binary trees. Though p is not a pointer, the value p is a handle like object. It is like something you would get from open(), yet it is a handle to data in your program rather than to a file. To me, this kind of thing is inconsistent with the way Euphoria was supposed to be. Yet at the same time I am thankful that I don't need to make assignment statements for each call.

Now ifdef is a regression in my view, because it puts EUPHORIA to where C is in terms of safety. If the compile time value doesn't exist, then the code inside the block is not even parsed for mispelt variable names. The advantages for this is speed, but C compile optimization makes this moot. I can still sympathize with the other side, but I have never been convinced of this.

There were other changes that violated "strict checking everywhere" in allowing functions to be called as if they were procedures, and changes to the behavior or length, and object.

8. Re: Promote Euphoria - MAKE A PAGE ON WIKIPEDIA

• Posted by petelomax Sep 20, 2020
• 1435 views

include std/map.e as map 
map:map p = map:new() 
map:put(p, 2, "two") 
map:put(p, 3, "three") 
map:put(p, 5, "five") 

Actually, they should really have been implemented as assignments, probably, eg:

map p = new_map() 
p[2] = "two" 
p[3] = "three" 
p[5] = "five" 

I put similar handling in for Phix structs, which works by spotting/substituting "attempt to subscript an integer" cases, but forgot/failed to do the same for dict/map...

(to nit-pick) More correctly speaking, Euphoria/Phix has copy-on-write semantics - apart from integers it always passes a reference, but automatically clones when needed should it have a reference count > 1.

Yep, mostly. However, binary_search() on an unordered haystack, and {s[idx],idx} = <expr> are two examples of undefined/unpredictable/unsupported outcomes.

Agreed. I half-get call-before-declare, but

s[1] = {1,2,3} 
string s 

and you have effectively just thrown away loads of opportunities for helpful compile-time messages, not to mention many potential optimisations, and any and all notions of variable scope going completely whack-a-doodle.

For me though, the real killer is Euphoria/Phix don't work in a web browser or have anything like codepen/jsFiddle/repl.it/tio so I'm now toying with some ideas for that (but....)
Actually, there is (almost but not quite) http://golf.shinh.org/l.rb?exu - the only thing I could find anyway.

10. Re: Promote Euphoria - MAKE A PAGE ON WIKIPEDIA

• Posted by SDPringle Sep 22, 2020
• 1301 views

What I meant earlier by Euphoria having "pass by value semantics", is that the way EUPHORIA passes parameters into routines is indistinguishable to pass by value barring time profiling or looking at the source code. I think I should have used the word "behavior" or "specification". There may be two implementations of some stack library and they may be implemented in different ways but it would still have this first in last out "behavior". Take what I said earlier to mean "observable behavior".

s[1] = {1,2,3} 
string s 

Maybe there are some special circumstances for this kind of thing with variables being declared after. It turns out this code gives an error:

include std/types.e 
s[1] = {1,2,3}  
cstring s  

The error is

<0074>:: Errors resolving the following references: 
    's' (wtf.ex:2) has not been declared. 
 
s[1] = {1,2,3} 
 ^ 

We probably do have different checkout revisions of Euphoria. It would surprise me if that wasn't the case.

As for the map example, there are all kinds of situations where the user needs to type in the same value twice because the true intention is to modify a value rather than assign a new value. I have some ideas for that. They all have the following properties.

• The modified object has to appear once in the expression.
• It must look different to a normal pass by value call.

The last thing I would like to see in EUPHORIA would be something like this:

-- Append is now pass by reference 
append(s, 5) 

These are some of my ideas

countries = append(countries, "Sweden") 
-- becomes 
countries.append("Sweden").   
-- or 
countries append="Sweden"