Re: Missing features in Euphoria

new topic     » goto parent     » topic index » view thread      » older message » newer message
  • Posted by mattlewis (admin) Jul 29, 2014
  • 1531 views
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 thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu