Re: Fair Criticism
On Sunday 12 August 2001 21:48, Robert Craig wrote:
<snip the Kat bait>
>
> 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.
Then shouldn't it be fixed?
> 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).
Horrors. Let's make it even more elegant, by removing the sequence.
And what about integers, aren't they a data type? Get rid of them too.
> 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.
How does that defeat my original intention? Being able to refer
to elements of a sequence by a meaningful name doesn't mean
that they can't still be referenced by number. The third item in a list,
whether it has a name or not, is still the third item in the list, isn't it?
Can you concatenate two structures? x & y
Why not? In most languages, a structure can be made up of other
structures.
> What if x and y share some of the same field names?
They can in C, Pascal, every other language I can think of....
doesn't seem to cause any problem.
> Can you append something to a structure?
> What do you get?
A structure with one additional field (element - whatever) which hasn't
been given a name. How is this different from appending something
to a sequence, when you haven't created a constant to point there?
> And of course you can't subscript
> a structure with a number.
Sez who?
> So structures would
> not be a mere tweak of sequences. They would
> have to be treated as a distinct data type.
If you want typechecking of the elements, yes.
Otherwise, nothing you have mentioned so far requires anything
more than a little syntactic sugar.
> 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 add two sequences? The answer is "maybe".
Where's the difference?
> "can you compare two structures with > what about = ?",
I don't know - can you compare two sequences with =?
> "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.
Ok, Rob, i can see that this would be too difficult.
Forget it, I won't mention the subject again.
Regards,
Irv
TP, circa 1984, 38.6 k of bloat, with built in editor, BCD math and -
oops, sorry, I promised not to mention "those things" anymore ;)
|
Not Categorized, Please Help
|
|
