1. Missing features in Euphoria

jimcbrown said...

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?

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

new topic     » topic index » view message » categorize

2. Re: Missing features in Euphoria

My 2c worth (and this comment is worth exactly what you're paying for it so keep that in mind ... :) )

Of the list presented the only two that I personally would like to have are the structures and the random file access additions. The others, while nice and perhaps needed by some developers, are 'fluff' IMO. Sure Euphoria could become another C# with incomprehensible syntax, 2-line long function/subroutine calls and obtuse syntactical twists depending on the time of day/day of week when the code was written ... but is that what we want and above all is it wise? Living in a Micro$oft developer world every single day at work I really enjoy going home and figuring out how to do what I need to do in Euphoria.

So, bottom line: I like Euphoria just as it is, frankly ... in fact version 4.x is going to be the ONLY programming language on the Linux box that I'm currently building. The addition of all the other 'stuff' listed won't enhance my personal experience in any way ... in fact it will make me dread doing any serious coding in Euphoria.

Again, before I get slammed, this is my personal opinion and represents my thoughts on the list given earlier ...

Have a great day!

Tom

new topic     » goto parent     » topic index » view message » categorize

3. Re: Missing features in Euphoria

GreenEuphorian said...
jimcbrown said...

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.

GreenEuphorian said...

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.

GreenEuphorian said...

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.

GreenEuphorian said...
  • Lack of OOP

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

GreenEuphorian said...
  • Lack of error/exception handling

Conceded.

GreenEuphorian said...
  • Lack of threads

I already mentioned this, but yes.

GreenEuphorian said...
  • Lack of generators

Ditto.

GreenEuphorian said...
  • Lack of run-time function specifier

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

GreenEuphorian said...
  • Lack of closures

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

GreenEuphorian said...
  • 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.

GreenEuphorian said...
  • Lack of higher-order functions

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

GreenEuphorian said...
  • 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.

GreenEuphorian said...
  • 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() ?

GreenEuphorian said...
  • 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.

GreenEuphorian said...
  • 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()

GreenEuphorian said...
  • 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.

GreenEuphorian said...
  • Lack of reference semantics

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

GreenEuphorian said...
  • Lack of nested functions

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

GreenEuphorian said...
  • Lack of REPL

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

GreenEuphorian said...
  • Lack of eval ()

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

GreenEuphorian said...
  • 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.

GreenEuphorian said...
  • 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.

GreenEuphorian said...

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.

GreenEuphorian said...

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.

new topic     » goto parent     » topic index » view message » categorize

4. Re: Missing features in Euphoria

jimcbrown said...
GreenEuphorian said...
  • 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.

I think a lot of the work has already been done in the interpreter. Take a look at the debugger stuff. I think it could be done with the translator. Probably similar to how we work with routine ids now.

Matt

new topic     » goto parent     » topic index » view message » categorize

5. Re: Missing features in Euphoria

jimcbrown said...
GreenEuphorian said...
  • Lack of OOP

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

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

new topic     » goto parent     » topic index » view message » categorize

6. Re: Missing features in Euphoria

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

These are variations of the same thing. I can't comment on the need for this because I've never needed it. It is however, not a trivial piece of work. It would need a lot of justification, IMO.

new topic     » goto parent     » topic index » view message » categorize

7. Re: Missing features in Euphoria

DerekParnell said...

  • 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.

I'll quote myself on that one:

ghaberek said...
jimcbrown said...
GreenEuphorian said...
  • Lack of OOP

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

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.

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

new topic     » goto parent     » topic index » view message » categorize

8. Re: Missing features in Euphoria

DerekParnell said...
  • 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.

I'm not totally convinced that the pros outweigh the cons for this. But note that using std/eumem.e /is/ using pointers to a heap stored in a sequence, along with all of the problems that come with "normal" pointers. To me, the best argument for native reference semantics (vs eumem) is performance. There are some hacky workarounds to get good performance when modifying data stored in eumem.

Also, the existence of our delete routine stuff could make debugging a lot easier. IOW, we already have hooks for when euphoria objects are dereferenced, and we could (optionally) supply a default hook to track this sort of thing, say when with debug is in effect. We could do additional instrumentation / logging to produce something similar to what valgrind gives to C/C++.

Matt

new topic     » goto parent     » topic index » view message » categorize

9. Re: Missing features in Euphoria

GreenEuphorian said...
  • Lack of higher-order functions

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?

GreenEuphorian said...
  • Lack of nested functions

+1

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

new topic     » goto parent     » topic index » view message » categorize

10. Re: Missing features in Euphoria

Nevla said...

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.

...

Why can't we have the same in Euphoria, with sequences?

This is already possible in Euphoria and has already been used by a few OO systems written in Euphoria. Check out the routine_id function.

The issue is really that Euphoria doesn't have the syntax niceties to make it easier to write and read OO code.

The first C++ 'compiler' was actually just a front end processor that output standard C code, which was feed into the normal C compiler to produce the runtime program.

new topic     » goto parent     » topic index » view message » categorize

11. Re: Missing features in Euphoria

DerekParnell said...
Nevla said...

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.

...

Why can't we have the same in Euphoria, with sequences?

This is already possible in Euphoria and has already been used by a few OO systems written in Euphoria. Check out the routine_id function.

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.

new topic     » goto parent     » topic index » view message » categorize

12. Re: Missing features in Euphoria

Nevla said...

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.

No. You'll need to do the research yourself at this stage.

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu