OpenEuphoria

Re: Eu improvements (part 4)

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

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