Re: Eu improvements (part 4)
- Posted by Karl Bochert <kbochert at copper.net> Jan 06, 2007
- 665 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