1. Eu improvements (part 4)

Consider:
sequence wdlist   -- a list of words
    --
    -- Add a new word to a list of words and warn if some
    -- condition is met
    --
    function add(sequence wordlist, sequence newword)
        integer warn
        append(wordlist, newword)
        ...    -- check for warning
        prepend(wordlist, warn)
        return wordlist
    end function

    result = add(wordList, "new")
    wdlist = result[2]
    if result[1] == WARN then
        ...

(did I do that right??!?)
. The function add() really should do what it says - add a word to the list.
. Instead it must return a new list - Eu cannot modify its parameters.
. The wdlist is copied several times -- it may be very large.
. Returning a flag is awkward when the return value must be used for the list
There are other ways to do this, but they all have serious flaws.

It would be helpful if add() could be allowed to modify the list argument,
but unrestrained pass-by-reference is very non-euphoric.

Allow pass by reference only for the first argument of a function or
procedure, and only if it is a sequence.
This restricts PBR to only certain circumstances.

When PBR is used, indicate it with a distinct syntax. 
Pull the first argument out of the parenthesis, and place it in front
of the function name to indicate that it is a reference. (separate it
from the functon name with a dot).
Use the same syntax when defining the function.
sequence wdlist  -- a list of words

    --
    -- Add a new word to a list of words and warn if some
    -- condition is met
    --
    function wdlist.add(sequence newword) --wdlist parameter must be a seq
        append(wdlist, newword)   
        ...    -- check for warning
        return warn
    end function

    if wdlist.add("new") == WARN then  
        ...

Both the function and its use are cleaner and more understandable.
The function add() really does add a word to the wdlist.
Another way to understand 'wdlist.add()' is that it is saying "modify
wdlist with the function add()"

KtB

new topic     » topic index » view message » categorize

2. Re: Eu improvements (part 4)

Karl Bochert wrote:
> 
> . The function add() really should do what it says - add a word to the list.

Then you'd want something like this:

http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=6&fromYear=B&toMonth=8&toYear=B&postedBy=cklester&keywords=Updating+parameters+in+a+procedure+%2F+function

-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/

new topic     » goto parent     » topic index » view message » categorize

3. Re: Eu improvements (part 4)

cklester wrote:
> 
> Karl Bochert wrote:
> > 
> > . The function add() really should do what it says - add a word to the list.
> 
> Then you'd want something like this:
> 
>     <a
>     href="http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=6&fromYear=B&toMonth=8&toYear=B&postedBy=cklester&keywords=Updating+parameters+in+a+procedure+%2F+function">http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=6&fromYear=B&toMonth=8&toYear=B&postedBy=cklester&keywords=Updating+parameters+in+a+procedure+%2F+function</a>
> 
> -=ck
> "Programming in a state of Euphoria."
> <a
> href="http://www.cklester.com/euphoria/">http://www.cklester.com/euphoria/</a>

A very nicely presented workaround for the lack of PBR.
Whats remarkable is the hoops you must jump through.
Your example using this version of PBR:
function list.addItem(object item)
        append(list, item)
    end function
   function list.getItemIdx(object item)
    -- PBR not needed for this fct, but what the heck
        return find(item, list)
    end function


    procedure main()
        sequence myCars, myPhones, myGirlFriends
        atom idx
        myCars = {}  myPhones = {}  myGirlFriends = {}
--? do I need these inits?  why?   how do I put them in addItem()?

        mycars.addItem("Porche")
        myPhones.addItem("123-456-7890");
        myGirlFriends.addItem("Jennifer Aniston")
        -- no reason for another way to add items
 
        -- get the index
        mycars.add("Porche")
        idx = mycars.getItemIdx("Porche")
        -- again, other ways are not needed or desireable
    end procedure

A remarkable increase in brevity and clarity (and faster).

KtB

new topic     » goto parent     » topic index » view message » categorize

4. Re: Eu improvements (part 4)

Karl Bochert wrote:
> cklester wrote:
> > Karl Bochert wrote:
> > > . The function add() really should do what it says - add a word to the
> > > list.
> > Then you'd want something like this:
> >     <a
> >     href="http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=6&fromYear=B&toMonth=8&toYear=B&postedBy=cklester&keywords=Updating+parameters+in+a+procedure+%2F+function">http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=6&fromYear=B&toMonth=8&toYear=B&postedBy=cklester&keywords=Updating+parameters+in+a+procedure+%2F+function</a>
> A very nicely presented workaround for the lack of PBR.
> Whats remarkable is the hoops you must jump through.
> Your example using this version of PBR:
> }}}
<eucode>
>     function list.addItem(object item)
>         append(list, item)
>     end function
>    function list.getItemIdx(object item)
>     -- PBR not needed for this fct, but what the heck
>         return find(item, list)
>     end function
> 
>     procedure main()
>         sequence myCars, myPhones, myGirlFriends
>         atom idx
>         myCars = {}  myPhones = {}  myGirlFriends = {}
> --? do I need these inits?  why?   how do I put them in addItem()?

It would work a little differently for OOP. You'd need something like the
following:

myCars = newObject("myCars") -- myCars previously defined as a holder of car
records
-- this is just an index to the internal list of
                             objects
auto = newObject("automobile") -- automobile previously defined as a record of
car data
-- this is just an index to the internal list of
                               objects
property(auto,"maker","Ford")

-- then to add the automobile to the myCars list/db:
addObject(myCars,auto) -- or somesuch

This is possible without any change to Euphoria right now. I bet some
current incarnation of a Euphoria OOP library does this exact thing.
Dot notation will be syntactic sugar, right? Not that there's anything
wrong with that. :)

new topic     » goto parent     » topic index » view message » categorize

5. Re: Eu improvements (part 4)

I messed up the paradigm... here it is corrected:

c.k.lester wrote:
> 
> It would work a little differently for OOP. You'd need something like the
> following:
> 
> myCars = newObject("myCars") -- myCars previously defined as a holder of car
> records
>                              -- this is just an index to the internal list of

newInstance("automobile_database","myCars")

so 'myCars' is now a database of automobiles.

> objects
> auto = newObject("automobile") -- automobile previously defined as a record
> of car data
>                                -- this is just an index to the internal list

this really should be

auto = newInstance("automobile")

or better

newInstance("automobile","auto1")

which creates a new automobile called auto1.

With this paradigm, we have no global constants required.

> of objects
> property(auto,"maker","Ford")

-- modify a property
property("auto1","maker","Ford")

> -- then to add the automobile to the myCars list/db:
> addObject(myCars,auto) -- or somesuch

-- add the auto to the database
addObject("myCars","auto1")

> This is possible without any change to Euphoria right now. I bet some
> current incarnation of a Euphoria OOP library does this exact thing.
> Dot notation will be syntactic sugar, right? Not that there's anything
> wrong with that. :)

new topic     » goto parent     » topic index » view message » categorize

6. Re: Eu improvements (part 4)

c.k.lester wrote:
> 
> I messed up the paradigm... here it is corrected:
> 
> c.k.lester wrote:
> >
<snip earlier messages> 
> 
> newInstance("automobile_database","myCars")
> 
> so 'myCars' is now a database of automobiles.
> 

> 
> this really should be
> 
> auto = newInstance("automobile")
> 
> or better
> 
> newInstance("automobile","auto1")
> 
> which creates a new automobile called auto1.
> 
> With this paradigm, we have no global constants required.
> 
> 
> -- modify a property
> property("auto1","maker","Ford")
> 
> 
> -- add the auto to the database
> addObject("myCars","auto1")
> 
This 'OOP as a mindset for using functions' may work for some, but I find
it very difficult to read or understand.

My posts were about 2 features that might make me a Euphorian again:
  .  Pass By Reference
  .  Structured Sequences
not about OOP or ways to implement it.

It happens that these features would allow OOP proponents to create
much improved OOP libraries, with which they could write advanced
OOP programs which would mystify me.
That's OK - after all I already find many Euphoria programmers
complex use of sequences terrifying.
The goal of these features is to allow a programmer to write programs
that more easily read and understood. Period.

With that in mind, I would ask those who disagree which category
they place themselves in:
1) Good ideas, but flawed implementation
2) I don't like PBR
3) I don't like SS
4) Both are instruments of the devil
5) Irrelevant  -- Euphoria is perfect

Ktb

new topic     » goto parent     » topic index » view message » categorize

7. Re: Eu improvements (part 4)

Karl Bochert wrote:
> This 'OOP as a mindset for using functions' may work for some, but I find
> it very difficult to read or understand.
> 
> My posts were about 2 features that might make me a Euphorian again:
>   .  Pass By Reference
>   .  Structured Sequences
> not about OOP or ways to implement it.
> 
> It happens that these features would allow OOP proponents to create
> much improved OOP libraries, with which they could write advanced
> OOP programs which would mystify me.
> That's OK - after all I already find many Euphoria programmers
> complex use of sequences terrifying.
> The goal of these features is to allow a programmer to write programs
> that more easily read and understood. Period.
> 
> With that in mind, I would ask those who disagree which category
> they place themselves in:
> 1) Good ideas, but flawed implementation
> 2) I don't like PBR
> 3) I don't like SS
> 4) Both are instruments of the devil
> 5) Irrelevant  -- Euphoria is perfect
> 
> Ktb

Hmm. I dunno if I can categorize very easily. Maybe I should put myself in #1.

I don't really like SS but I like the idea of dot notation. They really aren't
quite the same thing. I just like weaker types but there should be a better way
than defining a bunch of global constants.

Regarding PBR, I haven't really seen any good ideas regarding it yet. I think it
should be possible maybe with the addition of a keyword in the function or
procedure definition. PBR is only really needed for either very large sequences
or for medium sequences that are accessed very many times. Plus there are ways of
working around it (again, using globals though).


--
"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.

new topic     » goto parent     » topic index » view message » categorize

8. Re: Eu improvements (part 4)

Karl Bochert wrote:
> c.k.lester wrote:
> > I messed up the paradigm... here it is corrected:
> > c.k.lester wrote:
> <snip earlier messages> 
> > newInstance("automobile_database","myCars")
> > so 'myCars' is now a database of automobiles.
> > this really should be
> > auto = newInstance("automobile")
> > or better
> > newInstance("automobile","auto1")
> > which creates a new automobile called auto1.
> > With this paradigm, we have no global constants required.
> > -- modify a property
> > property("auto1","maker","Ford")
> > -- add the auto to the database
> > addObject("myCars","auto1")
> This 'OOP as a mindset for using functions' may work for some, but I find
> it very difficult to read or understand.

I was simply applying my lists functionality to OOP functionality (I thought
you were wanting OOP stuff). It basically has nothing to do with OOP, but can
be used in that way.

> My posts were about 2 features that might make me a Euphorian again:
>   .  Pass By Reference

Don't know why this is needed. Can you give an example where PBR is required?

>   .  Structured Sequences

Yes. Gimme. :)

> not about OOP or ways to implement it.

Sorry, that was just a tangent I thought I was following you on! heh.

> With that in mind, I would ask those who disagree which category
> they place themselves in:
> 1) Good ideas, but flawed implementation
> 2) I don't like PBR
> 3) I don't like SS
> 4) Both are instruments of the devil
> 5) Irrelevant  -- Euphoria is perfect

I'm in the "Euphoria is perfect... and would be even more perfect with
structured sequences!" :D

Adding structured sequences would not break anything, and would give us
a more powerful language syntax but still keep it all simple.

type text(sequence s)
   return is_all_ascii( s )
end type

sequence Company is
   text name
   Address headquarters
   --...
end sequence

sequence automobile is
     Company maker
     text model
     atom year
   --...
end sequence


Although, I still don't like the use of static variable names. For example,
what if we create a huge program with lots of includes and code and has the
automobile.maker text all throughout but we want to change the definition to
Company manufacturer at some point, thus breaking all that code (which now
needs to be automobile.manufacturer)?

Oh, well, this should all be in a database anyway. :)

How about instead of

sequence Company is
   --...
end sequence

we use

record Company
   --...
end record

because that's really what it seems to be: a database record.

new topic     » goto parent     » topic index » view message » categorize

9. Re: Eu improvements (part 4)

Jason Gade wrote:
> 
> Karl Bochert wrote:

> > With that in mind, I would ask those who disagree which category
> > they place themselves in:
> > 1) Good ideas, but flawed implementation
> > 2) I don't like PBR
> > 3) I don't like SS
> > 4) Both are instruments of the devil
> > 5) Irrelevant  -- Euphoria is perfect
> > 
> > Ktb
> 
> Hmm. I dunno if I can categorize very easily. Maybe I should put myself in #1.
> 
> I don't really like SS but I like the idea of dot notation. They really aren't
> quite the same thing. I just like weaker types but there should be a better
> way than defining a bunch of global constants.
>
Do you object to others using SS? Why?
Perhaps what you want is not to avoid SS, but to extend it??
sequence colors is
    constant
        blue = 3, red = 1
  end sequence
  ?length(colors)  --> 0 
  ?colors.blue     --> 3

 
> Regarding PBR, I haven't really seen any good ideas regarding it yet. I think
> it should be possible maybe with the addition of a keyword in the function or
> procedure definition. PBR is only really needed for either very large
> sequences
> or for medium sequences that are accessed very many times. Plus there are ways
> of working around it (again, using globals though).
> 

Excessive global variables is one of the things that makes it hard for me to
comprehend (large) Eu programs. Namespace pollution and loss of locality --
a global can be changed ANYWHERE!
For me, the real advantage of PBR is that it allows a function to modify
one of its parameters AND return a flag (without using a global or an
extraneous sequence)


KtB

new topic     » goto parent     » topic index » view message » categorize

10. Re: Eu improvements (part 4)

Karl Bochert wrote:
> 
> Jason Gade wrote:
> > 
> > Karl Bochert wrote:
> 
> > > With that in mind, I would ask those who disagree which category
> > > they place themselves in:
> > > 1) Good ideas, but flawed implementation
> > > 2) I don't like PBR
> > > 3) I don't like SS
> > > 4) Both are instruments of the devil
> > > 5) Irrelevant  -- Euphoria is perfect
> > > 
> > > Ktb
> > 
> > Hmm. I dunno if I can categorize very easily. Maybe I should put myself in
> > #1.
> > 
> > I don't really like SS but I like the idea of dot notation. They really
> > aren't
> > quite the same thing. I just like weaker types but there should be a better
> > way than defining a bunch of global constants.
> >
> Do you object to others using SS? Why?
No, I just don't think I'm explaining myself very well. Maybe because I don't
completely know what I want either smile

> Perhaps what you want is not to avoid SS, but to extend it??
> }}}
<eucode>
>   sequence colors is
>     constant
>         blue = 3, red = 1
>   end sequence
>   ?length(colors)  --> 0 
>   ?colors.blue     --> 3
> </eucode>
{{{

I'm not sure what you mean here... I guess something like that. There's a thread
by James W. Hoffman which I think has a pretty good idea for implementation.

> > Regarding PBR, I haven't really seen any good ideas regarding it yet. I
> > think
> > it should be possible maybe with the addition of a keyword in the function
> > or
> > procedure definition. PBR is only really needed for either very large
> > sequences
> > or for medium sequences that are accessed very many times. Plus there are
> > ways
> > of working around it (again, using globals though).
> > 
> 
> Excessive global variables is one of the things that makes it hard for me to
> comprehend (large) Eu programs. Namespace pollution and loss of locality --
> a global can be changed ANYWHERE!
> For me, the real advantage of PBR is that it allows a function to modify
> one of its parameters AND return a flag (without using a global or an
> extraneous sequence)
> 
> 
> KtB
I'm not really arguing with the need for it, just that I haven't seen a good
implementation. I know I've discussed with Rob on this list before whether it
could be done transparently. That is if the compiler recognizes a pattern like
this:
mySeq = DoSomethingTo(mySeq)

and avoid making a copy that would be good. I guess you lose your return flag
that you mention above, though. And you wouldn't be able to do it with a
procedure.

One problem with PBR is that it shouldn't surprise the programmer. Surprise
and/or side-effects can be a source of bugs. So another suggestion would be to
use a keyword in the function definition so it is explicit. Hmm. I tried to come
up with an example but I don't have one.

Anyway I'm just reading and thinking about these things. Part of me likes
Euphoria just the way it is and part of me would like to see improvements made.

--
"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.

new topic     » goto parent     » topic index » view message » categorize

11. Re: Eu improvements (part 4)

c.k.lester wrote:
> 
 
> > My posts were about 2 features that might make me a Euphorian again:
> >   .  Pass By Reference
> 
> Don't know why this is needed. Can you give an example where PBR is required?
> 
Not needed, just desireable. The minor advantage is speed when dealing
with large sequences (we like Eu for its speed, right?) A much bigger
advantage is that it allows a flag to be returned cleanly.

> >   .  Structured Sequences
> 
> Yes. Gimme. :)
> 
> > not about OOP or ways to implement it.
> 
> Sorry, that was just a tangent I thought I was following you on! heh.
> 
A tangent that traps many on this list, I think.

> > With that in mind, I would ask those who disagree which category
> > they place themselves in:
> > 1) Good ideas, but flawed implementation
> > 2) I don't like PBR
> > 3) I don't like SS
> > 4) Both are instruments of the devil
> > 5) Irrelevant  -- Euphoria is perfect
> 
> I'm in the "Euphoria is perfect... and would be even more perfect with
> structured sequences!" :D
> 
> Adding structured sequences would not break anything, and would give us
> a more powerful language syntax but still keep it all simple.
>
And thid is not true of PBR?
 
> }}}
<eucode>
> type text(sequence s)
>    return is_all_ascii( s )
> end type
> 
> sequence Company is
>    text name
>    Address headquarters
>    --...
> end sequence
> 
> sequence automobile is
>      Company maker
>      text model
>      atom year
>    --...
> end sequence
> </eucode>
{{{

> 
> Although, I still don't like the use of static variable names. For example,
> what if we create a huge program with lots of includes and code and has the
> automobile.maker text all throughout but we want to change the definition to
> Company manufacturer at some point, thus breaking all that code (which now
> needs to be automobile.manufacturer)?
>
No different than occurs now when any other id is changed.
 
> Oh, well, this should all be in a database anyway. :)
> 
> How about instead of
> 
> sequence Company is
>    --...
> end sequence
> 
> we use
> 
> record Company
>    --...
> end record
>
> because that's really what it seems to be: a database record.
Wouldn't bother me!

KtB

new topic     » goto parent     » topic index » view message » categorize

12. Re: Eu improvements (part 4)

Karl Bochert wrote:
> 
> Do you object to others using SS? Why?
> Perhaps what you want is not to avoid SS, but to extend it??
>   sequence colors is
>     constant
>         blue = 3, red = 1
>   end sequence
>   ?length(colors)  --> 0 
>   ?colors.blue     --> 3

This is basically what ooeu does (although you don't have to declare what
the constants will be).  They're defined similar to an enum:
euclass foo( sequence f )
    integer bar, baz
end euclass

? foo.bar   -- output 1
? foo.baz   -- output 2


Matt

new topic     » goto parent     » topic index » view message » categorize

13. Re: Eu improvements (part 4)

Ya know, I wonder if we should just stick with the improvements that Matt has
made with ooeu...

--
"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.

new topic     » goto parent     » topic index » view message » categorize

14. Re: Eu improvements (part 4)

Jason Gade wrote:
> 
> > Perhaps what you want is not to avoid SS, but to extend it??
> > }}}
<eucode>
> >   sequence colors is
> >     constant
> >         blue = 3, red = 1
> >   end sequence
> >   ?length(colors)  --> 0 
> >   ?colors.blue     --> 3
> > </eucode>
{{{

> I'm not sure what you mean here... I guess something like that. There's a
> thread
> by James W. Hoffman which I think has a pretty good idea for implementation.
> 
Extend the SS syntax to allow constants as elements that do not appear
in the sequence, or as normal sequence elements that are read-only.
Just a back-door enum.

I'd look at Hoffman's thead if I could find it.

> > > Regarding PBR, I haven't really seen any good ideas regarding it yet. I
> > > think
> > > it should be possible maybe with the addition of a keyword in the function
> > > or
> > > procedure definition. PBR is only really needed for either very large
> > > sequences
> > > or for medium sequences that are accessed very many times. Plus there are
> > > ways
> > > of working around it (again, using globals though).
> > > 
> > 
> > Excessive global variables is one of the things that makes it hard for me to
> > comprehend (large) Eu programs. Namespace pollution and loss of locality --
> > a global can be changed ANYWHERE!
> > For me, the real advantage of PBR is that it allows a function to modify
> > one of its parameters AND return a flag (without using a global or an
> > extraneous sequence)
> > 
> > 
> > KtB
> I'm not really arguing with the need for it, just that I haven't seen a good
> implementation. I know I've discussed with Rob on this list before whether it
> could be done transparently. That is if the compiler recognizes a pattern like
> this:
> }}}
<eucode>
> mySeq = DoSomethingTo(mySeq)
> </eucode>
{{{

> and avoid making a copy that would be good. I guess you lose your return flag
> that you mention above, though. And you wouldn't be able to do it with a
> procedure.
> 
I think the reurn value is the most important advantage.
I think transparency here is bad. PBR is different than normal parameter
passing, and I want to know which is being used when I read the code.
As an aside, this is what bothers me so much about OOP programming. So
much is being done transparently (behind my back) that reading the code
gives me no idea what is actually happening.

> One problem with PBR is that it shouldn't surprise the programmer. Surprise
> and/or side-effects can be a source of bugs. So another suggestion would be
> to use a keyword in the function definition so it is explicit. Hmm. I tried
> to come up with an example but I don't have one.
> 
Yes, make it obvious.
I considered things like
    add(!list, item)
using the bang to indicate pass-by reference.
I chose the presented
    list.add(item)
because it allows another feature that is arguably more important
than any other feature of PBR.
'add' does NOT have to be in the global namespace but can be
local to the list.


> Anyway I'm just reading and thinking about these things. Part of me likes
> Euphoria
> just the way it is and part of me would like to see improvements made.
> 
I discarded Euphoria when I discovered that I was not able to easily 
write or understand even moderately sized programs. For me, clarity of
the resultant code is the measure of all features.

> --
> "Any programming problem can be solved by adding a level of indirection."
> --anonymous
 "at the expense of comprehensibility"
 --KtB

> "Any performance problem can be solved by removing a level of indirection."
> --M. Haertel
 "at the expense of comprehensibility"
  --KtB

> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
 "unless it improves comprehensibility"
  --KtB


KtB

new topic     » goto parent     » topic index » view message » categorize

15. Re: Eu improvements (part 4)

Matt Lewis wrote:
> 
> Karl Bochert wrote:
> > 
> > Do you object to others using SS? Why?
> > Perhaps what you want is not to avoid SS, but to extend it??
> }}}
<eucode>
> >   sequence colors is
> >     constant
> >         blue = 3, red = 1
> >   end sequence
> >   ?length(colors)  --> 0 
> >   ?colors.blue     --> 3
> </eucode>
{{{

> This is basically what ooeu does (although you don't have to declare what
> the constants will be).  They're defined similar to an enum:
> }}}
<eucode>
> euclass foo( sequence f )
>     integer bar, baz
> end euclass
> 
> ? foo.bar   -- output 1
> ? foo.baz   -- output 2
> </eucode>
{{{

> 
> Matt

Sorry for the double post--

Do bar and baz have any meaning outside of the context of foo? Do they have any
value that you can check?

If you have another object, moo, that doesn't have bar or baz in it's definition
(but does have something in that placeholder) does moo.bar or moo.baz have any
meaning?

Last question--are foo.bar and foo[bar] interchangeable?
--
"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.

new topic     » goto parent     » topic index » view message » categorize

16. Re: Eu improvements (part 4)

Karl Bochert wrote:

> I'd look at Hoffman's thead if I could find it.
It was actually in your part I thread:
http://www.listfilter.com/EUforum/m11619.html
--
"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.

new topic     » goto parent     » topic index » view message » categorize

17. Re: Eu improvements (part 4)

Matt Lewis wrote:
> 
> Karl Bochert wrote:
> > 
> > Do you object to others using SS? Why?
> > Perhaps what you want is not to avoid SS, but to extend it??
> }}}
<eucode>
> >   sequence colors is
> >     constant
> >         blue = 3, red = 1
> >   end sequence
> >   ?length(colors)  --> 0 
> >   ?colors.blue     --> 3
> </eucode>
{{{

> This is basically what ooeu does (although you don't have to declare what
> the constants will be).  They're defined similar to an enum:
> }}}
<eucode>
> euclass foo( sequence f )
>     integer bar, baz
> end euclass
> 
> ? foo.bar   -- output 1
> ? foo.baz   -- output 2
> </eucode>
{{{

> 

I understand that an OOp system can declare member variables.
But again, I am not proposing OOP  I am proposing SS and PBR.

If people want OOP then new features such as PBR and SS are not
necessary - they just start their program with
include "ooeu.e"  -- (or whatever your library is named)


Ktb

new topic     » goto parent     » topic index » view message » categorize

18. Re: Eu improvements (part 4)

Jason Gade wrote:
> 
> Ya know, I wonder if we should just stick with the improvements that Matt has
> made with ooeu...
>
Yes, if you want OOP, you already have it.

KtB

new topic     » goto parent     » topic index » view message » categorize

19. Re: Eu improvements (part 4)

But it isn't a library--it's a different interpreter that is mostly compatible
with RDS Euphoria.

It includes a lot of features discussed on the list over the years. Plus it has
a graphical debugger!

I don't really want OOP so much, but classes are almost the same as structures.

That's all I'm saying here.

--
"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.

new topic     » goto parent     » topic index » view message » categorize

20. Re: Eu improvements (part 4)

Jason Gade wrote:

> > }}}
<eucode>
> > euclass foo( sequence f )
> >     integer bar, baz
> > end euclass
> > 
> > ? foo.bar   -- output 1
> > ? foo.baz   -- output 2
> > </eucode>
{{{

> > 
> > Matt
> 
> Sorry for the double post--
> 
> Do bar and baz have any meaning outside of the context of foo? Do they have
> any value that you can check?
> 
> If you have another object, moo, that doesn't have bar or baz in it's
> definition
> (but does have something in that placeholder) does moo.bar or moo.baz have any
> meaning?

No, they are completely encapsulated within foo.  Like C++ compilers,
ooeu decorates variable and routine names to keep them separate.  Here is
the disassembled output:

SubProgram [_toplevel_:00118]
     1: 018 125 123                      # [LIT 1:125] => [bar@foo:123]
     4: 018 126 124                      # [LIT 2:126] => [baz@foo:124]
     7: 036 125 123                      # QPRINT: [bar@foo:123]
    10: 036 125 124                      # QPRINT: [baz@foo:124]
    13: 034                              # RETURNT:
End SubProgram [_toplevel_:00118]

The decoration scheme is actually pretty simple.  For these constants,
I append a '@' and add the class name.  For routines, I tack on the
arguments for the routine, with any class names prepended and appended
with '@'s, and use o, a, i, s for anything else (corresponding to the
obvious native euphoria data types).

So if you really, really wanted to use bar with moo, you could:
? moo[foo.bar]

In the same vein, it's also possible to 'cast' objects for the purpose of
calling routines (at the risk of throwing out too much at once):
euclass foo( sequence f )
    integer bar, baz
    function foo( integer bar, integer baz ) : foo
        foo this
        this = repeat( 0, 2 )
        this.bar = bar
        this.baz = baz
        return this
    end function
    
    procedure print()
        ? this.bar
        ? this.baz
    end procedure
end euclass

foo f
f = foo( 1, 2 )
f.print()

sequence s
s = {1,2}
foo.print( s )

And again, the disassembled output:

SubProgram [_toplevel_:00118]
     1: 018 125 123                      # [LIT 1:125] => [bar@foo:123]
     4: 018 126 124                      # [LIT 2:126] => [baz@foo:124]
7: 027 127 125 126 138              # FUNC: [foo@ii:127], [LIT 1:125][LIT
     2:126]
                                         #     => [f:138]
    12: 097 138                          # SEQUENCE_CHECK: [f:138]
    14: 027 133 138                      # PROC: [print@foo@:133][f:138]
    17: 018 141 140                      # [LIT {1,2}:141] => [s:140]
    20: 058 23                           # STARTLINE: ref_example.exw(23)<<>>
    22: 027 133 140                      # PROC: [print@foo@:133][s:140]
    25: 034                              # RETURNT:
End SubProgram [_toplevel_:00118]

Note that lines 14 and 22 (the lines that call foo.print) look the same,
except for the parameter, of course.

SubProgram [foo@ii:00127]
     1: 096 128                          # INTEGER_CHECK: [bar:128]
     3: 096 129                          # INTEGER_CHECK: [baz:129]
5: 032 131 126 130                  # REPEAT: [LIT 0:131], [LIT 2:126] =>
     [this:130]
9: 118 130 123 128                  # ASSIGN_SUBS_I: [this:130],
     [bar@foo:123]
                                         #     <= [bar:128]
    13: 097 130                          # SEQUENCE_CHECK: [this:130]
15: 118 130 124 129                  # ASSIGN_SUBS_I: [this:130],
    [baz@foo:124]
                                         #     <= [baz:129]
    19: 097 130                          # SEQUENCE_CHECK: [this:130]
    21: 028 127 130                      # RETURNF: [this:130]
    24: 043                              # BADRETURNF:
End SubProgram [foo@ii:00127]

SubProgram [print@foo@:00133]
     1: 097 134                          # SEQUENCE_CHECK: [this:134]
3: 025 134 123 136                  # RHS_SUBS: [this:134] sub
     [bar@foo:123] =>
                                         #     [_temp_:136]
     7: 036 125 136                      # QPRINT: [_temp_:136]
10: 025 134 124 136                  # RHS_SUBS: [this:134] sub
    [baz@foo:124] =>
                                         #     [_temp_:136]
    14: 036 125 136                      # QPRINT: [_temp_:136]
    17: 029 133                          # RETURNP
End SubProgram [print@foo@:00133]

Matt

new topic     » goto parent     » topic index » view message » categorize

21. Re: Eu improvements (part 4)

Karl Bochert wrote:

> 
> I understand that an OOp system can declare member variables.
> But again, I am not proposing OOP  I am proposing SS and PBR.
> 
> If people want OOP then new features such as PBR and SS are not
> necessary - they just start their program with
> }}}
<eucode>
>    include "ooeu.e"  -- (or whatever your library is named)
> </eucode>
{{{


I know what you're saying.  As Jason pointed out, ooeu isn't a 
library (although you can embed it in your program as a scripting 
engine that way).

The main point of ooeu is to have a place to really try out some of the
ideas that get thrown around here over the years.  However, the way I've
implemented OOP is very similar to your concept of SS, and gives people
a way to play with this sort of thing in a working interpreter (I've 
gotten the translator to work with many ooeu features, too, BTW).

Matt

new topic     » goto parent     » topic index » view message » categorize

22. Re: Eu improvements (part 4)

Jason Gade wrote:
> 
> Ya know, I wonder if we should just stick with the improvements that Matt has
> made with ooeu...

I don't count goto as an improvement. :D

Besides, he said he did some of those things just because he could (or wanted
to try). I suspect he would not want to incorporate all of those modifications
into standard Euphoria.

new topic     » goto parent     » topic index » view message » categorize

23. Re: Eu improvements (part 4)

Matt Lewis wrote:

> euclass foo( sequence f )
>     integer bar, baz
>     function foo( integer bar, integer baz ) : foo
>         foo this
>         this = repeat( 0, 2 )
>         this.bar = bar
>         this.baz = baz
>         return this
>     end function
>     
>     procedure print()
>         ? this.bar
>         ? this.baz
>     end procedure
> end euclass

By this, don't we then already have structured sequences (SS) in Euphoria?!?!

-- simple example
euclass Address( sequence s )
   atom street_number
   sequence street_name
   sequence city
   sequence state
   atom zip_number
   atom zip_plus4
end euclass

This seems to allow both structured sequences (at its simplest) and advanced
objects (at its most complex).

address myAddress -- create your new structured sequence
  myAddress.street_number = 1234
  myAddress.street_name = "Independence Pkwy"

It's just called a euclass instead of a sequence/record/etc.

new topic     » goto parent     » topic index » view message » categorize

24. Re: Eu improvements (part 4)

Jason Gade wrote:
> 
> Karl Bochert wrote:
> 
> > I'd look at Hoffman's thead if I could find it.
> It was actually in your part I thread: <a
> href="http://www.listfilter.com/EUforum/m11619.html">http://www.listfilter.com/EUforum/m11619.html</a>

Ahh.
He presents an alternative syntax for naming elements which you may
prefer. It does not provide SS, nor, as far as I can see, enums.

 
KtB

new topic     » goto parent     » topic index » view message » categorize

25. Re: Eu improvements (part 4)

Matt Lewis wrote:
> 
> Karl Bochert wrote:
> 
> > 
> > I understand that an OOp system can declare member variables.
> > But again, I am not proposing OOP  I am proposing SS and PBR.
> > 
> > If people want OOP then new features such as PBR and SS are not
> > necessary - they just start their program with
> > }}}
<eucode>
> >    include "ooeu.e"  -- (or whatever your library is named)
> > </eucode>
{{{

> 
> I know what you're saying.  As Jason pointed out, ooeu isn't a 
> library (although you can embed it in your program as a scripting 
> engine that way).
> 
> The main point of ooeu is to have a place to really try out some of the
> ideas that get thrown around here over the years.
>  However, the way I've
> implemented OOP is very similar to your concept of SS, and gives people
> a way to play with this sort of thing in a working interpreter (I've 
> gotten the translator to work with many ooeu features, too, BTW).
> 
> Matt
So basically OOEU fulfills your needs and you are uninterested in adding
SS or PBR to the language.

-- rant --
I was hoping that the introduction of open Eu might have allowed
some advances  to what is (lets face it) a toy language.
I make a suggestion for what I think is a powerful and simple feature (SS).
The only response is "You can do some of that with OOEU" - "XYZ's
package does some of that this way" etc. etc. I am starting to
understand that the translation of these responses is "Not Interested, but
heres something else to talk about".
OK, I'll stop.

The other thing I notice is that RC is totally silent. Is he waiting for
unanimity? Will he bless any change at all? Without his input, none of
this means anything at all.
I seem to have forgotten this in my years away from Eu.

- end of rant -
KtB

new topic     » goto parent     » topic index » view message » categorize

26. Re: Eu improvements (part 4)

Karl Bochert wrote:
> -- rant --
> I was hoping that the introduction of open Eu might have allowed
> some advances  to what is (lets face it) a toy language.
> I make a suggestion for what I think is a powerful and simple feature (SS).
> The only response is "You can do some of that with OOEU" - "XYZ's
> package does some of that this way" etc. etc. I am starting to
> understand that the translation of these responses is "Not Interested, but
> heres something else to talk about".
> OK, I'll stop.
> 
> The other thing I notice is that RC is totally silent. Is he waiting for
> unanimity? Will he bless any change at all? Without his input, none of
> this means anything at all.
> I seem to have forgotten this in my years away from Eu.

I understand where you are coming from Karl.

Point 1:
I haven't read all the posts in detail so I'm not 100% of the details ... 
but what features do structures give you that oo doesn't?

I believe OO can be implemented in a very simple easy to understand way.
"If" OO can be added to Euphoria (in a way that doesn't force everyone to use
it) ... what is the disadvantage?

Point 2:
It's pretty disappointing to hear everyone's (well at least a few) peoples 
objections to adding OO features to Euphoria.
Can anyone list all of the other popular and growing languages that don't have
any OO features?
OO doesn't solve all of the problems in the world ... but it does give the 
programmer some powerful tools to solve certain problems very elegantly.

Point 3:
I like that Rob is staying out of it at this stage ... I'm pretty sure he is 
reading everything and is interested in how "the community" can drive forward
Euphoria.

Point 4:
and why I've been staying out of it - almost ;) ...
people can only really be "very vocal" and push hard about the future direction
of Euphoria if they are committed to actually helping do the work.
Everyone's opinions are great to hear ... but unless you can convince some
talented programmer with some time on their hands to implement it ...
nothing is going to happen anyway.


Euphoria's future is still pretty exciting.
Everyone should want Euphoria to have some more features ... but must 
realise it probably won't be "exactly" how they want them.  As long as it moves
forward slowly and well thought out ... any features are a bonus.

Regards,
 
Ray Smith
http://RaymondSmith.com

new topic     » goto parent     » topic index » view message » categorize

27. Re: Eu improvements (part 4)

Karl Bochert wrote:
> Matt Lewis wrote:
> > However, the way I've
> > implemented OOP is very similar to your concept of SS
> So basically OOEU fulfills your needs and you are uninterested in adding
> SS or PBR to the language.

I think what he's saying is that the functionality you desire is in OOEU,
and if we can get consensus amongst Euphoria users, it would be relatively
easy to add it to the primary Euphoria distribution.

> I was hoping that the introduction of open Eu might have allowed
> some advances  to what is (lets face it) a toy language.

I strongly disagree. It's so advanced it's simple. :)

> I make a suggestion for what I think is a powerful and simple feature (SS).
> The only response is "You can do some of that with OOEU" - "XYZ's
> package does some of that this way" etc. etc. I am starting to
> understand that the translation of these responses is "Not Interested, but
> heres something else to talk about".
> OK, I'll stop.

I think your interpretation is skewed... I think it's more of, "Okay, we've
got this functionality in these packages, is it something you think would
work?"

I think it's important, also, to nail down the syntax, which hasn't been done.
Many options have been suggested. Should we vote on it or what?

> The other thing I notice is that RC is totally silent. Is he waiting for
> unanimity? Will he bless any change at all?

Rob?

> Without his input, none of this means anything at all.

I don't know if that's true. Let us get clarification: Rob, will any
requested changes need approval from you, even if there's community
consensus?

new topic     » goto parent     » topic index » view message » categorize

28. Re: Eu improvements (part 4)

c.k.lester wrote:

> Rob?
> 
> > Without his input, none of this means anything at all.
> 
> I don't know if that's true. Let us get clarification: Rob, will any
> requested changes need approval from you, even if there's community
> consensus?


 From:
http://www.listfilter.com/EUforum/m11558.html

"""
However, if a clear majority of Euphoria programmers
wanted it, and someone was prepared to do it, I would
not try to veto it. (I've recently seen what can happen 
to dictators).
"""


Regards,

Ray Smith
http://RaymondSmith.com

new topic     » goto parent     » topic index » view message » categorize

29. Re: Eu improvements (part 4)

Ray Smith wrote:
> c.k.lester wrote:
> > Rob?
> > > Without his input, none of this means anything at all.
> > I don't know if that's true. Let us get clarification: Rob, will any
> > requested changes need approval from you, even if there's community
> > consensus?
>  From:
> <a
> href="http://www.listfilter.com/EUforum/m11558.html">http://www.listfilter.com/EUforum/m11558.html</a>
> 
> """
> However, if a clear majority of Euphoria programmers
> wanted it, and someone was prepared to do it, I would
> not try to veto it. (I've recently seen what can happen 
> to dictators).
> """

Despite Karl's griping (I almost said whining but I'm giving the benefit
of the doubt), then, we have our answer: structured sequences (SS), objects,
whatever you want to call it, will be added if:

1) Euphoria community wants it (how do we determine this?!? majority vote?)
2) Somebody is (or somebodies are) willing to program it

I suggest that since Matt has already developed code that does (or seems to
do) exactly what Karl wants AND appeals to OOP enthusiasts, that it's
a great option to consider adding to the standard Euphoria base. It will not
break any existing code, yet opens up advanced functionality for future
Euphoria programs.

new topic     » goto parent     » topic index » view message » categorize

30. Re: Eu improvements (part 4)

Karl Bochert wrote:
> 

> So basically OOEU fulfills your needs and you are uninterested in adding
> SS or PBR to the language.
> 
> -- rant --
> I was hoping that the introduction of open Eu might have allowed
> some advances  to what is (lets face it) a toy language.
> I make a suggestion for what I think is a powerful and simple feature (SS).
> The only response is "You can do some of that with OOEU" - "XYZ's
> package does some of that this way" etc. etc. I am starting to
> understand that the translation of these responses is "Not Interested, but
> heres something else to talk about".
> OK, I'll stop.

Whoa!  I think you've misinterpreted.  ooeu is based on openEu, and IMHO
is a great place for some of these things to test out, courtesy of me.
I've implemented most of what you're looking for with the SS concept, as
well as an implementation of PBR.  If people are interested in what you're
talking about, they could try it out with ooeu, since there's code that
works right now, as opposed to putting up demo code in a forum message.

 
> The other thing I notice is that RC is totally silent. Is he waiting for
> unanimity? Will he bless any change at all? Without his input, none of
> this means anything at all.
> I seem to have forgotten this in my years away from Eu.
> 
> - end of rant -

I think Rob is watching (or maybe taking a nap--let's face it, there's been
a lot of discussion in a fairly short time, so who knows if he's been 
anywhere near a computer).  There's no need to rush to make a decision
about this.  People can always start working on coding up whatever they
want.  Everybody isn't going to agree with whatever gets developed, so
we need to find a good solution.

Matt

new topic     » goto parent     » topic index » view message » categorize

31. Re: Eu improvements (part 4)

c.k.lester wrote:
> 
> Karl Bochert wrote:
> > Matt Lewis wrote:
> > > However, the way I've
> > > implemented OOP is very similar to your concept of SS
> > So basically OOEU fulfills your needs and you are uninterested in adding
> > SS or PBR to the language.
> 
> I think what he's saying is that the functionality you desire is in OOEU,
> and if we can get consensus amongst Euphoria users, it would be relatively
> easy to add it to the primary Euphoria distribution.
>
Adding it sounds like a good idea to me, but it has nothing to do with the
SS proposal.
 
> > I was hoping that the introduction of open Eu might have allowed
> > some advances  to what is (lets face it) a toy language.
> 
> I strongly disagree. It's so advanced it's simple. :)
It is a simple, elegant and powerful toy. It does not provide a host of
features that are accepted as producing better programs. modules,
exceptions, namespaces, etc.etc. have been invented for a reason.

> 
> > I make a suggestion for what I think is a powerful and simple feature (SS).
> > The only response is "You can do some of that with OOEU" - "XYZ's
> > package does some of that this way" etc. etc. I am starting to
> > understand that the translation of these responses is "Not Interested, but
> > heres something else to talk about".
> > OK, I'll stop.
> 
> I think your interpretation is skewed... I think it's more of, "Okay, we've
> got this functionality in these packages, is it something you think would
> work?"

> I think it's important, also, to nail down the syntax, which hasn't been done.
> Many options have been suggested. Should we vote on it or what?
The syntax is all-important. The face shown by a feature to a large extent 
determines whether better code can be produced. That is why trying out
with OOEU doesn't work. Not because OOEU is bad, but because it is different.

> 
> > The other thing I notice is that RC is totally silent. Is he waiting for
> > unanimity? Will he bless any change at all?
> 
> Rob?
> 
> > Without his input, none of this means anything at all.
> 
> I don't know if that's true. Let us get clarification: Rob, will any
> requested changes need approval from you, even if there's community
> consensus?
He has said that he would bow to consensus, but don't we all know that
consensus is impossible?
SS is proposed.
Not one response says:
"I'm for that"
or "I'm against any changes"
or "I want that  but I hate the syntax"
or even "You're crazy"
instead every response is a change of subject.
"Have you seen xyz"
"Thats similar to abc"

Everyone simply wants his pet syntax added, or wants
no changes at all. (I choose not to dwell on my inclusion in 'everyone' smile)

Well heres the gauntlet.
My SS proposal is on the table.
Yes, No, only with changes, or yes but consider this syntax first?

The proposal is SS.
The proposal is NOT dot-notation, NOT named elements,
NOT namespaced ids, NOT a new syntax for user-defined datatypes.
It IS a combination of all those things in a coherent package.

For or Against?

KtB

 

KtB

new topic     » goto parent     » topic index » view message » categorize

32. Re: Eu improvements (part 4)

Karl Bochert wrote:
> Well heres the gauntlet.
> My SS proposal is on the table.
> Yes, No, only with changes, or yes but consider this syntax first?
> 
> The proposal is SS.
> The proposal is NOT dot-notation, NOT named elements,
> NOT namespaced ids, NOT a new syntax for user-defined datatypes.
> It IS a combination of all those things in a coherent package.
> 
> For or Against?
> 
> KtB

Okay, because of your gauntlet I say "no".

My only caveat is the reason people say, "have you seen xyz?" is because that is
our way of saying "yes but consider this syntax first". But since I've given
examples and made discussion I guess that's all I've got.

--
"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.

new topic     » goto parent     » topic index » view message » categorize

33. Re: Eu improvements (part 4)

Karl Bochert wrote:
> c.k.lester wrote:
> Adding it sounds like a good idea to me, but it has nothing to do with the
> SS proposal.

Yeah, it does, actually. It accomplishes what you want to be able to do with
Euphoria. If you can accept typing this:

euclass MySequence
...
end euclass

instead of

sequence MySequence is
...
end sequence

then it does exactly what you want: a structured sequence.

> > > I was hoping that the introduction of open Eu might have allowed
> > > some advances  to what is (lets face it) a toy language.
> > I strongly disagree. It's so advanced it's simple. :)
> It is a simple, elegant and powerful toy. It does not provide a host of
> features that are accepted as producing better programs. modules,
> exceptions, namespaces, etc.etc. have been invented for a reason.

I suspect most of those things have been invented to fix language problems,
NOT improve languages.

Regardless, I'm sure you understand that your request for change isn't going
to happen overnight. It would do you well to be patient and struggle for what
you want instead of assuming you can snap your fingers and get it now.

> He has said that he would bow to consensus, but don't we all know that
> consensus is impossible?

Why do you think that? If we hold a vote and 20 people vote and 11 approve,
that's a majority consensus and the feature gets implemented.

> SS is proposed.
> Not one response says:
> "I'm for that"
> or "I'm against any changes"
> or "I want that  but I hate the syntax"
> or even "You're crazy"
> instead every response is a change of subject.

Your hyperbole leads me to believe this is an emotional issue for you, instead
of one of logic. I agree that perhaps you will be best served by another
language that isn't experiencing a significant change in development
procedures.

> For or Against?

I don't know that this is the best forum for a vote, but if I were
to cast today, my vote is "For structures (by any name)" (as I've already
indicated).

new topic     » goto parent     » topic index » view message » categorize

34. Re: Eu improvements (part 4)

Jason Gade wrote:
> 
> Karl Bochert wrote:
> > Well heres the gauntlet.
> > My SS proposal is on the table.
> > Yes, No, only with changes, or yes but consider this syntax first?
> > 
> > The proposal is SS.
> > The proposal is NOT dot-notation, NOT named elements,
> > NOT namespaced ids, NOT a new syntax for user-defined datatypes.
> > It IS a combination of all those things in a coherent package.
> > 
> > For or Against?
> > 
> > KtB
> 
> Okay, because of your gauntlet I say "no".
Fair enough. 
I suspect that is everyones stand.

KtB

new topic     » goto parent     » topic index » view message » categorize

35. Re: Eu improvements (part 4)

> The proposal is SS.
> The proposal is NOT dot-notation, NOT named elements,
> NOT namespaced ids, NOT a new syntax for user-defined datatypes.
> It IS a combination of all those things in a coherent package.
> 
> For or Against?
> 
> KtB
> 

I'm a "no." 

Your presentation of SS does some things that the type keyword doesn't do
currently, but it loses the precise check-as-function feature. To get both
implies that you make both a SS and a type; that is inelegant - a pollution
of keywords. In addition, SS tries very hard to separate itself from the
original sequence type; there is a lack of clarity in how the code:

sequence point is
     atom x,y
end sequence


actually translates to a REAL sequence. (the only thing implied is that
x comes before y. And then what happens with "extends" is even less clear.)
Even if you do define the behavior in some consistent manner, a reliance
on implied order will cause problems for the programmer who wishes to
mix SS with indexing.

You are welcome to debate on those points, of course.

I will also mention pass-by-reference. I think that is a bad idea for a
different reason; it avoids the real problem, which is an absence of
references! That is what makes complex data structures in Eu hard, more so
than any issue with naming. We instead resort to global variables and code
to maintain counts and other ugly things. References should be done
everywhere, as a new data type, if they're going to be done at all.

(I would even declare the result a "new language"
if it were necessary to do references properly.)

new topic     » goto parent     » topic index » view message » categorize

36. Re: Eu improvements (part 4)

Karl Bochert wrote:
> The other thing I notice is that RC is totally silent. 

I'm skimming through most of it. You have to realize though,
that I've had more than a decade to study most of these issues,
both privately, and on this forum, so they aren't as interesting to
me as they once were. Also, I don't want to jump into
the discussion and pour cold water on any idea until others
have had a fair chance to fully work through the pros and cons.
If I think some big pro or big con has been overlooked, I'll 
eventually chime in. Language design is highly subjective. 
There are very few 100% right or 100% wrong answers.

> Is he waiting for unanimity? 

Definitely not. We'll probably never have unanimity on
any important language design issue.

> Will he bless any change at all? 

Yes. 
If a competent person wants to do something,
and it looks like he/she has a lot of supporters, and few
opponents, I'll probably approve it, even if I'm not in favor
of it.

Language features aren't the only way to improve things.
There's porting, better documentation, a better debugger
etc. These things would not be controversial or difficult
to reach a consensus on.

> Without his input, none of
> this means anything at all.
> I seem to have forgotten this in my years away from Eu.

You've been away too long. Welcome back.
Times have changed.

Moving from dictatorship to democracy is not 
a simple process.  smile

The British royalty were once dictators, but now they
are just figureheads, with the Queen putting her signature
on anything that the elected parliament decides on. There's also the
House of Lords (like the Canadian senate) - old cronies 
who are not elected, but still have a bit of power, and
are supposed to provide "sober second thought" on major changes.

Eventually some sort of informal Euphoria political process 
will emerge. We'll just have to play it by ear for now.
The thing that keeps me honest is that anyone can fork
their own version of Euphoria at any time.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

37. Re: Eu improvements (part 4)

James W Hofmann wrote:
> 
> > The proposal is SS.
> > The proposal is NOT dot-notation, NOT named elements,
> > NOT namespaced ids, NOT a new syntax for user-defined datatypes.
> > It IS a combination of all those things in a coherent package.
> > 
> > For or Against?
> > 
> > KtB
> > 
> 
> I'm a "no." 
> 
> Your presentation of SS does some things that the type keyword doesn't do
> currently, but it loses the precise check-as-function feature. To get both
> implies that you make both a SS and a type; that is inelegant - a pollution
> of keywords.
It is not intended to replace type(). If you want type() functionality you
must use type(). I only showed the type() example to try and explain what
typechecking SS does -- namely it guarantees the length of the sequence and
the datatypes of its elements. 

> In addition, SS tries very hard to separate itself from the
> original sequence type; there is a lack of clarity in how the code:
> 
> }}}
<eucode>
> sequence point is
>      atom x,y
> end sequence
> </eucode>
{{{

> 
> actually translates to a REAL sequence. (the only thing implied is that
> x comes before y. And then what happens with "extends" is even less clear.)

The intention of that syntax was precisely to show that point is a sequence.
In memory it looks precisely like what you would get with:
sequence point
    point = {0.0, 0.0}

The 'is' was used to indicate that that is what it MUST look like.
You cannot add an element to it, or store a sequence in one of its
elements.
'extends' takes an existing SS and adds more elements to it so:
sequence point is
        atom x, y
    end sequence
    sequence point3d extends point
        atom z
    end sequence
-- Now pointe3 is the same as you would get with
    sequence point3d is
        atom x, y
        atom z
    end sequence

The advantage is that if you decide that all points should have a name,
you need only add 'sequence name' to point, and all SS's that extend
point get a name automatically. 
       
> Even if you do define the behavior in some consistent manner, a reliance
> on implied order will cause problems for the programmer who wishes to
> mix SS with indexing.
> 
The intention is to access the elements by name. If you want to access by
index, you should use a plain unstructured sequence.

> You are welcome to debate on those points, of course.
> 
> I will also mention pass-by-reference. I think that is a bad idea for a
> different reason; it avoids the real problem, which is an absence of
> references! That is what makes complex data structures in Eu hard, more so
> than any issue with naming. We instead resort to global variables and code
> to maintain counts and other ugly things. References should be done
> everywhere, as a new data type, if they're going to be done at all.
> 
> (I would even declare the result a "new language"
> if it were necessary to do references properly.)

Yes it would be a new language if it gave up pass by value.
So SS is proposed for Eu, not that language.


KtB

new topic     » goto parent     » topic index » view message » categorize

38. Re: Eu improvements (part 4)

Karl Bochert wrote:
> I'd look at Hoffman's thead if I could find it.
I remember seeing it, but I can't give you a link...

I scribbled some rubbish, probably along the same lines, which I guess I should
post for reaction:

type Point(sequence p)
enum integer x, y       -- x=1, y=2
--  if length(p)!=2 then return 0 end if        -- automatic
--  if not integer(p[1]) then return 0 end if   -- automatic
--  if not integer(p[2]) then return 0 end if   -- automatic
    return 1
end type

type Point_3D(sequence p)
enum Point, integer z   -- x=1, y=2, z=3
--  if length(p)!=3 then return 0 end if        -- automatic
--  if not integer(p[1]) then return 0 end if   -- automatic
--  if not integer(p[2]) then return 0 end if   -- automatic
--  if not integer(p[3]) then return 0 end if   -- automatic
    return 1
end type

--which allows:
Point_3D A
 A={1,1,1}
 ?A.x   -- same as A[1], note A[x] gives x undefined
 ?A.y   -- same as A[2], note A[y] gives y undefined
 ?A.z   -- same as A[3], note A[z] gives z undefined

--or (?better I think?):
type Point_3D(sequence q)
enum Point p, integer z -- p=1, z=2
--  if not Point(q[1]) then return 0 end if     -- automatic
--  if not integer(q[2]) then return 0 end if   -- automatic
    return 1
end type

--which needs:
Point_3D A
 A={{1,1},1}
 ?A.p.x -- same as A[1][1], note A[p][x] gives p undefined
        --                   and A[1][x] gives x undefined
 ?A.p.y -- same as A[1][2], note A[p][y] gives p undefined
        --                   and A[1][y] gives y undefined
 ?A.z   -- same as A[2], note A[z] gives z undefined


Something there, maybe, not sure I'm happy with it...

> I think the reurn value is the most important advantage.
> I think transparency here is bad. PBR is different than normal parameter
> passing, and I want to know which is being used when I read the code.
> As an aside, this is what bothers me so much about OOP programming. So
> much is being done transparently (behind my back) that reading the code
> gives me no idea what is actually happening.
Oh, snap!
> 
> > One problem with PBR is that it shouldn't surprise the programmer. 
Snap!

> For me, clarity of the resultant code is the measure of all features.
Bingo!

Regards,
Pete

new topic     » goto parent     » topic index » view message » categorize

39. Re: Eu improvements (part 4)

Jason Gade wrote:
> 
> Karl Bochert wrote:
> > Well heres the gauntlet.
> > My SS proposal is on the table.
> > Yes, No, only with changes, or yes but consider this syntax first?
> > 
> > The proposal is SS.
> > The proposal is NOT dot-notation, NOT named elements,
> > NOT namespaced ids, NOT a new syntax for user-defined datatypes.
> > It IS a combination of all those things in a coherent package.
> > 
> > For or Against?
> > 
> > KtB
> 
> Okay, because of your gauntlet I say "no".
> 
Fair enough. I was hoping for some reasons why SS falls short, but at
least I got an unequivocal answer.

KtB

new topic     » goto parent     » topic index » view message » categorize

40. Re: Eu improvements (part 4)

Karl Bochert wrote:
> 
> Jason Gade wrote:
> > 
> > Karl Bochert wrote:
> > > Well heres the gauntlet.
> > > My SS proposal is on the table.
> > > Yes, No, only with changes, or yes but consider this syntax first?
> > > 
> > > The proposal is SS.
> > > The proposal is NOT dot-notation, NOT named elements,
> > > NOT namespaced ids, NOT a new syntax for user-defined datatypes.
> > > It IS a combination of all those things in a coherent package.
> > > 
> > > For or Against?
> > > 
> > > KtB
> > 
> > Okay, because of your gauntlet I say "no".
> > 
> Fair enough. I was hoping for some reasons why SS falls short, but at
> least I got an unequivocal answer.
> 
> KtB

I've replied a lot in the last day or two trying to discuss it but you didn't
seem to be interested in discussion.

I kind of like Pete's idea above which builds on what James Hoffman had
proposed. I know it isn't perfect but it is interesting.

I also like how it is implemented already in a fork that I tried discussing with
you.

My main rationale is that while I like the idea of some kind of dot notation or
named subsequences I dislike the idea of restricting the types. However
integrating it by extending the type system we already have seems logical to me.

I understand the need for stronger typechecking in some instances; however
properly written routines should either check themselves or be written in such a
way that the data does not change in unexpected ways.

Any objections that I have can be taken with a grain of salt, though, since I
have not written any large Euphoria projects and I don't know if I am capable of
doing so. In Euphoria or any language for that matter. Mostly by reading and
writing in this forum I am learning stuff that may or may not be useful to me.

--
"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.

new topic     » goto parent     » topic index » view message » categorize

41. Re: Eu improvements (part 4)

Robert Craig wrote:
> 
> Karl Bochert wrote:
> > The other thing I notice is that RC is totally silent. 
> 
> I'm skimming through most of it. You have to realize though,
> that I've had more than a decade to study most of these issues,
> both privately, and on this forum, so they aren't as interesting to
> me as they once were. Also, I don't want to jump into
> the discussion and pour cold water on any idea until others
> have had a fair chance to fully work through the pros and cons.
Ouch!
That sounds like you plan to wait until your users decide on something
and then shoot it down.
That sounds like you have studied and rejected all these things
already.

> If I think some big pro or big con has been overlooked, I'll 
> eventually chime in. Language design is highly subjective. 
> There are very few 100% right or 100% wrong answers.
> 
> > Is he waiting for unanimity? 
> 
> Definitely not. We'll probably never have unanimity on
> any important language design issue.
> 
> > Will he bless any change at all? 
> 
> Yes. 
> If a competent person wants to do something,
> and it looks like he/she has a lot of supporters, and few
> opponents, I'll probably approve it, even if I'm not in favor
> of it.
> 
 Thats better. But given that you have closely studied most
of these issues, it sure would help if you could occaisionally
chime in with:
"I'll never go for that"
or "Don't forget ..."
or something.
I suspect that the range of things you will accept is narrow.

> Language features aren't the only way to improve things.
> There's porting, better documentation, a better debugger
> etc. These things would not be controversial or difficult
> to reach a consensus on.
Interestingly, I have seen no proposals along those lines. Perhaps
because you have so ably plumbed those depths already.
> 
> > Without his input, none of
> > this means anything at all.
> > I seem to have forgotten this in my years away from Eu.
> 
> You've been away too long. Welcome back.
Thanks (You'll not convince me that I was much missed smile)

> Times have changed.
> 
I thought so, very briefly.

> Moving from dictatorship to democracy is not 
> a simple process.  smile
>
I cannot count patience among my virtues.
 
> The British royalty were once dictators, but now they
> are just figureheads, with the Queen putting her signature
> on anything that the elected parliament decides on. There's also the
> House of Lords (like the Canadian senate) - old cronies 
> who are not elected, but still have a bit of power, and
> are supposed to provide "sober second thought" on major changes.
> 
> Eventually some sort of informal Euphoria political process 
> will emerge. We'll just have to play it by ear for now.
> The thing that keeps me honest is that anyone can fork
> their own version of Euphoria at any time.
> 
Maybe my best bet is to come back next year.

> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>

Good to know you're there
KtB
I seem to be afflicted with this terrible urge to type...

new topic     » goto parent     » topic index » view message » categorize

42. Re: Eu improvements (part 4)

Ray Smith wrote:
> "If" OO can be added to Euphoria...
> OO doesn't solve all of the problems in the world ... but it does give the 
> programmer some powerful tools to solve certain problems very elegantly.
Features, yes, OO, no.
I firmly believe there are some really great neato features we can add, 
some of which come from the dying throes of the OO movement, as it were.
But OO has failed, in case you hadn't noticed.
> 
> Everyone should want Euphoria to have some more features ... but must 
> realise it probably won't be "exactly" how they want them.
Well, we should, nay MUST thash out our thoughts, else what is the point of this
list?

It matters not a jot if we are wrong, but if we/an idea is right...

Regards,
Pete

new topic     » goto parent     » topic index » view message » categorize

43. Re: Eu improvements (part 4)

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).

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:

type Point(sequence s) -- classic syntax
    ...
    return checkval
end type

type Point is -- like SS
    atom x,y
    (where)
    ...
    (requiring)
    ...
    return checkval
end type


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)

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.

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. 

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.

The "extends" syntax can apply as in your SS proposal, with
the "where" and "requiring" keywords causing an override of the
original declaration.

new topic     » goto parent     » topic index » view message » categorize

44. Re: Eu improvements (part 4)

Pete Lomax wrote:
> 
Yeah, Cut that middle bit of nonsense, subsequences rule, no flattening:
> }}}
<eucode>
> type Point(sequence p)
> enum integer x, y       -- x=1, y=2
> --  if length(p)!=2 then return 0 end if        -- automatic
> --  if not integer(p[1]) then return 0 end if   -- automatic
> --  if not integer(p[2]) then return 0 end if   -- automatic
>     return 1
> end type
> 
> type Point_3D(sequence q)
> enum Point p, integer z -- p=1, z=2
> --  if not Point(q[1]) then return 0 end if     -- automatic
> --  if not integer(q[2]) then return 0 end if   -- automatic
>     return 1
> end type
> 
> Point_3D A
>  A={{1,1},1}
>  ?A.p.x -- same as A[1][1], note A[p][x] gives p undefined
>         --                   and A[1][x] gives x undefined
>  ?A.p.y -- same as A[1][2], note A[p][y] gives p undefined
>         --                   and A[1][y] gives y undefined
>  ?A.z   -- same as A[2], note A[z] gives z undefined
> </eucode>
{{{

> 
Agreed, you're right, much happier with that now.
Yes, obviously you can put user defined code above the return 1.

Thanks,
Pete

new topic     » goto parent     » topic index » view message » categorize

45. Re: Eu improvements (part 4)

Robert Craig wrote:
> We'll probably never have unanimity on any important language design issue.
Nice to see someone stuck a up stupid poll before any consensus whatsoever.

> The British royalty ...
> are just figureheads
> old cronies 
> "sober"
OI! Watch your mouth blink
Pete

new topic     » goto parent     » topic index » view message » categorize

46. Re: Eu improvements (part 4)

James W Hofmann wrote:
> 
> > The proposal is SS.
> > The proposal is NOT dot-notation, NOT named elements,
> > NOT namespaced ids, NOT a new syntax for user-defined datatypes.
> > It IS a combination of all those things in a coherent package.
> > 
> > For or Against?
> > 
> > KtB
> > 
> 
> I'm a "no." 
> 
> Your presentation of SS does some things that the type keyword doesn't do
> currently, but it loses the precise check-as-function feature. To get both
> implies that you make both a SS and a type; that is inelegant - a pollution
> of keywords. In addition, SS tries very hard to separate itself from the
> original sequence type; there is a lack of clarity in how the code:
> 
> }}}
<eucode>
> sequence point is
>      atom x,y
> end sequence
> </eucode>
{{{

> 
> actually translates to a REAL sequence. (the only thing implied is that
> x comes before y. And then what happens with "extends" is even less clear.)
> Even if you do define the behavior in some consistent manner, a reliance
> on implied order will cause problems for the programmer who wishes to
> mix SS with indexing.
> 
> You are welcome to debate on those points, of course.
> 
> I will also mention pass-by-reference. I think that is a bad idea for a
> different reason; it avoids the real problem, which is an absence of
> references! That is what makes complex data structures in Eu hard, more so
> than any issue with naming. We instead resort to global variables and code
> to maintain counts and other ugly things. References should be done
> everywhere, as a new data type, if they're going to be done at all.
> 
> (I would even declare the result a "new language"
> if it were necessary to do references properly.)

Wise conclusions. I agree fully.

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

new topic     » goto parent     » topic index » view message » categorize

47. Re: Eu improvements (part 4)

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

new topic     » goto parent     » topic index » view message » categorize

48. Re: Eu improvements (part 4)

Pete Lomax wrote:
> 
> Pete Lomax wrote:
> > 
> Yeah, Cut that middle bit of nonsense, subsequences rule, no flattening:
> > }}}
<eucode>
> > type Point(sequence p)
> > enum integer x, y       -- x=1, y=2
> > --  if length(p)!=2 then return 0 end if        -- automatic
> > --  if not integer(p[1]) then return 0 end if   -- automatic
> > --  if not integer(p[2]) then return 0 end if   -- automatic
> >     return 1
> > end type
> > 
> > type Point_3D(sequence q)
> > enum Point p, integer z -- p=1, z=2
> > --  if not Point(q[1]) then return 0 end if     -- automatic
> > --  if not integer(q[2]) then return 0 end if   -- automatic
> >     return 1
> > end type
> > 
> > Point_3D A
> >  A={{1,1},1}
--I think you are discarding something valuable if you expose the
--innards this way. Think about the versioning of external libraries

> >  ?A.p.x -- same as A[1][1], note A[p][x] gives p undefined
> >         --                   and A[1][x] gives x undefined
> >  ?A.p.y -- same as A[1][2], note A[p][y] gives p undefined
> >         --                   and A[1][y] gives y undefined
> >  ?A.z   -- same as A[2], note A[z] gives z undefined
> > </eucode>
{{{

> >
Why do I have to know that Point_3D was extended from Point, rather than
defined all-at-once?
Why should one co-ordinate be so different from the others?
If a function operates on a Point, should it also operate on a Point_3D?
Flatten the sequence!
 
> Agreed, you're right, much happier with that now.
> Yes, obviously you can put user defined code above the return 1.
> 
> Thanks,
> Pete

new topic     » goto parent     » topic index » view message » categorize

49. Re: Eu improvements (part 4)

Pete Lomax wrote:
> 
> Pete Lomax wrote:
> > 
> Yeah, Cut that middle bit of nonsense, subsequences rule, no flattening:
> > }}}
<eucode>
> > type Point(sequence p)
> > enum integer x, y       -- x=1, y=2
> > --  if length(p)!=2 then return 0 end if        -- automatic
> > --  if not integer(p[1]) then return 0 end if   -- automatic
> > --  if not integer(p[2]) then return 0 end if   -- automatic
> >     return 1
> > end type
> > 
> > type Point_3D(sequence q)
> > enum Point p, integer z -- p=1, z=2
> > --  if not Point(q[1]) then return 0 end if     -- automatic
> > --  if not integer(q[2]) then return 0 end if   -- automatic
> >     return 1
> > end type
> > 
> > Point_3D A
> >  A={{1,1},1}
> >  ?A.p.x -- same as A[1][1], note A[p][x] gives p undefined
> >         --                   and A[1][x] gives x undefined
> >  ?A.p.y -- same as A[1][2], note A[p][y] gives p undefined
> >         --                   and A[1][y] gives y undefined
> >  ?A.z   -- same as A[2], note A[z] gives z undefined
> > </eucode>
{{{

> > 
> Agreed, you're right, much happier with that now.
> Yes, obviously you can put user defined code above the return 1.
> 
> Thanks,
> Pete

(Just to clarify, this post is not directed at anyone in particular, but at the
chaos of this and related threads.)

The type construct is not a suitable candidate for structured sequences.
The only way that it can be suitable is if a new syntax is introduced for
defining the structure members. The problem is in discerning private variables
used for the typecheck routine from the structure members.
I've chewed on it before, many times. The type construct is one thing that
really sticks out to me as in dire need of improvement, if only for the sake of
making it more useful. Let's not invent an excuse to wedge it into a new mould
though.

Now before this crazy discussion goes any further, I for one would like to see
structured sequences, but not if I have to forfeit the possibility of oop. Do we
really want both?
Before you slap your veto on either concept, consider what is best for Eu, not
what is best for yourself, because ultimately whatever is best for Eu will be
best for you too. If Eu continues to stagnate at the expense of stubborn and
unsubstantiated opinions, development will cease and we will have nothing but a
relic. If you are happy with how Eu is now, then don't upgrade?
If Eu progresses, even if it means that it will include features that you
despise, if that progress means a substantial increase in participants, it also
means a substantial increase in available Eu code, turnover in development time
of both the code resources and Eu itself. All of this means less work for us
building and maintaining the tools we need to create the applications we want.
As a sort of obscure example. I've been working for a long time on trying to
fully automate the process of wrapping dlls using the header files because I KNOW
that the Eu community will NEVER even come close to being able to wrap every dll
I need/want to use, plus there needs to be a standardized method of creating
wrappers. We don't even have a proper port of the win32 headers yet.
The point is two-fold, with more participants, this issue would be less
pressing, because the major things would very likely be taken care of already.
Also with more particpants, it's likely that someone else would have been
successful at implementing such a tool for us by now.

Lest we forget, there is but a handful of people who are willing and capable of
implementing whatever features we come up with, so what YOU want really doesn't
matter. Be pragmatic, not emotional.

I also suggest that this discussion should turn it's focus on WHAT exactly needs
improvement first. Nevermind how.
Does eu need structured sequences? I say yes
Does eu need oop functionality? I say yes
Perhaps before even answering those questions we should ask ourselves what is
Eu's purpose? Other than the obvious "it's for programming", what kind of
programming and what kind of programmers?

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

new topic     » goto parent     » topic index » view message » categorize

50. Re: Eu improvements (part 4)

Pete Lomax wrote:
> 
> Ray Smith wrote:
> > "If" OO can be added to Euphoria...
> > OO doesn't solve all of the problems in the world ... but it does give the 
> > programmer some powerful tools to solve certain problems very elegantly.
> Features, yes, OO, no.
> I firmly believe there are some really great neato features we can add, 
> some of which come from the dying throes of the OO movement, as it were.
> But OO has failed, in case you hadn't noticed.

I hadn't heard that OO had failed.  In which way do you believe OO has failed?
Maybe you have a different view of success vs failure?

Why are all the most popular and most used languages OO?

When I first started using eu some 9 years ago I was against OO - and loved
Euphoria!
As I have learned more and had more experience I have grown to appreciate OO
concepts and believe it's a great solution to many problems.

Regards,

Ray Smith
http://RaymondSmith.com

new topic     » goto parent     » topic index » view message » categorize

51. Re: Eu improvements (part 4)

James W Hofmann wrote:
> I will also mention pass-by-reference. I think that is a bad idea for a
> different reason; it avoids the real problem, which is an absence of
> references! That is what makes complex data structures in Eu hard, more so
> than any issue with naming. We instead resort to global variables and code
> to maintain counts and other ugly things. References should be done
> everywhere, as a new data type, if they're going to be done at all.
I don't understand what you mean by "absence of references".

Pete

new topic     » goto parent     » topic index » view message » categorize

52. Re: Eu improvements (part 4)

Karl Bochert wrote:
> > > Point_3D A
> > >  A={{1,1},1}
> --I think you are discarding something valuable if you expose the
> --innards this way. 
I agree that is a truly awful way to initialise a point_3d and warrants some
seriously negative style points, but as for "innard exposure", it is unavoidable.
Consider
procedure p(object o)
    ?o
end procedure
Point_3D A
-- initialise A
..
p(A)

What else you gonna do? Encrypt it?
The contents will be exposed, period.

> Think about the versioning of external libraries
You lost me there.

> If a function operates on a Point, should it also operate on a Point_3D?
Quite. A return {x*cos(y/x),y*sin(x/y)} might work fine on a Point but will chop
off the z of a flattened point_3d. If we have line as point,point then how can we
specify the first or second x if it's flattened? If line is flattened, then how
do functions from point operate on [1..2] or [3..4]?

Flattening just won't work.

I agree that any point_3d which needs different syntax to access the x and z
coordinates is badly written. line as point,point is a much better example.

Regards,
Pete

new topic     » goto parent     » topic index » view message » categorize

53. Re: Eu improvements (part 4)

Chris Bensler wrote:
> the chaos of this and related threads.
We love it!
> 
> The type construct is not a suitable candidate for structured sequences.
If we cannot morph types into what we need, then we need to rip them out of the
language. I think we need something completely different for c-structs, let's not
have multiple/incompatible user defined Eu-types as well. 100% backward
compatibility for types must not become an overriding concern.

> The only way that it can be suitable is if a new syntax is introduced for 
> defining the structure members. The problem is in discerning private 
> variables used for the typecheck routine from the structure members.
an "end enum" would do that nicely, much better than the while nextCh=','
approach I was thinking of.

>If Eu continues to stagnate at the expense of stubborn and unsubstantiated 
>opinions
We have to rise above that. Advancement should not occur at the cost of free
speech. We have to learn to ignore what we must in order to progress.
Some of these concepts are profoundly difficult and it seems often beyond the
ability of any one person to dot all the i's and cross all the t's, even
theoretically. I feel I learn much from these discussions, chaos or not.

I take the point that this anarchy is not very newbie-friendly, though.

> I also suggest that this discussion should turn it's focus on WHAT exactly 
> needs improvement first. Nevermind how.
> Does eu need structured sequences? I say yes
> Does eu need oop functionality? I say yes
> Perhaps before even answering those questions we should ask ourselves what 
> is Eu's purpose? Other than the obvious "it's for programming", what kind 
> of programming and what kind of programmers?
What drives me most at the moment is how to add oft-requested features "in the
style of" the existing Eu.

Regards,
Pete

new topic     » goto parent     » topic index » view message » categorize

54. Re: Eu improvements (part 4)

Pete Lomax wrote:
> 
> Karl Bochert wrote:
> > > > Point_3D A
> > > >  A={{1,1},1}
> > --I think you are discarding something valuable if you expose the
> > --innards this way. 
> I agree that is a truly awful way to initialise a point_3d and warrants some
> seriously negative style points, but as for "innard exposure", it is
> unavoidable.
> Consider
> }}}
<eucode>
> procedure p(object o)
>     ?o
> end procedure
> Point_3D A
> -- initialise A
> ..
> p(A)
> </eucode>
{{{

> What else you gonna do? Encrypt it?
> The contents will be exposed, period.
> 
What I meant was that p(A) hides the details of the implementation, while
p[0] exposes (and forces) implemenation as a sequence.
Likewise
 p = {0,0,{0,0}}
not only exposes the implementation as a sequence, but also exposes the
number of elements in p (maybe we want private elements?) and their
structure (so if the provider of Point adds something else to it, say 
'color', code is broken.
Perhaps when we implement this, we will want to put some control fields
in the underlying sequence, So  a Point is perhaps actually:
 ({flg,x},{flg,y})
If we access the elements by name, we need not worry about how the SS is
actually implemented, and indeed that implementation could change with
the next version of Eu.

---
It was probably a mistake mentioning sequences at all in connection with
SS. My mental picture of a SS is of a sequence with restrictions, because
I have a clear idea how I would implement it (I've done this once).
I thought that image might help with understanding. I now think it might
be better to call them StructureS, and remain ignorant of how Eu
implements them.
They are a data structure whose elements are accessed by name.
---

> > Think about the versioning of external libraries
> You lost me there.
> 
A major advantage of SS is that they hide implementation. When
we get the latest version of xx.lib, the internal structure of Point
may have changed, new private fields etc. If we access only by name,
The author of the library is free to add new features.
Our code should not be broken by the upgrade of the library.

> > If a function operates on a Point, should it also operate on a Point_3D?
> Quite. A return {x*cos(y/x),y*sin(x/y)} might work fine on a Point but will
> chop off the z of a flattened point_3d. If we have line as point,point then
> how can we specify the first or second x if it's flattened? If line is
> flattened,
> then how do functions from point operate on [1..2] or [3..4]?
> 
> Flattening just won't work.
> 
function mat(Point p)
       return (p.x*cos(p.y/p.x), p.y*sin(p.x/p.y))
    end function

When the function accesses the x value, it accesses p[1] (the x
element of a Point) If p is a Point3D, it must access p[1][1] to get
x. It cannot know which form to use. Moreover when you later add a
Point4D, the x is accessed differently again.
Both Point and Point3d must have the x element in the same place.

Inheritance (the is-a relationship) produces flat sequences.
Containment (the has-a relationship) produces nested sequences.
So:
sequence Point3d extends Point -- (is a point)
       atom z
    end sequence
    ?Point3d  --=> {0,0,0}

    sequence Pointxx is
       Point p           -- (has a point)
       atom z
    end sequence
    ?Pointxx    --=> {{0,0}, 0}


We specify the first or second x with dot notation like this
sequence Point is
      atom x, y
    end sequence
    sequence Line is
       Point beg, end
    end sequence

    procedure showPoints(Line L)
      showPoint(L.beg.x)
      showPoint(L.beg.y)
      showPoint(L.end.x)
      showPoint(L.end.y)
    end procedure

Internally The structure of a line is:
   l = {{x,y},{x,y}}
( there is a direct correspondence between the nesting of the sequence
 and the dots of the dot notation )
If we create an instance of a line with Point3D's instead, we get
   l = {{x,y,z}, {x,y,z} }
In both cases
  beg.x <-> line[1][1]
  beg.y <-> line[1][2]
  etc.
Anything that deals with a point, knows that the x element is at point[1]
and the y element is at point[2]. For a point3d to be a point, it must
have its x element at point3d[1], not at point3d[1][1]

> I agree that any point_3d which needs different syntax to access the x and z
> coordinates is badly written. line as point,point is a much better example.
> 
> Regards,
> Pete

As a low-level programmer, I can't help but prattle on about implementation.
I will try to improve, but for now --
-- Please pay no attention to how SS is implemented --
That is the problem of the implementor
An SS is a structure whose elements are accessed by name. only.

KtB

new topic     » goto parent     » topic index » view message » categorize

55. Re: Eu improvements (part 4)

Pete Lomax wrote:
> 
> Chris Bensler wrote:
> > the chaos of this and related threads.
> We love it!
> > 
> > The type construct is not a suitable candidate for structured sequences.
> If we cannot morph types into what we need, then we need to rip them out of
> the language. I think we need something completely different for c-structs,
> let's not have multiple/incompatible user defined Eu-types as well. 100%
> backward
> compatibility for types must not become an overriding concern.
> 
I think type() and structures co-exist quite nicely. type() functions very
well for restricting the values of items, while structures provide
control of, well, structure.
I might use structures to organize the fields of a customer list, but
I would want type() to validate that a zipcode is ok.
Type() and structures do different things.

> > The only way that it can be suitable is if a new syntax is introduced for 
> > defining the structure members. The problem is in discerning private 
> > variables used for the typecheck routine from the structure members.
> an "end enum" would do that nicely, much better than the while nextCh=','
> approach
> I was thinking of.
> 
> >If Eu continues to stagnate at the expense of stubborn and unsubstantiated 
> >opinions
> We have to rise above that. Advancement should not occur at the cost of free
> speech. We have to learn to ignore what we must in order to progress.
> Some of these concepts are profoundly difficult and it seems often beyond the
> ability of any one person to dot all the i's and cross all the t's, even
> theoretically.
> I feel I learn much from these discussions, chaos or not.
> 
> I take the point that this anarchy is not very newbie-friendly, though.
> 
> > I also suggest that this discussion should turn it's focus on WHAT exactly 
> > needs improvement first. Nevermind how.
> > Does eu need structured sequences? I say yes
> > Does eu need oop functionality? I say yes
> > Perhaps before even answering those questions we should ask ourselves what 
> > is Eu's purpose? Other than the obvious "it's for programming", what kind 
> > of programming and what kind of programmers?
> What drives me most at the moment is how to add oft-requested features "in the
> style of" the existing Eu.
> 
> Regards,
> Pete

new topic     » goto parent     » topic index » view message » categorize

56. Re: Eu improvements (part 4)

Karl Bochert wrote:
> 
> I might use structures to organize the fields of a customer list, but
> I would want type() to validate that a zipcode is ok.

Or you could create a structure for the zip variable...

type Zip(sequence z) -- the type way
   if all_numbers(z) then
      return length(z) = 5 or length(z) = 9
   else
      return -1
   end if
end type

sequence Zip is
    integer a, b, c, d, e
    where
       a in {0,1,2,3,4,5,6,7,8,9} -- pseudo code
       b in {0,1,2,3,4,5,6,7,8,9}
       c in {0,1,2,3,4,5,6,7,8,9}
       d in {0,1,2,3,4,5,6,7,8,9}
       e in {0,1,2,3,4,5,6,7,8,9}
    end where
end sequence

sequence ZipPlus is
    integer a, b, c, d
    where
       a in {0,1,2,3,4,5,6,7,8,9}
       b in {0,1,2,3,4,5,6,7,8,9}
       c in {0,1,2,3,4,5,6,7,8,9}
       d in {0,1,2,3,4,5,6,7,8,9}
    end where
end sequence

sequence ZipCode is
    Zip zip_code
    ZipPlus zip_plus
end sequence

ZipCode z
z.Zip = "12345"
z.ZipPlus = "9876"

:)

-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/

new topic     » goto parent     » topic index » view message » categorize

57. Re: Eu improvements (part 4)

Crap! I typoed...

> ZipCode z
> z.Zip = "12345"
> z.ZipPlus = "9876"

Should be:

z.zip_code = "12345"
z.zip_plus = "9876"

I think... right? Argh!

-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/

new topic     » goto parent     » topic index » view message » categorize

58. Re: Eu improvements (part 4)

Karl Bochert wrote:
> -- Please pay no attention to how SS is implemented --
> That is the problem of the implementor
> An SS is a structure whose elements are accessed by name. only.

For me, structures are just fine, actually desirable,
when their effect on the simplicity of the language 
and libraries is ignored, and when implementation issues are ignored.
Please read what I said back in 2001...  

http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=8&fromYear=6&toMonth=8&toYear=6&postedBy=rds&keywords=structures+bloat

Maybe Matt or yourself, since one or both of you seem to have 
implemented structures, can explain where I'm wrong about either the 
implementation costs, or the loss of language and library simplicity.

I don't need to be sold on the value of structures as an isolated
language design concept. I need persuading in these other two areas.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

new topic     » goto parent     » topic index » view message » categorize

59. Re: Eu improvements (part 4)

Robert Craig wrote:
> 
> For me, structures are just fine, actually desirable,
> when their effect on the simplicity of the language 
> and libraries is ignored, and when implementation issues are ignored.
> Please read what I said back in 2001...  
> 
> <a
> href="http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=8&fromYear=6&toMonth=8&toYear=6&postedBy=rds&keywords=structures+bloat">http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=8&fromYear=6&toMonth=8&toYear=6&postedBy=rds&keywords=structures+bloat</a>
> 
> Maybe Matt or yourself, since one or both of you seem to have 
> implemented structures, can explain where I'm wrong about either the 
> implementation costs, or the loss of language and library simplicity.
> 
> I don't need to be sold on the value of structures as an isolated
> language design concept. I need persuading in these other two areas.

I don't see why a structure can't be treated as being a sequence.
Yes, you should be able to subscript a structure or concatenate them etc..
What's wrong with that? I think that would be desirable. If the length of a
structure changes from it's definition, the structure properties would be lost
and it is then just a sequence.

It would be nice if structures could be concatenated and retain their
definitions but then they would probably have to be dynamic.

Actually, while data structures would be useful too, I don't think that is what
we are actually in need of. What we need is a way to address the global pollution
created by all the index constants used for the pseudo-structures we already use
routinely. We just need a way to name the elements.


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

new topic     » goto parent     » topic index » view message » categorize

60. Re: Eu improvements (part 4)

Chris Bensler wrote:
> 
> Actually, while data structures would be useful too, I don't think that is
> what
> we are actually in need of. What we need is a way to address the global
> pollution
> created by all the index constants used for the pseudo-structures we already
> use routinely. We just need a way to name the elements.
> 

This would bring us back to the first thing I proposed, adding a
keyword "index" used within type to declare named indexes,
and some extra syntax to access a named index.
A simple aliasing scheme, without performance impact after compilation.
http://www.listfilter.com/EUforum/m11619.html

new topic     » goto parent     » topic index » view message » categorize

61. Re: Eu improvements (part 4)

Chris Bensler wrote:
> Actually, while data structures would be useful too, I don't think that is 
> what we are actually in need of. What we need is a way to address the 
> global pollution created by all the index constants used for the pseudo-
> structures we already use routinely. We just need a way to name the 
> elements.

Turning my previous idea on it's head a bit, you could bury a bunch of enums
inside a type:
type cust(sequence...)
enum name, addr1, addr2, ... end enum
   ...
end type

cust c
  ?c[cust:name]

What I'm saying now is the emums don't do anything to the type, but are
available as qualified subscripts.

Just an idea,
Pete

new topic     » goto parent     » topic index » view message » categorize

62. Re: Eu improvements (part 4)

James W Hofmann wrote:
> 
> Chris Bensler wrote:
> > 
> > Actually, while data structures would be useful too, I don't think that is
> > what
> > we are actually in need of. What we need is a way to address the global
> > pollution
> > created by all the index constants used for the pseudo-structures we already
> > use routinely. We just need a way to name the elements.
> > 
> 
> This would bring us back to the first thing I proposed, adding a
> keyword "index" used within type to declare named indexes,
> and some extra syntax to access a named index.
> A simple aliasing scheme, without performance impact after compilation.
> <a
> href="http://www.listfilter.com/EUforum/m11619.html">http://www.listfilter.com/EUforum/m11619.html</a>

That's why I like the idea. Plus regarding other threads on the subject, I don't
like the idea of making another datatype that is not a sequence and I understand
Rob's objections.

However the way that classes are implemented in ooeu fits the bill for what we
are suggesting, for the most part.

--
"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.

new topic     » goto parent     » topic index » view message » categorize

63. Re: Eu improvements (part 4)

Pete Lomax wrote:
> 
> Chris Bensler wrote:
> > the chaos of this and related threads.
> We love it!
> > 
> > The type construct is not a suitable candidate for structured sequences.
> If we cannot morph types into what we need, then we need to rip them out of
> the language.

Types are useful. They just aren't used as often as they should be because they
lack enough value. The concept is also different than structures. While they are
similar, a type construct is eu's form of assertion used primarily for debugging.
We don't want to be able to turn off the member typechecking for structures.


> > The only way that it can be suitable is if a new syntax is introduced for 
> > defining the structure members. The problem is in discerning private 
> > variables used for the typecheck routine from the structure members.
> an "end enum" would do that nicely, much better than the while nextCh=','
> approach
> I was thinking of.

Euphoria has a definite lack of rules and exceptions. PLEASE let's keep it that
way. Exceptions beget exceptions.
I'm certainly not opposed to advancement, but it must be weighed very carefully
in my opinion. I think so many languages are failures precisely because they have
become duct-tape victims.


> >If Eu continues to stagnate at the expense of stubborn and unsubstantiated 
> >opinions
> We have to rise above that. Advancement should not occur at the cost of free
> speech. We have to learn to ignore what we must in order to progress.
> Some of these concepts are profoundly difficult and it seems often beyond the
> ability of any one person to dot all the i's and cross all the t's, even
> theoretically.
> I feel I learn much from these discussions, chaos or not.

True, but it's not productive.


> > I also suggest that this discussion should turn it's focus on WHAT exactly 
> > needs improvement first. Nevermind how.
> > Does eu need structured sequences? I say yes
> > Does eu need oop functionality? I say yes
> > Perhaps before even answering those questions we should ask ourselves what 
> > is Eu's purpose? Other than the obvious "it's for programming", what kind 
> > of programming and what kind of programmers?

> What drives me most at the moment is how to add oft-requested features "in the
> style of" the existing Eu.

I don't see how that has to do with the questions I posed :P
I know what ya mean though.
But thank you for bringing it up because that is very much what I was trying to
say we should not do. We need to approach this pragmatically, not emotionally (or
enthusiastically iow). We shouldn't implement something just because that is what
people want or don't want. We should do it because it would improve the Euphoria
language. Maybe that means Eu shouldn't be improved at all, if it already meets
it's M.O.
That's why we need to figure out what Eu is supposed to be, or what we want it
to be. Not what it should have or not have.


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

new topic     » goto parent     » topic index » view message » categorize

64. Re: Eu improvements (part 4)

Chris Bensler wrote:
> Types are useful. They just aren't used as often as they should be because
> they
> lack enough value. The concept is also different than structures. While they
> are similar, a type construct is eu's form of assertion used primarily for
> debugging.
> We don't want to be able to turn off the member typechecking for structures.

Why not? Use typechecking for debugging and ensuring correctness and once it is
correct then you can turn it off. I don't see structures and typechecking as
fundamentally different things. At least, they shouldn't be.

--
"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.

new topic     » goto parent     » topic index » view message » categorize

65. Re: Eu improvements (part 4)

Jason Gade wrote:
> 
> Chris Bensler wrote:
> > Types are useful. They just aren't used as often as they should be because
> > they
> > lack enough value. The concept is also different than structures. While they
> > are similar, a type construct is eu's form of assertion used primarily for
> > debugging.
> > We don't want to be able to turn off the member typechecking for structures.
> 
> Why not? Use typechecking for debugging and ensuring correctness and once it
> is correct then you can turn it off. I don't see structures and typechecking
> as fundamentally different things. At least, they shouldn't be.

A type construct is used for assertion of any type. Binding it with the concept
of structures will create confusion. A type construct is used for verifying the
integrity of the data itself, whereas a structure is used to define how the data
is arranged. I agree that they are related, but I think that the purpose of the
structure is a very separate thing from eu's custom types.


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

new topic     » goto parent     » topic index » view message » categorize

66. Re: Eu improvements (part 4)

Chris Bensler wrote:
> Actually, while data structures would be useful too, I don't think that is
> what
> we are actually in need of. What we need is a way to address the global
> pollution
> created by all the index constants used for the pseudo-structures we already
> use routinely. We just need a way to name the elements.

Yes, I thought that too after reading Robert's old post.

I think an enum-like syntax would help a lot there, but they become another data
type too.

eg
enum customer_record = ID, first_name, last_name, balance

-- create a sequence of length 4 
sequence customer as customer_record
-- I don't actually like this idea though as you have to tie the variable to
something else

-- or alternatively --
sequence customer
customer = repeat(0, length(customer_record)) -- number of enums

-- or --
constant enumLength = customer_record
-- the name of the enum itself returns its length
--   customer = repeat("", enumLength)
-- ie (but looks odd) --
--   customer = repeat("", customer_record)

customer.ID = next_ID()
customer[first_name] = "Bob"
customer.balance = 10000
-- and of course
customer[3] = "Smith"
-- would still work

-- calling the enum like a function with the name of record you want returns
-- the index of the field.
integer balance_field
balance_field = customer_record(balance)
customer[balance_field] -= 400


I do like the idea of named data access to sequences with dot notation but
anything that helps with the field access will help, without having to define 100
constants for every type of 'structure' you are trying to create.

I know these wouldn't go anywhere near what people were talking about the last
week or so but it might be easier to implement?

Gary

new topic     » goto parent     » topic index » view message » categorize

67. Re: Eu improvements (part 4)

Pete Lomax wrote:
> 
> inside a type:
> }}}
<eucode> 
> type cust(sequence...)
> enum name, addr1, addr2, ... end enum
>    ...
> end type
> 
> cust c
>   ?c[cust:name]
> </eucode>
{{{


Yeah, that looks good.  After reading your post before this I realised that
enums (as I suggested) would be just as polluting, since you'd have to call the
enum fields something like customer_first_name, cust_last_name, cust_balance,
etc.  More typing but maybe still workable.

I like what you've proposed above, but why can't you say:

c.name since c is a cust type?

Gary

new topic     » goto parent     » topic index » view message » categorize

68. Re: Eu improvements (part 4)

Robert Craig wrote:
> 
> Karl Bochert wrote:
> > -- Please pay no attention to how SS is implemented --
> > That is the problem of the implementor
> > An SS is a structure whose elements are accessed by name. only.
> 
> For me, structures are just fine, actually desirable,
> when their effect on the simplicity of the language 
> and libraries is ignored, and when implementation issues are ignored.
> Please read what I said back in 2001...  
> 
> <a
> href="http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=8&fromYear=6&toMonth=8&toYear=6&postedBy=rds&keywords=structures+bloat">http://www.listfilter.com/cgi-bin/esearch.exu?fromMonth=8&fromYear=6&toMonth=8&toYear=6&postedBy=rds&keywords=structures+bloat</a>
> 
> Maybe Matt or yourself, since one or both of you seem to have 
> implemented structures, can explain where I'm wrong about either the 
> implementation costs, or the loss of language and library simplicity.
> 
> I don't need to be sold on the value of structures as an isolated
> language design concept. I need persuading in these other two areas.

Rob, I fully agree with you about the effect upon the backend if a new
primitive datatype were added.  Which is why my version of structures
is just an extension of the existing types.

I'm not proposing anything that could be automatically handed off to a 
C routine, although I've thought about how to create some classes to 
help with this process, so that a simple method call could update the 
memory structure or read from it, so C-structure help comes from a 
library.

As I mentioned in another post, these are just sequences with some extra
tools.

Matt

new topic     » goto parent     » topic index » view message » categorize

69. Re: Eu improvements (part 4)

On Sat, 06 Jan 2007 23:25:19 -0800, Chris Bensler
<guest at RapidEuphoria.com> wrote:

>> > The type construct is not a suitable candidate for structured sequences.
>> If we cannot morph types into what we need, then we need to rip them out of
>> the language.
>
>Types are useful. They just aren't used as often as they should be because they
>lack enough value.
So add value!

>The concept is also different than structures. While they are similar, 
>a type construct is eu's form of assertion used primarily for 
>debugging. We don't want to be able to turn off the member 
>typechecking for structures.
Oh, absolutely. Obviously no-one would ever feel confident that a
program that used structures actually works. </SARCASM>

Of course you MUST be ABLE to turn off member typechecking!

>> > The only way that it can be suitable is if a new syntax is introduced for 
>> > defining the structure members. The problem is in discerning private 
>> > variables used for the typecheck routine from the structure members.
>> an "end enum" would do that nicely, much better than the while nextCh=','
>> approach
>> I was thinking of.
>
>Euphoria has a definite lack of rules and exceptions. PLEASE let's 
>keep it that way. Exceptions beget exceptions.
I take it you don't like enum/end enum. But what the heck did that wot
you just said mean?

>> >If Eu continues to stagnate at the expense of stubborn and unsubstantiated 
>> >opinions
>> We have to rise above that. Advancement should not occur at the cost of free
>> speech. We have to learn to ignore what we must in order to progress.
>> Some of these concepts are profoundly difficult and it seems often beyond the
>> ability of any one person to dot all the i's and cross all the t's, even
>> theoretically.
>> I feel I learn much from these discussions, chaos or not.
>
>True, but it's not productive.
Well, I must disagree. Some of my recent musings have been shot down
in flames and that may have saved me MONTHS of wasted effort.

If that is not productive then I likely have a quite different
definition of productive to you.

Regards,
Pete
PS I've delayed replying on this one for a reason; trust me it is much
less vitriolic than my words were 48hrs ago! You probably touched a
few raw nerves there Chris.

new topic     » goto parent     » topic index » view message » categorize

70. Re: Eu improvements (part 4)

I wrote:
> PS I've delayed replying on this one
And it seems Topica delayed it for another 3 days...
I think I'm finally a convert to the web interface now...

new topic     » goto parent     » topic index » view message » categorize

71. Re: Eu improvements (part 4)

Pete Lomax wrote:
> 
> On Sat, 06 Jan 2007 23:25:19 -0800, Chris Bensler
> <guest at RapidEuphoria.com> wrote:
> 
> >> > The type construct is not a suitable candidate for structured sequences.
> >> If we cannot morph types into what we need, then we need to rip them out of
> >> the language.
> >
> >Types are useful. They just aren't used as often as they should be because
> >they
> lack enough value.</font></i>
> So add value!
> 
> >The concept is also different than structures. While they are similar, 
> >a type construct is eu's form of assertion used primarily for 
> >debugging. We don't want to be able to turn off the member 
> >typechecking for structures.
> Oh, absolutely. Obviously no-one would ever feel confident that a
> program that used structures actually works. </SARCASM>
> 
> Of course you MUST be ABLE to turn off member typechecking!
> 
> >> > The only way that it can be suitable is if a new syntax is introduced for
> >> >
> >> > defining the structure members. The problem is in discerning private 
> >> > variables used for the typecheck routine from the structure members.
> >> an "end enum" would do that nicely, much better than the while nextCh=','
> >> approach
> >> I was thinking of.
> >
> >Euphoria has a definite lack of rules and exceptions. PLEASE let's 
> >keep it that way. Exceptions beget exceptions.
> I take it you don't like enum/end enum. But what the heck did that wot
> you just said mean?
> 
> >> >If Eu continues to stagnate at the expense of stubborn and unsubstantiated
> >> >
> >> >opinions
> >> We have to rise above that. Advancement should not occur at the cost of
> >> free
> >> speech. We have to learn to ignore what we must in order to progress.
> >> Some of these concepts are profoundly difficult and it seems often beyond
> >> the
> >> ability of any one person to dot all the i's and cross all the t's, even
> >> theoretically.
> >> I feel I learn much from these discussions, chaos or not.
> >
> >True, but it's not productive.
> Well, I must disagree. Some of my recent musings have been shot down
> in flames and that may have saved me MONTHS of wasted effort.
> 
> If that is not productive then I likely have a quite different
> definition of productive to you.
> 
> Regards,
> Pete
> PS I've delayed replying on this one for a reason; trust me it is much
> less vitriolic than my words were 48hrs ago! You probably touched a
> few raw nerves there Chris.

Pete, I'm terrible at explaining things.
Any time I offer an opinion it turns into a week long debate and I spend
countless hours defending myself for the sake of misunderstandings when the
difference in opinions is actually VERY subtle.
(happens IRL too)

Frankly I'm just plain tired of it. You guys will do what you want regardless of
my input. When Eu turns into another variation of C or PHP or PERL, it will be
you guys who have to deal with the headaches. I'll be walking away. I don't think
Eu should be like those other hacked languages.

I should be working on Mambo, not Eu. This is rather fruitless for me, because I
can see that Eu is going where I had hoped it would never tread.
The only thing that keeps me here is that I don't NEED to program and I do enjoy
using Eu. Plus the time I have invested to it.

I respect your input and abilities and I didn't mean to offend you. In fact I'm
pretty sure I said that I was replying to the topic and not to you directly.

The only thing I will say in reply to your comments is that I meant productive
for Euphoria. While it may be productive for you, we still haven't established
what we want Eu to grow up to be, or priority criteria, etc. As much as I love to
discusss things, I want to see Eu making some real progress.

Don't get me wrong Pete, I'm not barking, just fed up with trying to translate
my brainwaves into something that others can comprehend.

For all the effort I've put into trying to relay my ideas for Eu, I could have
finished Mambo 10 times over and not only demonstrate, but make you pay for my
work too.


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

new topic     » goto parent     » topic index » view message » categorize

72. Re: Eu improvements (part 4)

Chris Bensler wrote:
> 
> I should be working on Mambo, not Eu.

What's Mambo?

new topic     » goto parent     » topic index » view message » categorize

73. Re: Eu improvements (part 4)

c.k.lester wrote:
> 
> Chris Bensler wrote:
> > 
> > I should be working on Mambo, not Eu.
> 
> What's Mambo?

Vaporware mostly.
To be brief it's sort of a cross between Eu and C.
It's not meant to be a better Eu, since I'm sure that's what yer thinking.
Although it might resemble Eu, it would be much different functionally.

More technically, I started working on Mambo around the time 2.4 was released
and the idea was to demonstrate how the runtime, parser and IL could be separated
to provide greater flexibility and possibilities for things like embedding in
applications. That kind of petered out though when when the plans for 2.5 were
announced shortly after I began my own plans.

Mambo is the runtime component. There is also Tango (IL) and Foxtrot(parser).
(They are codenames, I haven't decided on a formal name yet or if I should even
continue work on it)


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

new topic     » goto parent     » topic index » view message » categorize

74. Re: Eu improvements (part 4)

Chris Bensler wrote:
> c.k.lester wrote:
> > Chris Bensler wrote:
> > > I should be working on Mambo, not Eu.
> > What's Mambo?
> Vaporware mostly.

heh. The only Mambo I knew of was the content management system, of which
Joomla is a fork (I think).

> Mambo is the runtime component. There is also Tango (IL) and Foxtrot(parser).
> (They are codenames, I haven't decided on a formal name yet or if I should
> even
> continue work on it)

Well, you should call the runtime "Whiskey," so you have Whiskey-Tango-Foxtrot,
or, briefly: WTF. :)

new topic     » goto parent     » topic index » view message » categorize

75. Re: Eu improvements (part 4)

c.k.lester wrote:
> 
> Chris Bensler wrote:
> > c.k.lester wrote:
> > > Chris Bensler wrote:
> > > > I should be working on Mambo, not Eu.
> > > What's Mambo?
> > Vaporware mostly.
> 
> heh. The only Mambo I knew of was the content management system, of which
> Joomla is a fork (I think).
> 
> > Mambo is the runtime component. There is also Tango (IL) and
> > Foxtrot(parser).
> > (They are codenames, I haven't decided on a formal name yet or if I should
> > even
> > continue work on it)
> 
> Well, you should call the runtime "Whiskey," so you have
> Whiskey-Tango-Foxtrot,
> or, briefly: WTF. :)

LOL

What's even funnier is that WTF!? is the name I use for my *underground* faux
software company.

Seriously though, the names are meant to represent grace and elegance (ie
dancing).

Yes, I'm aware of the Mambo CMS too.
Indirectly I think that's where I got the idea for the name.

I'm actually thinking of using Harmony for the formal name, but the project is
nowhere near a point to worry about that yet. I'd like to use Jive, but it's a
little too similar to Java.

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

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu