Re: Eu 4.2.0 Beta?
- Posted by ghaberek (admin) Jun 17, 2022
- 758 views
The ability to set constants in routines rather than only variables.
Constants in routines, like this:
procedure foobar() constant FOOBAR = 1234 end procedure
Or constant routines, like this:
constant function foobar() atom some_value = 42 return some_value -- cannot be modified by the caller end function
I can see both being useful, especially the latter for use with classes.
exceptions
This shouldn't be hard to do in the interpreter. The harder part would be emulating this behavior in translated code with setjmp and longjmp.
full classes
Agreed. I've looked at Matt's OOEU a few times and he's handling everything in the front end. Once we get 4.2 out the door I'd like to work on merging in his changes and then building on it from there.
operator overloading (need classes for this)
Operators are already implemented as functions in the back end, so overriding them seems like it could be pretty straight-forward. Question is, as usual, how to handle that in translated code?
From operator overloading, comes the ability to create huge integers for cryptography. I don't know if anyone around here really has the inclination and ability to introduce these features to Euphoria.
Yes I think operator overloading has a lot of potential for adding new features in and of itself.
delete should be something that not only calls the destructor but takes the passed variable out of scope at the point in the routine it is called.
Right now delete() is handled by the back end, and if you try to access the value at runtime it will be NOVALUE and that will cause an error and crash. The front end could hide the symbol when delete() is called but it'd be hiding the symbol from itself, so further assignments would also fail unless more scanning was done to look ahead for future assignments. A good middle ground might be to issue a warning about potential "use after delete" or something.
an interpreter that wont mess up when I modify the length of a sequence I am iterating over. I get an index error if I remove an element.
I think a "for each" loop might help alleviate this restriction. But in this case I'd use a while loop with my own counter. I use this approach a lot when writing parsers.
a redo which re-iterates a for loop without incrementing the variable, but in the while with entry loop goes to the entry clause. Between the condition of the loop and the entry clause is invariably where the loop sets up the next iteration. Like line is read, or match is called again.
I think these kinds of complex loop constructs are better left to just using while and continue and handling the counters and other variables manually. I don't think there's a good "one size fits all" approach here.
I would like to see 'for (x of s)' like loops from Javascript ( not the syntax but the ability to just get the s[i] in a variable rather than i.
Yes, definitely. I was thinking it would be for item in list do where item is an object that lives for the scope of the loop and list has to be a sequence.
statements like b += func(), where func() sets b should throw an error rather than overriding changes of the variable b as the language does now. I'd love someone to convince me why this is a good idea. It is not obvious without understanding the front-end code to some degree, but a lot of effort was put in to make this work consistently this way
I was unaware this behavior existing. I'm curious so I'll dig into it at some point so I can at least understand how it works today.
no more destructors on atoms. It was a misconceived idea which had to be implemented before we realized what problems would be introduced. Internally, the interpreter is designed to convert atoms which are implemented as pointers to structs, which could contain a destructor now, to an atom represented as a C integer, which can only represent a value of an integer. This means innocent looking code can often close your file handle before you can use it. (https://openeuphoria.org/ticket/937.wc)
Nooo not my atom destructors! Do you have any idea how often I use the cleanup option with allocate_string()? It's like... a lot. One of the best features of Euphoria IMHO. Is there anything inherently wrong with storing an integer value in a floating-point that can accommodate its size? I mean sure, there's a lot of typecasting going on in the back end to accommodate this. Could the integer value ever get mangled?
atom x = open("foo.txt", "w", 1) -- x is an atom because it has a destructor. x has no fraction part so it should be an integer.
I propose we make open return a sequence when returning with a destructor with the file handle being the first element. The sequence can contain the destructor.
Perhaps this is something to revisit when we start to implement classes. If, for example, all class-declared objects are sequences underneath, then the file handle would be stored in the object and close() would be called via the class destructor. Then we could remove atom destructors later. Otherwise I think what you're proposing here adds too much complexity for the user and I think we all want to avoid that.
-Greg
