OpenEuphoria

Re: Fair Criticism

• Posted by gertie at ad-tek.net Aug 11, 2001
• 537 views

On 11 Aug 2001, at 16:30, Irv Mullins wrote:

> 
> Kat wrote:
> 
> > I *much* prefer the Eu way of free-form structures. This leaves it up to
> me what i want
> > to put in "fields". In Pascal, i used a lot of variant fields, and was
> constrained by the
> > rule of only one variant and it had to be at the end of a pre-declared
> fixed record. What
> > would make arrays/records as complex as C++ or pascal, but far more
> versatile, will
> > be if/when Rob (or someone) adds the runtime var naming, like mirc.
> 
> No one, including Rob, seems to be able to grasp the fact that fixed-length
> "structures".
> have never been the issue here. All people want is a simple, maintainable,
> and readable,
> way to reference parts of a standard Euphoria nested sequence..
> 
>  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. The fact that
> Pascal's
> structures and variant fields were useful to you, (and me, and lots of other
> programmers) despite their limitations, should be only more reason to
> include something similar in Euphoria, where you can have infinitely variant
> fields without the constraints you mentioned above.
> 
> It would be nice, after that, if the elements of a structure could retain
> their types, but I believe, given the nature of Euphoria, that would be
> impossible. So perhaps "structure" would be
> an overly ambitious name. Call 'em "indexed lists" or, "named nested
> sequences" or whatever,
> just as long as the names of the fields are somehow associated with the
> sequence itself,
> so that we have meaningful and non-colliding names for more than one
> sequence  in a given
> program.
> 
> You know very well that a Pascal program which has both a customer structure
> and a product
> structure will never get confused when you refer to customer.name or
> product.name.
> And that you can go into the customer structure later and add a .phone field
> without
> having to renumber all the following fields in that structure. In most other
> languages
> this is a standard, in fact an  *expected*  feature. One which simplifies,
> not complicates,
> the language. One which reduces, not increases, errors.

And makes local names easier, like the following mirc one-liner, which wipes the
contents of all the vars i am about to use:
 unset %reading_*
even tho i mirc does not support structures, the naming conventions lend
themselves
to the use of totally free-form "structures". Even tho the names are all one
dimension,
doing this:
if ( %opdeop. [ $+ [ %net ] $+ . $+ [ # ] ] == yes ) etc
in Eu would be fantastic for the Eu database, making it possible to access 
fields/rows/columns (data.{%net,channel}.indexnumber) by names that the 
programmer had not even thought about. 

Kat