OpenEuphoria

1. Eu improvements (Part 1)

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

One of my biggest problems with Eu comes when I look at someone's code and
see something like

if atom( base[2][4]) then
    ...

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:

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

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

3. Re: Eu improvements (Part 1)

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Jan 03, 2007
• 501 views

c.k.lester wrote:
> 
> Karl Bochert wrote:
> > 
> > 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)
> 
> That's a cool idea, Karl. It seems to take sequences to the next level.
> 
> I guess you could then do
> 
> sequence line is
>    point x
>    point y
> end sequence
> 
> sequence shape is
>    line a
>    line b
>    line c
> end sequence
> 
> I suspect it won't be easy to implement, eh?

Well, the ooeu equivalent is:

euclass point( sequence p )
    atom x, y
end euclass

euclass line( sequence l ) point p1, p2 end euclass

euclass shape( sequence s ) line a, b, c end euclass </euclass>

One of the demos that comes with ooeu is shape.ex, and shows some simple ways that you can build up objects from other objects. There is no enforcement of changing the structure in ooeu, however.

Matt }}}

5. Re: Eu improvements (Part 1)

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

c.k.lester wrote:

> That's a cool idea, Karl. It seems to take sequences to the next level.
> 
> I guess you could then do
> 
> sequence line is
>    point x
>    point y
> end sequence
> 
> sequence shape is
>    line a
>    line b
>    line c
> end sequence


Shhh! you're giving away part II 

> 
> I suspect it won't be easy to implement, eh?

Thats why we have Robert Craig!

KtB

7. Re: Eu improvements (Part 1)

• Posted by James W Hofmann <jhofmann at ucsc.edu> Jan 03, 2007
• 523 views
• Last edited Jan 04, 2007

I had the same idea, but with a different syntax that fits into the type
system:

type Foo(sequence s)
    index a = s[1]
    index b = s[2]
    index c = s[3]
    return 1 -- any type can be this type
end type

Foo f
sequence bad

bad = {10,20,{30,40}}
f = bad
? f.a -- 10
? bad.b -- fails, sequence has no index for "a"
? f.c[2] -- 40

The issue of "confusing indexes" is a reason for adding syntactic sugar;
declaring a constant value can serve a lot of the same needs, but the scope
is wrong(too wide). The type system can already enforce a regular structure
on your data, it just needs to be extended to be useful beyond that. The
big point of dispute, I think, is that doing it the specific way I've
implemented makes types stronger, perhaps too strong; if you didn't declare
the variable with "Foo" there's no way to implicitly restate as a Foo later.
You will have to copy the data.

An redesigned syntax, then, with that in mind:

Foo f
sequence bad, good
good = {10,20,{30,40,{50,60}}
f = good
? f:Foo.a -- 10
? good:Foo.b -- 20
? good:Foo.c:Foo.a -- 30
? good:Foo.c:Foo.c -- {50,60}
? good:Foo.c[3] -- {50,60}
bad = {1,2}
? bad:Foo.c -- error; invalid subscript. Or error; typecheck failed.

This one makes the code verbose but extremely clear; the user reasserts 
that they are using the specified object as a particular type, for the
purpose of a sequence indexing operation.

You're more likely to skip typing things right now because that system is
only good for tests; if types made the code more clear as well we would
be using them for that benefit as well, and maybe that would encourage
more testing.

Also, this solution looks relatively easy to implement compared with a full
class or struct type. It adds a second kind of type check to the existing 
one: when a dot-value is used the interpreter can go to a lookup hash for
the calling type. If the hash doesn't mention the requested dot-value,
the type-check has failed. If type-checking is disabled or the code is
compiled to C, these values could be translated to constant values and
there would be zero runtime performance loss(possibly a longer startup).

9. Re: Eu improvements (Part 1)

• Posted by James W Hofmann <jhofmann at ucsc.edu> Jan 04, 2007
• 518 views

Jason Gade wrote:
> 
> This looks interesting, but I would like to see a more substantive example.
> 
> What would be the effect of without typecheck?

Original source

type Point(sequence s)
    index x=s[1]
    index y=s[2]
    return length(s)=2
end type

Point p
sequence q
p={0,0} -- initialize
q={5,5}

for nx=1 to 10 do
    p.x = nx
    ? p.x
    p.y = p.x+1
    ? p.y
end for

-- output is 1,2,2,3,3,4,4,5,5,6,6,7,7...

? q:Point.x -- output is 5

Typecheck off makes it into this equivalent:

sequence p
sequence q
p={0,0} -- initialize
q={5,5}

for nx=1 to 10 do
    p[1] = nx
    ? p[1]
    p[2] = p[2]+1
    ? p[2]
end for

? q[1] -- output is 5

At least, I think that's how it would look. A simple replacement of
name-notation with number-notation.

> I kind of like the first example better but then use the colon notation as
> kind
> of a "cast". Maybe. Hmm.

Both notations could work, because they do different things.
Dot-only(simple-dot?) notation says "use the type that you declared the
variable as."
Colon-dot notation says "try to use this particular type on this variable."

In the above example I used simple-dot because it felt natural to me after
doing it so often to reference class variables in Python. But having the
other seems like a reasonable idea for code needing greater structure. I
don't really have a good feel for the potential downsides, though.

11. Re: Eu improvements (Part 1)

• Posted by Chris Bensler <bensler at nt.net> Jan 04, 2007
• 502 views

Before we get carried away, please consider the ramifications of these
proposals.

I'd like to see something like structured sequences in Eu. I would also like to
see some simple form of OOP (I haven't checked out Matt's OOEU, but it appears to
be too complex/advanced for what I would like to see in Eu), but would it be a
good idea to implement both? OO objects are just an advanced form of structured
arrays (sequences) and can be used to implement a simple structure if you want.
You cannot use a simple structure to implement a 'this' keyword or class
hierarchy.


Chris Bensler
~ The difference between ordinary and extraordinary is that little extra ~
http://empire.iwireweb.com - Empire for Euphoria

13. Re: Eu improvements (Part 1)

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Jan 04, 2007
• 508 views

Chris Bensler wrote:
> 
> Before we get carried away, please consider the ramifications of these
> proposals.
> 
> I'd like to see something like structured sequences in Eu. I would also like
> to see some simple form of OOP (I haven't checked out Matt's OOEU, but it
> appears
> to be too complex/advanced for what I would like to see in Eu), but would it
> be a good idea to implement both? OO objects are just an advanced form of
> structured
> arrays (sequences) and can be used to implement a simple structure if you
> want.
> You cannot use a simple structure to implement a 'this' keyword or class
> hierarchy.

I'm curious as to what appears to be more complex than what you wanted.

Matt

15. Re: Eu improvements (Part 1)

• Posted by Michael J. Sabal <m_sabal at yahoo.com> Jan 04, 2007
• 507 views

I've set up a poll at Yahoo Groups:
http://tech.groups.yahoo.com/group/programming_euphoria/surveys?id=12494187

This survey will be open until January 18, and the results will determine 
the priority in the project queue.  The ability to create structures has been
discussed at length in this forum.  To summarize VERY briefly, the benefits
include code clarity and improved interfacing to external libraries.  The 
cons include interpreter complexity and performance degradation.  Other 
benefits can be found in the forum archives, but I would be interested in 
hearing from anyone who can think of any other negatives.

The actual method of implementation will still need to be hashed out, and
perhaps we can put up another poll when this one is done to address those
issues.

Michael Sabal

17. Re: Eu improvements (Part 1)

• Posted by Matt Lewis <matthewwalkerlewis at gmail.com> Jan 04, 2007
• 515 views

Chris Bensler wrote:
> 
> Matt Lewis wrote:
> > 
> > I'm curious as to what appears to be more complex than what you wanted.
> 
> Without having investigated it thouroughly, it's pretty much what I would
> expect,
> but I think it's taking too big of a step at once.
> Mostly, I don't think polymorphism belongs.

Fair enough.

> I also think that inheritance should be limited to one parent.

That is the case in ooeu, unless you consider grandparents to be multiple
parents:

euclass A( sequence A )
    -- ...
end euclass 

euclass B( A b )
    -- ...
end euclass

euclass C( B c )
    -- ...
end euclass

> I would also reuse the global keyword to allow public and private members.

That is my plan, as well.

Matt