Eu Improvements consolidation
Because of your rant, I'm going to try to respond to all of these together (even
though I've discussed in each one).
Karl Bochert wrote:
>
> One of my biggest problems with Eu comes when I look at someone's code and
> see something like
> }}}
<eucode>
> if atom( base[2][4]) then
> ...
> </eucode>
{{{
>
> What is the significance of the 4th item of the kind of sequence put into
> the 'base' sequence? Does base contain different kinds of sequences, or
> a single kind? Does the nature of its contents change with time?
>
> Therefore:
> }}}
<eucode>
> sequence point is -- define a fixed sequence
> sequence name
> atom x, y
> end sequence
> ...
> point.x = 0 -- set point's x value
> if point.x > 0 then
> point.name = 3 -- illegal
> point = concat(point, 0) -- illegal
> mylist[1].name = "!!" -- can be in a seq.
>
> -- the above opaque example might now be:
> if atom(base[2].location) -- The location of base's second element
> -- or perhaps
> if atom(base.values[4]) -- The fourth vale of base
> </eucode>
{{{
>
> The 'fixed sequence':
> 1) has named elements
> 2) cannot have its structure modified
> 3) contains only data (like any other sequence)
> 4) may be put in another sequence without losing its
> identity (like any other data)
>
> KtB
One thing I've been trying to point out is the Matt's ooeu does this but the
syntax is a little different. Matt would have to answer if it fits all four of
your criteria but I believe that it at least follows the first three.
Karl Bochert wrote:
>
>
> }}}
<eucode>
> sequence point is
> atom x, y
> end sequence
> </eucode>
{{{
>
> The fixed sequence declaration creates a real sequence in memory, but
> it also describes a datatype.
> Therefore it should be able to be used to define data just like
> any other datatype. Also like any other datatype, it should be
> usable as a function.
>
> }}}
<eucode>
> point x, y -- create 2 points
> point(foo) -- is foo a point?
> </eucode>
{{{
>
> This creates a user defined type by restricting the types in a sequence,
> much as Eu's 'type' creates a user defined type by restricting the
> values of an existing type.
>
> The sequences 'x' and 'y' are simply created as exact duplicates of the
> sequence 'point', values and all.
>
> We can now create complex sequences whose elements are named(documented)
> and enforced(fewer bugs).
>
> KtB
ooeu handles the first part, I'm not sure about runtime type checking. I can't
find it in the ooeu docs. Again, it's a question for Matt.
Karl Bochert wrote:
>
> Allow the programmer to defined one fixed sequence in terms of another.
>
> }}}
<eucode>
> sequence Point is
> integer x, y
> end sequence
>
> sequence Point_3D extends Point
> integer z
> end sequence
> </eucode>
{{{
>
> If at some later time we decide that a Point should have a name, we
> can change the definition of Point to
> }}}
<eucode>
> sequence Point is
> sequence name
> integer x, y
> end sequence
> </eucode>
{{{
> and a Point_3D gets a name field automatically (it is a Point, after all)
>
> Some notes:
> 'Point' provides 5 things:
> 1) an actual sequence
> 2) Access to elements by name (with dot notation)
> 3) A separate namespace for the element names
> 4) A user defined type that provides type checking just like Eu's
> current type() mechanism
> 5) Extension from parents (Inheritance)
>
>
> The data typing aspect can be understood by realizing that Eu
> can already create the Point datatype (so 'without typecheck' acts just
> as it does for any other user-defined type)
> }}}
<eucode>
> type Point (sequence s)
> if length(s) != 2 then return 0 end if
> if not integer[1] then return 0 end if
> if not integer[2] then return 0 end if
> return 1
> end type
> </eucode>
{{{
>
> One fine point is to realize that the Point datatype serves as a
> prototype for the definition of new sequences -- it creates them complete
> with data:
> }}}
<eucode>
> sequence Point is
> integer x, y
> end sequence
> Point.x = 5
>
> Point my_point -- create my_point as a copy of Point
> ? my_point -- => '5'
> </eucode>
{{{
> The newly created sequence is initialized.
>
> KtB
This is basic inheritance, and again ooeu does this. I'm not trying to kick a
horse that is down on the ground or anything, but...
I'm not going to quote part four. I didn't really understand the post (even
though I understand PBR) so I'll need to read it a few times.
Just as a note: ooeu has var_id() which works like routine_id(). You can grab
the id of a variable and modify it directly so you can do PBR. But it's more like
pointers than automatic.
Didn't you write the Bach interpreter? I know Kat always used to gush over it
even though I've never used it. Are some of these features from Bach?
Oh, and here's a link to ooeu: http://ooeu.sourceforge.net/
|
Not Categorized, Please Help
|
|
