Re: Fair Criticism
Type casting would satisfy both sides.
We would still use sequences to create structures,but we could type cast an
element, to eliminate the need for the bulky typechecking routines.
Chris
----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Fair Criticism
>
> 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
>
>
>
>
>
>
|
Not Categorized, Please Help
|
|
