Re: Euphoria's identity/philosophy -- Where is the focus?
- Posted by SDPringle Oct 28, 2014
- 3558 views
I think EUPHORIA's core identity is the following:
- to have only one kind of data: objects which are an atom or a sequence of objects
- to have pass by value for *everything*. Not only atoms but sequences as well.
- in contrast to the famous expression "Garbage In, Garbage Out". Euphoria is Garbage In, Error Out.
There is a bit of a compromise with poke and peek. We have what in C are void* pointers. This violates the first principle (they are atoms that you can get other information from), yet Euphoria would be very limited if you couldn't do this kind of thing. A wrapper library is supposed to hide these routines.
Euphoria sequences are most like arrays in other languages. A number is a number. There is no concept of 5 the complex number vs. 5 the floating point number vs. 5 the integer. Any library that works with very large numbers violates this idea. For the sake of argument I implemented 320 bit big endian integers using sequenes in the namespace bignum. Because now we have 5 vs. bignum:new("5") which are different but the same, we no longer have 5 is just 5 anymore. Such objects are useful, however.
It would be nice if we could reconcile the later in such a way that 5 == bignum:new("5") would return 1. The only way I can see to do this is to allow arbitrarily long integer and floating point sizes to be used by default and to have an 'approx' function that could be used to crunch them back into 64-bit double floats again. As an optimization approx( 10 / 3 ) would simply be division by double floats.
Other languages pass by reference and value. Euphoria has pass by value or it looks like that from the user's prospective. The fact that it copies on write is an implementation detail on how it implements pass by value. There are ways around that though. 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. Some deem always returning the modified structure to be a less attractive way of doing things.
Finally, garbage in, error out. The user is supposed to know a value should attain a certain value, run-time type checking catches this error, assigning to an index out of bounds is an error, etc. If possible, don't let the user shoot himself in the foot.
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.
The three-principles are in order of importance, except that principle two and one are at par with each other.
Shawn Pringle
