OpenEuphoria

1. Eu Improvements consolidation

• Posted by Jason Gade <jaygade at yahoo.com> Jan 05, 2007
• 636 views
• Last edited Jan 06, 2007

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/

3. Re: Eu Improvements consolidation

• Posted by Jason Gade <jaygade at yahoo.com> Jan 05, 2007
• 612 views
• Last edited Jan 06, 2007

I've looked at part 4 and I've decided to hold off commenting on PBR any
further.

Which feature is more important--structured sequences or pass by reference? I
think we should concentrate on discussing one at a time.

--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.

5. Re: Eu Improvements consolidation

• Posted by Jason Gade <jaygade at yahoo.com> Jan 05, 2007
• 637 views
• Last edited Jan 06, 2007

Matt Lewis wrote:
> 
> Jason Gade 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)
> I don't cover 2 or 3, and 4 is maintained only if you put it into another
> class into a member of the appropriate type.  I was more interested in
> the functionality than strict type checking.  Being able to have control
> over the data is one reason why I like Euphoria, and to do those things
> would have taken a lot more effort than what I did. :)

Thanks for the answer, Matt. I like the flexibility, too. Does that mean that
after you instantiate a class you can add more members to it?


> That's a good point.  There are actually two types of PBR in ooeu, once
> you consider var_id's.
>  
> Matt

What's the other version? I guess I'll go back and look at the docs again.

(Sorry to write so much today!)

--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.

7. Re: Eu Improvements consolidation

• Posted by Karl Bochert <kbochert at copper.net> Jan 05, 2007
• 608 views
• Last edited Jan 06, 2007

Jason Gade wrote:

> 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.
I fully accept that OOEU has analogs to all my proposals
> 
> 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?
> 
Yes. Like OOEU, I hoped that exposure to advanced features would prompt
their addition to EU.  Doesn't work that way.

> Oh, and here's a link to ooeu: <a
> href="http://ooeu.sourceforge.net/">http://ooeu.sourceforge.net/</a>

And yet again:
My proposal is not OOP
My proposal is not OOP
OOP is off at a tangent to my proposal.

redundantly,
KtB

9. Re: Eu Improvements consolidation

• Posted by Karl Bochert <kbochert at copper.net> Jan 05, 2007
• 611 views
• Last edited Jan 06, 2007

c.k.lester wrote:
> 
> > 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>
{{{

> 
> This, of course, is not a problem with the language, but with the individual
> programmer. Karl, how would you deal with users who don't follow your
> particular brand of code formatting. Would you dump Euphoria because somebody
> doesn't use SS? For instance, even despite SS being available to Euphoria
> users, you STILL might have code that looks like this:
> 
> }}}
<eucode>
> if atom( base[2][4] ) then
>    ...
> end if
> }}}
<eucode>
Obviously, no matter the language some will write 'good code' and some
will write 'bad code'.
That does not change the fact that language features tilt the balance
one way or another (whatever your definition of 'good code')

The unstructured sequence has, in varying proportions, some faults.
. Indexing with numbers is opaque
. Indexing with ids pollutes the namespace
. Untyped elements allow surprising type changes

Like 'goto considered harmful', some things just promote bad habits.

Why am I even going through this??

KtB

11. Re: Eu Improvements consolidation

• Posted by Karl Bochert <kbochert at copper.net> Jan 05, 2007
• 616 views
• Last edited Jan 06, 2007

Matt Lewis wrote:
> 
> Jason Gade 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)
> > >   
> > > 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.
> 
> I don't cover 2 or 3, and 4 is maintained only if you put it into another
> class into a member of the appropriate type.  I was more interested in
> the functionality than strict type checking.  Being able to have control
> over the data is one reason why I like Euphoria, and to do those things
> would have taken a lot more effort than what I did. :)
> 
Stricter typechecking make the code harder to write, but easier to read.
You must invest a (very)little more writing time up front, and a
little more discipline when using them. (many would think that a good thing).
I appreciate that SS takes away a little of that gunslinger freedom, but
then you don't have to use them.


KtB

13. Re: Eu Improvements consolidation

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

Matt Lewis wrote:
> 
> Karl Bochert wrote:
> > 
> > > 
> > Stricter typechecking make the code harder to write, but easier to read.
> > You must invest a (very)little more writing time up front, and a
> > little more discipline when using them. (many would think that a good
> > thing).
> > I appreciate that SS takes away a little of that gunslinger freedom, but
> > then you don't have to use them.
> > 
> 
> Yes, I agree that the stricter type checking is generally considered a
> 'good thing' from a computer science perspective, and I mostly agree with
> that.  However, it's probably more of an emotional issue for me--just 
> something that I like--and I'm not ready to give it up just yet.
> 
Yes, all rules seem to have so many exceptions that it is hard to call
them rules 
I think that most of the versatility of Eu remains, and you don't really
lose the dynamic typing.

struct myvars is
      object flag
      sequence bits
    end struct

Now myvars.flag or myvars.bits[1] can hold can hold anything.

You have 'type freedom' but you still have namespacing, the
documentation provided by the name, a convenient way to group related
things (and some other things).

Note that 'flag' and 'bits' above are initialized

?myvars.flag  --> "0"
    ?myflags.bits  --> "{}"

KtB

15. Re: Eu Improvements consolidation

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

Bernie Ryan wrote:
> 
> Karl Bochert wrote:
> > 
> > Yes, all rules seem to have so many exceptions that it is hard to call
> > them rules 
> > I think that most of the versatility of Eu remains, and you don't really
> > lose the dynamic typing.
> > }}}
<eucode>
> >     struct myvars is
> >       object flag
> >       sequence bits
> >     end struct
> > </eucode>
{{{

> > Now myvars.flag or myvars.bits[1] can hold can hold anything.
> > 
> > You have 'type freedom' but you still have namespacing, the
> > documentation provided by the name, a convenient way to group related
> > things (and some other things).
> > 
> > Note that 'flag' and 'bits' above are initialized
> > }}}
<eucode>
> >     ?myvars.flag  --> "0"
> >     ?myflags.bits  --> "{}"
> > </eucode>
{{{

> > 
> > KtB
> 
>     What about user defined types ?
> 
> Bernie
>
As I think you would expect:

type pos_atom(atom q)
        return q > 0
    end type

    struct Point_urquadrant is
        pos_atom a, y
    end struct
    Point_urquadrant.x = -2.0

KtB