Re: Euphoria's identity/philosophy -- Where is the focus?
- Posted by ghaberek (admin) Oct 28, 2014
- 3438 views
Like the std/map.e library which uses false pointers. This has caused some confusion among some users who save the map to a disk, (really only a handle) and find the map doesn't exist when another process tries to use the same handle. That's the cost of using false or real pointers. The win is you get pass-by reference semantics with std/map. If it were pass-by-value, each routine would need to return a new map in order to modify an existing one.
FYI, both the Map and Stack libraries use Pseudo Memory (std/eumem.e) library for these "false pointers" to provide pass-by-reference functionality. The Pseudo Memory library has the potential for a variety of uses based on its "pointer" semantics.
I think that often the last principle is in conflict with the first. Having distinct types prevent all kinds of errors from happening. As mentioned before, pointers in Euphoria are essentially void*, for they are simply just numbers (principle 1) and they do not have the structure type information that you get with C in int* and so on. The coder has to determine the type on each access (against principle 3). The EUPHORIA parser cannot check for this.
I think that when you start to cross over into other languages (e.g. working with a C library) then most of the rules go out the window. However, I believe that the author of a C library wrapper should do his best to preserve the nature of Euphoria within that wrapper to the benefit of his users (other Euphoria programmers). The same concepts, I believe, will hold true when (if?) the struct branch goes full-time: typical Euphoria programmers won't need to use built-in structures, but library authors can use them to ease the burden of wrapping a structure through peek()/poke() calls.
-Greg
