Re: Missing features in Euphoria
- Posted by jimcbrown (admin) Jul 28, 2014
- 1790 views
From my point of view, Euphoria is more-or-less missing only two features - native multithread support and generators. (I'm still working on the first but not making a lot of progress yet.) Otherwise, it mostly has everything you'd expect from another language.
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?
Of course, the development team is small and the progress is slow, but why restrict the possibilities for development?
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.
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.
I think this is best addressed by directly addressing each area you have brought up from your compiled list.
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
memtructs branch.
- Lack of OOP
A standard dot4 preprocessor (which gives OOP sugar syntax) is included in demos iirc. We also have OOP libraries (like Diamond).
- Lack of error/exception handling
Conceded.
- Lack of threads
I already mentioned this, but yes.
- Lack of generators
Ditto.
- Lack of run-time function specifier
Maybe I'm misunderstanding here, but isn't this just routine_id?
- Lack of closures
This can be done with delete_routine. Perhaps though we're better off adding closures proper (with all the syntax sugar).
- Lack of native Unicode support
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.
- Lack of higher-order functions
Hmm... maybe, I suppose... I've written function composition libraries for Euphoria before....
- Lack of support for embedding
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.
- Lack of efficient disk space management (to avoid waste of disk space when writing data files)
What exactly are you referring to with this? Something like bget() ?
- Lack of true random access for files
You can do it if the operating system supports it, you just might need to wrap a library or two.
- Lack of scalar accumulation along a vector operator
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()
- Lack of pointers
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.
- Lack of reference semantics
Conceded. Having pointers is probably good enough, but getting the syntax sugar and the real sematics would be nice.
- Lack of nested functions
Agreed, but this is easy to emulate with a preprocessor.
- Lack of REPL
True. There was a REPL at one point in time, but it no longer works with current versions of Euphoria.
- Lack of eval ()
True, but one can get it to work by including eu.ex - Matt once wrote an eueval library to do this.
- Lack of reflection
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.
- Lack of run-time dynamism, i.e. not being able to interpret or evaluate code at run-time
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.
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.
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.
Also, I believe it is always better to be realistic, and keep in view the weaknesses of the language, for the sake of improvement.
This I agree with in its entirety.
