1. Eu 4.2.0 Beta?
- Posted by Icy_Viking Jun 12, 2022
- 1110 views
Hello all,
I was wondering if perhaps Euphoria 4.2.0 would be ready for beta testing anytime soon? That new struct feature would come in handy. I was also thinking about updating or making a new Win32lib type-ish wrapper.
2. Re: Eu 4.2.0 Beta?
- Posted by ghaberek (admin) Jun 13, 2022
- 1083 views
I was wondering if perhaps Euphoria 4.2.0 would be ready for beta testing anytime soon?
I've been working on some of the other features I detailed Roadmap to Euphoria 4.2, mainly zip files and hashes.
I can try to merge the struct branch into master with my keyword changes soon. I also need to get GitHub Actions publishing releases after it completes a build so that "beta" builds and whatnot are easier to download.
That new struct feature would come in handy. I was also thinking about updating or making a new Win32lib type-ish wrapper.
I definitely think structs will be very useful for interacting with a lot of things and I'm looking forward to an overhaul of Win32Lib.
-Greg
3. Re: Eu 4.2.0 Beta?
- Posted by petelomax Jun 14, 2022
- 1032 views
That new struct feature would come in handy. I was also thinking about updating or making a new Win32lib type-ish wrapper.
I definitely think structs will be very useful for interacting with a lot of things and I'm looking forward to an overhaul of Win32Lib.
I'll tell you what: for x in s do is pretty darn neat! I must admit I was a little sceptical and slightly concerned I'd made it too simple, but now that it's in [the internal development version of] Phix, I just can't seem to not use it!
Any new GUI should ideally at least try to be compatible with the CSS box model, by which I mean a little bit of CSS can mimic what happens on the desktop, as opposed to desktop parsing/implementing any form of CSS. In other words, express layout in terms of margin/border/padding, and/or flexbox-compatible, and avoid the use of specific pixel coordinates. Oh, and cross-platform, of course - I am toying with the idea of a new and minimalist GTK/kernel32 GUI wrapper myself, with an IUP-inspired (but not actually using IUP) simple attribute basis, the tricky part getting something to work atop GTK (initially/experimentally on Windows) but not (necessarily) actually looking anything like the underlying gtk function calls.
4. Re: Eu 4.2.0 Beta?
- Posted by ghaberek (admin) Jun 14, 2022
- 1001 views
I'll tell you what: for x in s do is pretty darn neat! I must admit I was a little sceptical and slightly concerned I'd made it too simple, but now that it's in [the internal development version of] Phix, I just can't seem to not use it!
Yeah I would really like to get this feature into Euphoria. Not sure if I can make it happen in 4.2 though.
-Greg
5. Re: Eu 4.2.0 Beta?
- Posted by Icy_Viking Jun 14, 2022
- 989 views
I was wondering if perhaps Euphoria 4.2.0 would be ready for beta testing anytime soon?
I've been working on some of the other features I detailed Roadmap to Euphoria 4.2, mainly zip files and hashes.
I can try to merge the struct branch into master with my keyword changes soon. I also need to get GitHub Actions publishing releases after it completes a build so that "beta" builds and whatnot are easier to download.
That new struct feature would come in handy. I was also thinking about updating or making a new Win32lib type-ish wrapper.
I definitely think structs will be very useful for interacting with a lot of things and I'm looking forward to an overhaul of Win32Lib.
-Greg
Yes the new struct feature will be very handy. Especially when wrapping libraries. It would also probably help with making a new Win32Lib type wrapper.
6. Re: Eu 4.2.0 Beta?
- Posted by Bhupen1277 Jun 16, 2022
- 966 views
I don’t know Python. However, talking with some young job aspirants, Python with Data manipulation abilities give them a 6-figure income in industry.
So, what is the difference? Can anybody explain why we have to have newer versions of Euphoria with problems remaining and modifications every few weeks?
7. Re: Eu 4.2.0 Beta?
- Posted by ghaberek (admin) Jun 16, 2022
- 949 views
I don’t know Python. However, talking with some young job aspirants, Python with Data manipulation abilities give them a 6-figure income in industry.
So, what is the difference? Can anybody explain why we have to have newer versions of Euphoria with problems remaining and modifications every few weeks?
I'm confused. What "newer versions of Euphoria" are you talking about? We haven't had an official release in the past decade.
-Greg
8. Re: Eu 4.2.0 Beta?
- Posted by Bhupen1277 Jun 16, 2022
- 949 views
I don’t know Python. However, talking with some young job aspirants, Python with Data manipulation abilities give them a 6-figure income in industry.
So, what is the difference? Can anybody explain why we have to have newer versions of Euphoria with problems remaining and modifications every few weeks?
I'm confused. What "newer versions of Euphoria" are you talking about? We haven't had an official release in the past decade.
-Greg
Perhaps i am confused. To me a beta is newer version and I have gone through 4.05, 4.06 4.1 and now we are talking of 4.2.
What I was trying to convey is that we should look at the languages which are successful in the market place and try and introduce those features.
We should not bother to see if those features are "Good". As long as you can say we also have that in Euphoria, you are OK.
Quite frankly I have not been able to convince my nearest relatives to use Euphoria, because they talk of Python and Java all the time.
9. Re: Eu 4.2.0 Beta?
- Posted by ghaberek (admin) Jun 16, 2022
- 966 views
Perhaps i am confused. To me a beta is newer version and I have gone through 4.05, 4.06 4.1 and now we are talking of 4.2.
The next release of Euphoria will be version 4.2. We did go through 4.0.1, 4.0.2, etc. up to 4.0.5. And a while ago I retroactively declared 4.1 to be a "full" release. Some new features and changes are version-dependent so the master branch will be getting incremented soon as we move towards an actual release. Keep in mind that some features like structs and a lot of the standard library features are already in various states of half-complete.
What I was trying to convey is that we should look at the languages which are successful in the market place and try and introduce those features.
I couldn't agree more. This is why I'm working on adding features that very common and useful in the world, like parsers for Markdown, JSON, and SGML (HTML/XML). And a template engine. And database support. And zip files and gzip compression. And cryptographic hashes like MD5, SHA2, etc. And support for HTTPS and other encrypted protocols. And SQL database connectors like MySQL/MariaDB, Postgres, and SQLite.
But -- and this is very important -- while sometimes languages are popular because they're good, sometimes they're popular because they are popular. It's a weird paradox but it's still true nonetheless. Sometimes a language like Python or Java takes off not because it's a good language but because it's just good enough to be popular. Then a community swells around the language and it takes off even higher.
We should not bother to see if those features are "Good". As long as you can say we also have that in Euphoria, you are OK.
Well, they should still be functionally good features. Nobody wants to use a bad feature, right? I think that right now, we need to focus on bringing Euphoria up to par with what the rest of the world expects a programming language to have. And we're getting there. One of the biggest features I think we need is classes, but I'll admit that's very much a "next version" feature.
Quite frankly I have not been able to convince my nearest relatives to use Euphoria, because they talk of Python and Java all the time.
Right, like I said: popular because they're popular. Python is good. Java is awful. In my opinion Euphoria is better than either, but right now we can't offer half the functionality those languages have until we can pull Euphoria up to speed and then start moving forward.
All that said, I think we're all on the same team here. If anybody wants to help contribute so we can get things moving along better, just speak up. There's no shortage of things to do and a lot of the work is "front end" stuff (like standard library) or "user facing" stuff (like documentation).
-Greg
10. Re: Eu 4.2.0 Beta?
- Posted by SDPringle Jun 17, 2022
- 923 views
Features I like about C++:
- The ability to set constants in routines rather than only variables.
- exceptions
- full classes
- operator overloading (need classes for this)
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.
Some things I would like to see:
- 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.
sequence s s = regex:new("[a-z]+") delete(s) puts(1, s) -- I want it to say: 's is no longer declared error' at parse time.
- 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.
for i = 1 to length(s) do if some_condition then -- this causes errors in Euphoria today s = s[1..i-1] & s[i+1 .. $] end if if some other condition then i += 1 -- so does this end if end for
I want loops like these to work.
- 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 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.
- 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
- 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)
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.
11. Re: Eu 4.2.0 Beta?
- Posted by ghaberek (admin) Jun 17, 2022
- 926 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
12. Re: Eu 4.2.0 Beta?
- Posted by SDPringle Jun 17, 2022
- 903 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.
I meant the former. Euphoria being copy on write, I don't appreciate the benefit of the second interpretation you have. In something that looks like copy by value (but is copy on write), why should we care whether a caller modifies it?
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.
...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.
One could mark variables in the parser as deleted. Making people declare a new variable rather than recycling variables and if they can reuse the same name, it wouldn't bother me much. Such delete statements would then have to be restricted to be the same level as the declaration. (not with in a branch or something)....
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.
Remember in the forum threads a long long time ago... someone posted this problem where the program simulates throwing a ball over a wall. The program has to catch it. Some how the ball never gets caught. It gets lost. He couldn't figure out why, and neither could we.
13. Re: Eu 4.2.0 Beta?
- Posted by Icy_Viking Jun 17, 2022
- 890 views
I see this thread has become somewhat long and has led to discussion, but this I like. I agree that Euphoria having more features like Python or Java would be great. I also agree with Greg that Java sucks. I mean yes it is popular, but I'd rather program in C-Sharp then Java if it came down to it. Honestly I'd write/program in Euphoria for all my needs and wants if it were completly feasible. I'd love to make money writing code in Euphoria. Getting a little off-track here. I've used both Python and Java and I don't really care for them. There's a whole list I could go on aqbout Java. However with Python, its that it uses whitespace to indiate when a if-statement begins and ends. That I'm not a fan of. I'd rather have brackets or
if then end if
Like Euphoria does.
I also think a "for-each" like C-Sharp has would be great. But of course the struct feature is what I'm really looking forward to in Eu 4.2.0! The other new features that Greg has been working on also sound promising. I hadn't thought about classes being added to Euphoria, but I guess it would help Euphoria stand out. I think struct would be similar to classes, but I think structs are easier than classes. I also think that once Eu 4.2.0 releases and has the struct feature, it would be easier to make wrappers. I've also been thinking of making a new GUI/Widget toolkit or expanding upon Win32lib. Windows has changed a lot since the last actual release of Win32lib.
14. Re: Eu 4.2.0 Beta?
- Posted by petelomax Jun 20, 2022
- 868 views
Features I like about C++:
- The ability to set constants in routines rather than only variables.
- exceptions
- full classes
Phix has all three, see below for my thoughts re classes.
- operator overloading (need classes for this)
From operator overloading, comes the ability to create huge integers for cryptography.
Not a fan, and not sure what the connection is (in general) with huge integers. Plus whenever I've messed with cryptography it seems to be the other way round, in that I have to explicitly and frequently and_bits(x,#FFFFFFFF) to discard the high bits that plain C does without giving you any choice, change signs, etc.
- 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.
not the delete() builtin itself, but I've been changing things like IupDestroy() into functions that return NULL(s), eg ih = IupDestroy(ih) as a way to prevent accidental use of ih after it has been destroyed.
- 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.
for i = 1 to length(s) do end for
My go-to solution for that is
for i = length(s) to 1 by -1 do end for
Regarding classes/structs, I'm not finding them particularly useful. In fact I've just translated some OOP code, https://rosettacode.org/wiki/Red_black_tree_sort (Not the F# entry, which is as uttery fascinating as it is utterly indecipherable), and found it littered with code duplication such as (but much bugger chunks):
if (condition) {
thing.right = ...
} else {
thing.left = ...
}
Whereas using sequences and indices lends itself quite naturally to far less code duplication:
integer d = iff(condition?LEFT:RIGHT) thing[d] = ...
There are of course (a rare few) cases where classes/structs shine, I'm just saying they ain't no panacea.
