OpenEuphoria

1. Eu improvements (part 4)

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

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

3. Re: Eu improvements (part 4)

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

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

5. Re: Eu improvements (part 4)

• Posted by c.k.lester <euphoric at cklester.com> Jan 05, 2007
• 685 views

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

7. Re: Eu improvements (part 4)

• Posted by Jason Gade <jaygade at yahoo.com> Jan 05, 2007
• 676 views

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.

9. Re: Eu improvements (part 4)

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

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

11. Re: Eu improvements (part 4)

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

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

13. Re: Eu improvements (part 4)

• Posted by Jason Gade <jaygade at yahoo.com> Jan 05, 2007
• 716 views

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.

15. Re: Eu improvements (part 4)

• Posted by Jason Gade <jaygade at yahoo.com> Jan 05, 2007
• 678 views

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.

17. Re: Eu improvements (part 4)

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

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

19. Re: Eu improvements (part 4)

• Posted by Jason Gade <jaygade at yahoo.com> Jan 05, 2007
• 684 views

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.

21. Re: Eu improvements (part 4)

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

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

23. Re: Eu improvements (part 4)

• Posted by c.k.lester <euphoric at cklester.com> Jan 05, 2007
• 688 views
• Last edited Jan 06, 2007

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.

25. Re: Eu improvements (part 4)

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

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

27. Re: Eu improvements (part 4)

• Posted by c.k.lester <euphoric at cklester.com> Jan 05, 2007
• 736 views
• Last edited Jan 06, 2007

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?

29. Re: Eu improvements (part 4)

• Posted by c.k.lester <euphoric at cklester.com> Jan 05, 2007
• 712 views
• Last edited Jan 06, 2007

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.

31. Re: Eu improvements (part 4)

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

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

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

33. Re: Eu improvements (part 4)

• Posted by c.k.lester <euphoric at cklester.com> Jan 05, 2007
• 687 views
• Last edited Jan 06, 2007

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

35. Re: Eu improvements (part 4)

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

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

37. Re: Eu improvements (part 4)

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

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

39. Re: Eu improvements (part 4)

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

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

41. Re: Eu improvements (part 4)

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

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 )

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

> Moving from dictatorship to democracy is not 
> a simple process.  
>
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...

43. Re: Eu improvements (part 4)

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

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.

45. Re: Eu improvements (part 4)

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jan 06, 2007
• 681 views

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 
Pete

47. Re: Eu improvements (part 4)

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

James W Hofmann wrote:
> 
> Karl Bochert wrote:
> > The intention is to access the elements by name. If you want to access by
> > index, you should use a plain unstructured sequence.
> 
> In that case, please don't call them "sequences." That is
> misleading. Sequence means indexing to me. And "structured" is
> not very meaningful except in relation to C structs, or the practice
> of "structured programming," which is mostly about flow of execution
> but when taken in this context led me to believe it must have been
> about type checking(a practice that came into vogue at the same time
> as structured programming).
Sorry -- I'm open to any name.

> 
> Hence, my remarks on typing and indexing. I don't have any major
> problem with the concepts, but I do disagree with how they are
> presented.
> I think it would be a good idea to extend type to support
> these things. So I will propose something and see if you like it.
> 
> You could have two syntaxes:
> 
> }}}
<eucode>
> 
> type Point(sequence s) -- classic syntax
>     ...
>     return checkval
> end type


> type Point is -- like SS
>     atom x,y
>     (where)
>     ...
>     (requiring)
>     ...
>     return checkval
> end type
> 
> </eucode>
{{{

> 
> 1. "Is" now tells us that Point is going to contain several 
> variables(ignoring their internal representation; whether it
> should be accessable as a sequence or not is tangential to
> the major functionality of named access)
>
Good. the 'is differentiates it from a 'normal' type
 
> 2. "Where" lets us initialize these variables each type we
> instantiate a Point. This is optional, hence the (), which would
> not appear in real code.
>
Why 'where'?
why not just
   atom x = 0.0, y = 0.0
 
> The "Point.x = 5" example of setting the initialization is still
> valid, but I think "where" is a bit cleaner since it keeps that 
> inside the same code block.

Why complicate it with code at all? The original type() has code, and
the syntax looks like code.  The new version simply states
what a point is.
 
> 
> 3. "Requiring" is the original use of type, the checking
> functionality. But since we aren't using a sequence representation
> there is no reason for a parameter to be passed. Instead we would
> only refer to the variables that "is" declared, in this case x and
> y. Note that there would be two checks, one for is and one for
> requiring.
I don't understand.

> 
> The "extends" syntax can apply as in your SS proposal, with
> the "where" and "requiring" keywords causing an override of the
> original declaration.
If you have the where and requiring (which I don't want) along with
extends, then I suspect the two requiring's might be more complex,
but then I need a better explanation of requiring.

KtB

49. Re: Eu improvements (part 4)

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

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

51. Re: Eu improvements (part 4)

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jan 06, 2007
• 714 views

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

53. Re: Eu improvements (part 4)

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jan 06, 2007
• 701 views

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

55. Re: Eu improvements (part 4)

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

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

57. Re: Eu improvements (part 4)

• Posted by cklester <cklester at yahoo.com> Jan 06, 2007
• 684 views
• Last edited Jan 07, 2007

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/

59. Re: Eu improvements (part 4)

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

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

61. Re: Eu improvements (part 4)

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jan 07, 2007
• 658 views

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

63. Re: Eu improvements (part 4)

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

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

65. Re: Eu improvements (part 4)

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

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

67. Re: Eu improvements (part 4)

• Posted by ags <eu at 531pi.co.nz> Jan 07, 2007
• 690 views

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

69. Re: Eu improvements (part 4)

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jan 11, 2007
• 713 views

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.

71. Re: Eu improvements (part 4)

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

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

73. Re: Eu improvements (part 4)

• Posted by Chris Bensler <bensler at nt.net> Jan 11, 2007
• 674 views
• Last edited Jan 12, 2007

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

75. Re: Eu improvements (part 4)

• Posted by Chris Bensler <bensler at nt.net> Jan 11, 2007
• 681 views
• Last edited Jan 12, 2007

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