OpenEuphoria

Re: Eu improvements (part 4)

• Posted by Karl Bochert <kbochert at copper.net> Jan 06, 2007
• 638 views

James W Hofmann wrote:
> 
> Karl Bochert wrote:
> > The intention is to access the elements by name. If you want to access by
> > index, you should use a plain unstructured sequence.
> 
> In that case, please don't call them "sequences." That is
> misleading. Sequence means indexing to me. And "structured" is
> not very meaningful except in relation to C structs, or the practice
> of "structured programming," which is mostly about flow of execution
> but when taken in this context led me to believe it must have been
> about type checking(a practice that came into vogue at the same time
> as structured programming).
Sorry -- I'm open to any name.

> 
> Hence, my remarks on typing and indexing. I don't have any major
> problem with the concepts, but I do disagree with how they are
> presented.
> I think it would be a good idea to extend type to support
> these things. So I will propose something and see if you like it.
> 
> You could have two syntaxes:
> 
> }}}
<eucode>
> 
> type Point(sequence s) -- classic syntax
>     ...
>     return checkval
> end type


> type Point is -- like SS
>     atom x,y
>     (where)
>     ...
>     (requiring)
>     ...
>     return checkval
> end type
> 
> </eucode>
{{{

> 
> 1. "Is" now tells us that Point is going to contain several 
> variables(ignoring their internal representation; whether it
> should be accessable as a sequence or not is tangential to
> the major functionality of named access)
>
Good. the 'is differentiates it from a 'normal' type
 
> 2. "Where" lets us initialize these variables each type we
> instantiate a Point. This is optional, hence the (), which would
> not appear in real code.
>
Why 'where'?
why not just
   atom x = 0.0, y = 0.0
 
> The "Point.x = 5" example of setting the initialization is still
> valid, but I think "where" is a bit cleaner since it keeps that 
> inside the same code block.

Why complicate it with code at all? The original type() has code, and
the syntax looks like code.  The new version simply states
what a point is.
 
> 
> 3. "Requiring" is the original use of type, the checking
> functionality. But since we aren't using a sequence representation
> there is no reason for a parameter to be passed. Instead we would
> only refer to the variables that "is" declared, in this case x and
> y. Note that there would be two checks, one for is and one for
> requiring.
I don't understand.

> 
> The "extends" syntax can apply as in your SS proposal, with
> the "where" and "requiring" keywords causing an override of the
> original declaration.
If you have the where and requiring (which I don't want) along with
extends, then I suspect the two requiring's might be more complex,
but then I need a better explanation of requiring.

KtB