OpenEuphoria

1. Missing features in Euphoria

• Posted by GreenEuphorian Jul 28, 2014
• 1867 views
• Last edited Jan 25, 2015

I was quite surprised to read your statement, Jim. Do you really mean that in your opinion the future development of the language should be limited to these two features?

Reading the old posts on the forum I have come across many comments pointing out how Euphoria is actually lacking in many areas, not just the two that you mentioned. Of course, the development team is small and the progress is slow, but why restrict the possibilities for development? Also, I believe it is always better to be realistic, and keep in view the weaknesses of the language, for the sake of improvement.

I have compiled (from many forum posts) a tentative list of the many missing features requested by Euphoria's users over the years, which (I hope) summarizes the main points on which the developers may want to concentrate for future development.

Disclaimer: some of these issues might already have been solved in the latest releases of the language, with which I am not very familiar. If an issue has already been solved, kindly point it out.

• Lack of structures
• Lack of OOP
• Lack of error/exception handling
• Lack of closures
• Lack of threads
• Lack of higher-order functions
• Lack of support for embedding
• Lack of native Unicode support
• Lack of generators
• Lack of efficient disk space management (to avoid waste of disk space when writing data files)
• Lack of true random access for files
• Lack of reference semantics
• Lack of scalar accumulation along a vector operator
• Lack of run-time function specifier
• Lack of pointers
• Lack of nested functions
• Lack of REPL
• Lack of eval ()
• Lack of reflection
• Lack of run-time dynamism, i.e. not being able to interpret or evaluate code at run-time

Now, before someone starts shouting at me that Euphoria is not meant to become another C plus plus or the like, trying to incorporate all the possible language features in the world, I clarify that I am NOT advocating that all these features should be implemented in Euphoria. I am merely pointing out that these features (some of which may indeed be useless or redundant) are not present in Euphoria. At the same time, I am sure that many users would really appreciate if some of these features were added to the language.

Could some of the developers please take the time to comment on the features listed above, just to give the users an idea of what they should or should not expect in future releases? It would be nice if a priority marker was specified against each feature (e.g. high, medium, low, nil) so that the expectations of the users can at least be redefined in more realistic terms.

It would also be useful if non-developers also commented on the desirability of these features, from their respective points of view.

Thanks

Green Euphorian

3. Re: Missing features in Euphoria

• Posted by jimcbrown (admin) Jul 28, 2014
• 1895 views

Of course not. Just that those are the major two that can't be implemented outside of the language. I'll concede a point though - I forgot about exception handling. That's a third.

But, if someone wants to have a go (or another go) at implementing feature XYZ in Euphoria itself, I'm all for it.

I think this is best addressed by directly addressing each area you have brought up from your compiled list.

memtructs branch.

A standard dot4 preprocessor (which gives OOP sugar syntax) is included in demos iirc. We also have OOP libraries (like Diamond).

Conceded.

I already mentioned this, but yes.

Ditto.

Maybe I'm misunderstanding here, but isn't this just routine_id?

This can be done with delete_routine. Perhaps though we're better off adding closures proper (with all the syntax sugar).

True. Actually however, a large part of this was already implemented - but the dev team made a choice to push this back until a much later release. I don't consider this a big deal because most UI toolkits provide unicode support anyways, and I've been using UTF-8 with Euphoria for years.

Hmm... maybe, I suppose... I've written function composition libraries for Euphoria before....

True. The current C-based source code is not easy to use for embedding Euphoria into another program. Of course, you could always turn something like Matt's eueval library into a shared library, but this isn't the most efficient way of doing things.

What exactly are you referring to with this? Something like bget() ?

You can do it if the operating system supports it, you just might need to wrap a library or two.

You mean something like a generic version of sum() or or_all() ?

You're right, we seem to lack this. The closet thing we have to a generic version of this seems to be stdseq:apply()

I wrote a preprocessor to simulate these, and something similar exists today in the stdlib as eumem. Actually, however, there's a way to get real pointers to work.

Conceded. Having pointers is probably good enough, but getting the syntax sugar and the real sematics would be nice.

Agreed, but this is easy to emulate with a preprocessor.

True. There was a REPL at one point in time, but it no longer works with current versions of Euphoria.

True, but one can get it to work by including eu.ex - Matt once wrote an eueval library to do this.

Conceded. This won't be universally possible. Translated programs won't be able to support reflection, ever. The interpreter could in theory, but it'd take a lot of work on the insides.

Hmm. Actually the interpreter can already do this in theory, but no one has ever attempted to make it do this. Anyways, you can simulate this with eu.ex or Mat''s eueval library.

Absolutely. There's nothing wrong with holding a discussion.

My main point though, is that the lack of, e.g. nested functions or OOP or REPL or reflection or embeddability in (for example) C does not make C a toy language.

This I agree with in its entirety.

5. Re: Missing features in Euphoria

• Posted by ghaberek (admin) Jul 28, 2014
• 1739 views

On that note, I'd also like to point out that Euphoria's preprocessor system leaves a lot to be desired. Without a reliable means of chewing up the language and spitting it back out, every preprocessor author is left to his own devices. The barrier-of-entry on implementing new preprocessor-defined features shouldn't be so high. There's got to be a more formalized way to process the language.

-Greg

7. Re: Missing features in Euphoria

• Posted by ghaberek (admin) Jul 29, 2014
• 1635 views

I'll quote myself on that one:

I guess what I was really referring to here was reflection. It really seems that the two go hand-in-hand: implementing reflection without OOP seems unnecessary and implementing OOP without reflection seems incomplete.

-Greg

9. Re: Missing features in Euphoria

• Posted by Nevla Aug 09, 2014
• 1473 views
• Last edited Aug 10, 2014

If we had anonymous functions, we could implement a truly Euphoric OOP system by using sequences (yes, sequences!), without the need for any other OOP infrastructure. And it would be an all-Euphoric solution, for Euphoria purists.

That's what Lua developers did with tables, which are to Lua what sequences are to Euphoria. The clever trick by Lua's developers consisted in having OOP objects that are actually tables. The methods/functions are stored within the tables, just like the variables are. Everything in Lua is table-based, so objects are simply tables. Of course, there is some syntax candy involved to make them look like traditional objects, but in the end they are nothing but tables. Why can't we have the same in Euphoria, with sequences?

+1

I would really like to see nested functions supported in Euphoria.

11. Re: Missing features in Euphoria

• Posted by Nevla Aug 10, 2014
• 1359 views

I see. Is there an easy-to-read article somewhere that compares the different OO systems for Euphoria? Possibly with a comparative table showing the different syntax conventions.