OpenEuphoria

Re: Fair Criticism

• Posted by Robert Craig <rds at RapidEuphoria.com> Aug 12, 2001
• 531 views

Irv Mullins writes:
> The fact that Rob had trouble with C structures 
> is irrelevant to Euphoria, except in that
> it must have tainted his view of how useful structures can be. 

I was actually referring to "data structures" in general in C, 
not "structures" per se. It's the mallocing and freeing that drives
me nuts. "structures" are a good feature of C, Pascal etc.,
but I think they'd be bad news for Euphoria.
If you look at the C source code for Euphoria (as you'll soon
be able to) you'll find lots of C structures, and even (horrors!) 
a few gotos.

I agree that the current way in Euphoria of simulating
structures is not as good as the real thing. It does
open up possibilities for errors.

However, think a bit further.
Suppose structures were added to Euphoria.
The elegant little language formerly based on just 2 data
types (atoms and sequences) would now be based
on 3 (atoms, sequences, and structures).

Oh, but isn't a structure just a form of sequence?
Well... can you slice a structure:  x[3..5]? If you can then
you are admitting that fields can also be 
referenced by number, which defeats your 
original intention. Can you concatenate two structures? x & y
What if x and y share some of the same field names?
Can you append something to a structure?
What do you get? And of course you can't subscript
a structure with a number. So structures would
not be a mere tweak of sequences. They would 
have to be treated as a distinct data type.

For structures to have any real usefulness 
you would have to allow sequences 
of structures, not just isolated individual
structures declared for a single variable.

So now the elements of a sequence can be
atoms, sequences or structures. And the fields
of a structure can be atoms, sequences and structures.
Fine. But then a host of complicated questions arise. 
Every library routine has to be reconsidered and the 
documentation and implementation have to be updated. 
For each argument of each routine we must ask 
"What if a structure is passed in here?" Does it
make any sense? Is it the same as passing a sequence?
Is it an error? Can we force it to make sense?

Then there's the implementation.
At every place in the interpreter or translator
where we deal with sequences (that's almost everywhere)
we must now augment the code to allow for 
the possibility of structures. That's extra if-statements
being executed everywhere, and a combinatorial growth
in cases, e.g. using + as one example: 
Now:
atom+atom, 
atom+sequence, 
sequence+atom,
sequence+sequence, 

New cases to code:
atom+structure, 
structure+atom,
structure+structure, 
structure+sequence
sequence+structure

Imagine the code bloat in the interpreter,
and the code bloat in the translated C code.

The possibilities for errors in the interpreter or translator
will dwarf whatever possibilities there are now when using 
simulated structures. But that's not the worst part.
The worst part is that Euphoria's simplicity will
have been compromised severely. People will have to
remember dumb things like "can you add two structures?",
"can you compare two structures with > what about = ?", 
"what are the scope rules for field names?" etc. etc.
In an effort to make one aspect of coding somewhat 
more robust, you will have seriously degraded the language 
as a whole, both the ease of understanding it, and the 
ease of implementing and maintaining it in the future.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com