Re: Missing features in Euphoria
- Posted by DerekParnell (admin) Jul 29, 2014
- 1597 views
I think that we need to be a bit more precise with the terminology that is used during this discussion. We could end up arguing about different things without realizing it.
When changing Euphoria in significant ways, we have to be certain that there is a justifiable need. A strong case in favor of the change needs to be ratified by the community.
But anyhow, here are my initial thoughts on this list.
- Lack of structures
I think what is meant here is 'lack of syntax support for structures'. Euphoria already copes with both sort of structures - data and memory-mapped. Its just that the syntax for them can be a bit unwieldy and thus a hindrance.
- Data structures are those that allow us to name, assign datatypes to, and refer to, items in a sequence. Used within a Euphoria coded program.
- Memory-mapped structures are those that allow us to name, assign datatypes to, and refer to, areas of RAM. Used when interfacing with other languages.
- Lack of OOP
Again, this is a syntax issue more than anything else. Euphoria can do OOP right now, just as C and Assembler can ... but the effort to do so using the current syntax is a barrier.
- Lack of error/exception handling
Yep ... this needs to be built into the backend, and thus also the syntax.
- Lack of closures
Similar to exceptions in this regard. A related issue is nested routines and anonymous routines.
- Lack of threads
This is a biggie. A lot of work will be needed to support this and the related multi-cpu support and shared memory accesses.
- Lack of higher-order functions
Hmmm... not quite in Euphoria's paradigm really. I could need convincing on this one.
- Lack of native Unicode support
Depending on what is meant by native, I don't think Euphoria will ever have this. Sequences are already UTF-32 friendly and it wouldn't be hard to create UDT to support UTF-8 and UTF-16. Except for some simple functions, nearly all the functionality to support Unicode would come from a 3rd-party library and not written in Euphoria.
- Lack of efficient disk space management (to avoid waste of disk space when writing data files)
I do not know what this is about. As far as I can tell, Euphoria already has efficient disk space management. What wastage are you referring to.
- Lack of true random access for files
Euphoria already has and has always had true random access for files. I'm not sure what this is about.
- Lack of reference semantics
- Lack of pointers
One of the paradigms that defines Euphoria is pass-by-value only. To have reference semantics would redefine the language. The choice of only having pass-by-value was a deliberate one in order to avoid a class of problems found in C and other 'traditional' languages. The main purpose of pass-by-reference and pointers are to increase performance by not having to copy data. Euphoria uses a hybrid system in which sequences and atoms are actually passed by reference and the data copy is only made if the item being passed is modified by the routine receiving it. This means that passing a long sequence to a routine that doesn't modify it, is no more expensive than passing a pointer to it.
Euphoria takes a safety-first approach. Basically, any data which your routine creates and thus owns, can never be modified by any other routine. If you feel you must use 'sharable' data then use can use data defined at the module level and declared global or public, or you can use the eumem.e library and pass references to data in a shared area.
I feel that the case for pointers (to data) and reference semantics has still be to be made convincing. Using such features usually also lead to bugs and harder-to-maintain applications.
- Lack of scalar accumulation along a vector operator
What? Can you give an example?
- Lack of run-time function specifier
Not sure what you mean by this one either.
- Lack of nested functions
Yeah, this would be nice. Not a high priority but nice. It can be used to remove repeated code and/or to make a routine more readable.
- Lack of reflection
I'm sure a case for this could be developed. I can't think of one right now, but it feels as if it might be a "good thing" - maybe.
- Lack of REPL
- Lack of eval ()
- Lack of run-time dynamism, i.e. not being able to interpret or evaluate code at run-time
