OpenEuphoria

2. Re: Optional "then" and "do"

• Posted by Marco Achury <achury at cantv.??t> May 14, 2008
• 975 views

I have not problem with type as ed.exe complete the expression.

I like the change, specially in for, this way looks a lot like 
the BASIC FOR.

The only bad thing is the error message will be less clear for 
newbies, the parser must to difference if the error is at the 
boolean condition or in the first statement after it.

+-+-+-+-+-+-+-+
Marco A. Achury
Caracas, Venezuela

4. Re: Optional "then" and "do"

• Posted by Jason Gade <jaygade at yah?o?com> May 14, 2008
• 951 views

yuku wrote:
> 
> I made changes to the parser.e so that the keyword "then" and "do"
> is optional (if the coder wants that it is still accepted).
> 
> Reasons:
> 
> - Less typing
> 
> - Prevent mistakes of writing if <expr> do  and  for <expr> then
>   which I did a lot of times (Kat too)
> 
> If no real objection is made, I will commit it.

Can you give some examples of code doing this? I mean, how optional is it?

I'm mainly wondering whether the parser relies on the keyword "then" or "do"
being between <expr> and <statement>. I don't know enough about the internals  to
say.

I've never really had a problem with "then" or "do" (except occasionally
forgetting "do") but I also don't have a problem with removing them if there is
no major effect.

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

6. Re: Optional "then" and "do"

• Posted by yuku <yuku at i?itek.?om> May 14, 2008
• 958 views

Jason Gade wrote:
> Can you give some examples of code doing this? I mean, how optional is it?

Every then and do become optional. It doesn't matter where it is placed.

> I'm mainly wondering whether the parser relies on the keyword "then" or "do"
> being
> between <expr> and <statement>. I don't know enough about the internals
>  to say.

I looked at the internals, and the parser only *asserts* that there are THENs
and DOs
on the correct places. The THENs and DOs does not help the parser at all. 
There is no ambiguity generated too.

> I've never really had a problem with "then" or "do" (except occasionally
> forgetting
> "do") but I also don't have a problem with removing them if there is no major
> effect.

Oh yes, I forgot to mention that. Besides being mixed up between THEN and DO,
occassionally I forgot to write that. What a.

8. Re: Optional "then" and "do"

• Posted by Salix <salix at free?a?l.hu> May 14, 2008
• 951 views

yuku wrote:
> 
> I made changes to the parser.e so that the keyword "then" and "do"
> is optional (if the coder wants that it is still accepted).
> Reasons:
> - Less typing
> - Prevent mistakes of writing if <expr> do  and  for <expr> then
>   which I did a lot of times (Kat too)
> If no real objection is made, I will commit it.

I am against the optional "then" and "do".

I understand if in this example it is too hard to type "then".

if apple=1 and bananas=3 then peach=7 end if

But if I tend to forget "and". The result now is

if apple=1 bananas=3 then peach=7 end if

that gives an error message. With optional "then" it would be

if apple=1 bananas=3 peach=7 end if

that is much harder to track down.

Let's not skip "do" and "then".

Regards,

Salix

10. Re: Optional "then" and "do"

• Posted by Jason Gade <jaygade at yahoo??om> May 14, 2008
• 961 views
• Last edited May 15, 2008

Fernando Bauer wrote:
> 
> Kat wrote:
> > 
> > Larry Miller wrote:
> > > 
> > > yuku wrote:
> > > > 
> > > > I made changes to the parser.e so that the keyword "then" and "do"
> > > > is optional (if the coder wants that it is still accepted).
> > > > 
> > > > Reasons:
> > > > 
> > > > - Less typing
> > > > 
> > > > - Prevent mistakes of writing if <expr> do  and  for <expr> then
> > > >   which I did a lot of times (Kat too)
> > 
> > Confirmed, especially when changing code from one loop form to another to
> > get
> > program flow to use exit correctly. I often wonder why "then" and "do"
> > aren't
> > the same word. 
> 
> Me too. I think both 'do' and 'then' exist to mark the beginning of a
> executable
> block of code. So, if they are synonyms, one of them is superfluous and could
> be eliminated (in my opinion 'then').
> 
> A similar case occurs with '..' (slice operator) and 'to' (historical note:
> ZX81 BASIC uses 'TO' for 'FOR' statements and also for slices). Both have the
> meaning of a range. In this case I would keep with '..'.
> Then, we could write something like this:
> 
> for i = 1..10 do
>    if i=3 do exit end if
> end for
> 
> [snipped]
> 
> Just some provocative thoughts! 
> 
> - Fernando

Okay, now to that I have to say "yuk!"

I mean, we may as well write
for(i = 0; i < 10; i++) {
/* do something */
}

Which certainly has its own elegance, but it isn't Euphoria.

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

12. Re: Optional "then" and "do"

• Posted by Jeremy Cowgar <jeremy at cowg?r.c?m> May 14, 2008
• 983 views
• Last edited May 15, 2008

Jason Gade wrote:
> 
> Oh, and to me, do and then really aren't synonyms so much. It's the way you
> say things in English.
> 
> Well, "then" is anyway.
> 
> if i=3 do exit end if
> 
> is very ugly to me too.
> 

I agree. do and then may be a place holder, but read very different, thus make
code cleaner and easier to read, which is very important.

--
Jeremy Cowgar
http://jeremy.cowgar.com

14. Re: Optional "then" and "do"

• Posted by Fernando Bauer <fmbauer at hotma?l.c?m> May 15, 2008
• 1005 views

Jason Gade wrote:
> 
> Fernando Bauer wrote:
> > 
> > Kat wrote:
> > > 
> > > Larry Miller wrote:
> > > > 
> > > > yuku wrote:
> > > > > 
> > > > > I made changes to the parser.e so that the keyword "then" and "do"
> > > > > is optional (if the coder wants that it is still accepted).
> > > > > 
> > > > > Reasons:
> > > > > 
> > > > > - Less typing
> > > > > 
> > > > > - Prevent mistakes of writing if <expr> do  and  for <expr> then
> > > > >   which I did a lot of times (Kat too)
> > > 
> > > Confirmed, especially when changing code from one loop form to another to
> > > get
> > > program flow to use exit correctly. I often wonder why "then" and "do"
> > > aren't
> > > the same word. 
> > 
> > Me too. I think both 'do' and 'then' exist to mark the beginning of a
> > executable
> > block of code. So, if they are synonyms, one of them is superfluous and
> > could
> > be eliminated (in my opinion 'then').
> > 
> > A similar case occurs with '..' (slice operator) and 'to' (historical note:
> > ZX81 BASIC uses 'TO' for 'FOR' statements and also for slices). Both have
> > the
> > meaning of a range. In this case I would keep with '..'.
> > Then, we could write something like this:
> > 
> > for i = 1..10 do
> >    if i=3 do exit end if
> > end for
> > 
> > [snipped]
> > 
> > Just some provocative thoughts! 
> > 
> > - Fernando
> 
> Okay, now to that I have to say "yuk!"
> 
> I mean, we may as well write
> for(i = 0; i < 10; i++) {
> /* do something */
> }
> 
> Which certainly has its own elegance, but it isn't Euphoria.

Agreed. But I'm sure that any Euphoria programmer would understand my example.
The difference is minimal, just other characters (already used) for the same
token and the advantage is: less keywords to know and to parse. You could call it
a Euphoria dialect. All things change and evolve, even if we don't want. A
computer language should also obey this natural principle. One form to evolve is
creating mutations, which in this case is a dialect. Some modifications in Eu 4.0
are more profound than these ones.
Finally, your example uses a different syntax and semantics, and not every
Euphoria programmer would understand it, so IMHO it's not a Euphoria dialect.

Anyway, thanks for your reply!
- Fernando

> 
> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
> 
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
> 
> j.

16. Re: Optional "then" and "do"

• Posted by Jason Gade <jaygade at yaho?.?om> May 15, 2008
• 973 views

Well, I guess you could write a programming language in a language other than
English if you wanted.



--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

18. Re: Optional "then" and "do"

• Posted by yuku <yuku at ?k?tek.com> May 15, 2008
• 993 views

Salix wrote:
> But if I tend to forget "and". The result now is
> 
> }}}
<eucode>
> if apple=1 bananas=3 then peach=7 end if
> </eucode>
{{{

> 
> With optional "then" it would be
> 
> }}}
<eucode>
> if apple=1 bananas=3 peach=7 end if
> </eucode>
{{{

> 
> that is much harder to track down.

You can always write the "then" if you want. 
Especially in such one-line if. 

Reason of making it optional is that it reduces the mental load of 
remembering the correct delimiter for every if, for and while statement.

20. Re: Optional "then" and "do"

• Posted by CChris <christian.cuvier at agriculture?gou?.fr> May 15, 2008
• 956 views

Jason Gade wrote:
> 
> Fernando Bauer wrote:
> > 
> > Jason Gade wrote:
> > > 
> > > I mean, we may as well write
> > > for(i = 0; i < 10; i++) {
> > > /* do something */
> > > }
> > > 
> > > Which certainly has its own elegance, but it isn't Euphoria.
> > 
> > Agreed. But I'm sure that any Euphoria programmer would understand my
> > example.
> > The difference is minimal, just other characters (already used) for the same
> > token and the advantage is: less keywords to know and to parse. You could
> > call
> > it a Euphoria dialect. All things change and evolve, even if we don't want.
> > A computer language should also obey this natural principle. One form to
> > evolve
> > is creating mutations, which in this case is a dialect. Some modifications
> > in
> > Eu 4.0 are more profound than these ones.
> > Finally, your example uses a different syntax and semantics, and not every
> > Euphoria
> > programmer would understand it, so IMHO it's not a Euphoria dialect.
> > 
> > Anyway, thanks for your reply!
> > - Fernando
> 
> Well, I can understand a lot of things, but some of these examples are
> jarring.
> 
> One of the things that I like about Euphoria is that it accomplishes the
> relatively
> difficult goal of reading very similarly to natural English without being
> overly
> wordy. I think that it strikes a happy medium.
> 

I certainly wouldn't agree with the latter.

See how much you have to write to share a state (as a sequence - no pointers)
between two functions. You can pass {x1,x2,x3}, fine.. But when the sequence
state is returned, you have to code
x1=state[1]
x2=sate[2]
etc

while {x1,x2,x3}=state is clear enough.

Just one example out of many.

CChris

> --
> A complex system that works is invariably found to have evolved from a simple
> system that works.
> --John Gall's 15th law of Systemantics.
> 
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
> 
> j.

22. Re: Optional "then" and "do"

• Posted by Matt Lewis <matthewwalkerlewis at ?mail.?om> May 15, 2008
• 961 views

yuku wrote:
> 
> Salix wrote:
> > But if I tend to forget "and". The result now is
> > 
> > }}}
<eucode>
> > if apple=1 bananas=3 then peach=7 end if
> > </eucode>
{{{

> > 
> > With optional "then" it would be
> > 
> > }}}
<eucode>
> > if apple=1 bananas=3 peach=7 end if
> > </eucode>
{{{

> > 
> > that is much harder to track down.
> 
> You can always write the "then" if you want. 
> Especially in such one-line if. 
> 
> Reason of making it optional is that it reduces the mental load of 
> remembering the correct delimiter for every if, for and while statement.

I argue that this mental load is dwarfed by the mental load required for
maintenance.

Matt

24. Re: Optional "then" and "do"

• Posted by CChris <christian.cuvier at agricultur?.gouv.?r> May 15, 2008
• 960 views

Matt Lewis wrote:
> 
> yuku wrote:
> > 
> > Salix wrote:
> > > But if I tend to forget "and". The result now is
> > > 
> > > }}}
<eucode>
> > > if apple=1 bananas=3 then peach=7 end if
> > > </eucode>
{{{

> > > 
> > > With optional "then" it would be
> > > 
> > > }}}
<eucode>
> > > if apple=1 bananas=3 peach=7 end if
> > > </eucode>
{{{

> > > 
> > > that is much harder to track down.
> > 
> > You can always write the "then" if you want. 
> > Especially in such one-line if. 
> > 
> > Reason of making it optional is that it reduces the mental load of 
> > remembering the correct delimiter for every if, for and while statement.
> 
> I argue that this mental load is dwarfed by the mental load required for
> maintenance.
> 
> Matt

If using proper indentation to start and end code blocks, you'd get clearer code
with less typing:

if something()
    do_stuff()
    while true
        poll_channel()
-- end of all three blocks

Do away with end, do and then in one sweep.
Make code structure visually clear, making maintainance easier. How clear is a
sequence of interspersed "end if", "end for" and "end while"?

All editors I know, except Notepad, have a detab command. The only drawback of
the above is the stronger need to use it when pasting code from other files.

CChris
CChris

26. Re: Optional "then" and "do"

• Posted by ChrisBurch3 <crylex at gm?il.co?> May 15, 2008
• 967 views

Hi

Rarely chipping in into the (too?) rapidly evolving euphoria language.

De blocking blocks of code with optional then then-do-ends will make for
ugly, hard to maintain code, I for one vote strongly against this.

As annoying as it is to keep on having to add do s and thens at run time, 
it makes the code much easier to read, and maintain later on.

This commit should be de-commited asap.

Chris

28. Re: Optional "then" and "do"

• Posted by Derek Parnell <ddparnell at b?gpond.?om> May 15, 2008
• 985 views

Matt Lewis wrote:
> 
> yuku wrote:
> > If no real objection is made, I will commit it.
> 
> Though it has already been committed as I write this, I object. 

What!? 

Yuku, I think you were way too quick to commit this. Please, in future, discuss
and get agreement/commitment BEFORE you commit stuff, especially things that are
debatable.

I STRONGLY OPPOSE THIS CHANGE.

Making these delimiters optional will cause coding and maintenance errors. And
the benefit ??? ... I just can see why this is a 'good thing'.

-- 
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell

30. Re: Optional "then" and "do"

• Posted by Jason Gade <jaygade at ya?oo.c?m> May 15, 2008
• 953 views

CChris wrote:
> 
> Matt Lewis wrote:
> > 
> > yuku wrote:
> > > 
> > > Salix wrote:
> > > > But if I tend to forget "and". The result now is
> > > > 
> > > > }}}
<eucode>
> > > > if apple=1 bananas=3 then peach=7 end if
> > > > </eucode>
{{{

> > > > 
> > > > With optional "then" it would be
> > > > 
> > > > }}}
<eucode>
> > > > if apple=1 bananas=3 peach=7 end if
> > > > </eucode>
{{{

> > > > 
> > > > that is much harder to track down.
> > > 
> > > You can always write the "then" if you want. 
> > > Especially in such one-line if. 
> > > 
> > > Reason of making it optional is that it reduces the mental load of 
> > > remembering the correct delimiter for every if, for and while statement.
> > 
> > I argue that this mental load is dwarfed by the mental load required for
> > maintenance.
> > 
> > Matt
> 
> If using proper indentation to start and end code blocks, you'd get clearer
> code with less typing:
> }}}
<eucode>
> if something()
>     do_stuff()
>     while true
>         poll_channel()
> -- end of all three blocks
> </eucode>
{{{

> 
> Do away with end, do and then in one sweep.
> Make code structure visually clear, making maintainance easier. How clear is
> a sequence of interspersed "end if", "end for" and "end while"?
> 
> All editors I know, except Notepad, have a detab command. The only drawback
> of the above is the stronger need to use it when pasting code from other
> files.
> 
> CChris
> CChris

There's already a language that does this, it's called Python.

Mandatory indentation? No thanks.

--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.

"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare

j.

32. Re: Optional "then" and "do"

• Posted by Larry Miller <larrymiller at saskt?l?net> May 15, 2008
• 995 views

yuku wrote:
> 
> I made changes to the parser.e so that the keyword "then" and "do"
> is optional (if the coder wants that it is still accepted).
> 
> Reasons:
> 
> - Less typing
> 
> - Prevent mistakes of writing if <expr> do  and  for <expr> then
>   which I did a lot of times (Kat too)
> 
> If no real objection is made, I will commit it.

I know the changes have already been made at this time but I must still object.
It is not too late to change this.

Yes, removing the necessity of typing "do" and "then" may speed initial coding,
at least for some. But not for me, and I suspect many others as well. I will
continue to add them, even for a quick and dirty test.

As any experienced programmer would agree, the real cost in writing software is
not the initial coding. It is in debugging and maintenance. I believe that "do"
and "then" make it easier to read code, particularly when it is complex and
written by others.

Rob Craig had a reason for adding "do" and "then". If they are not needed by the
interpreter they must have been for the benefit of the programmer. After reading
many of his posts about the design of Euphoria I have come to the conclusion that
everything was well thought out, nothing was done on a whim. And I think few
would disagree, most of these decisions were correct. We might disagree about the
details but that will always be inevitable in this world.

Larry Miller

34. Re: Optional "then" and "do"

• Posted by ChrisBurch2 <crylex at ?reeuk.?o.uk> May 15, 2008
• 995 views

yuku wrote:
> 
> ChrisBurch3 wrote:
> > This commit should be de-commited asap.
> 
> Done :)

36. Re: Optional "then" and "do"

• Posted by jacques deschênes <desja at g?obetr?tter.net> May 16, 2008
• 960 views

oops! some of my text have been drop in posting (bug in euforum maybe??)

jacques deschênes wrote:
> 
> 
> I almost missed it!! What are you trying to do with euphoria? I'm opposed to
> this.  It's not that I like the "then" and "do". But its part of the
> personnality
> of euphoria.  Is this euphoria or a new language that you want?
> surely C and Java have it better, a block structure is a block structure and
> all blocks should be opended and closed with the sames tokens, for exemples:
<missing part>
opening and closing curly brace open and close all blocks of code in C and Java,
I prefer it, but euphoria as is
</missing part>
> personnality and it should keep it. 
> 
> There is so much posting lately I don't have time to read it all. If I don't
> comment or vote on every suggestion it is because I lack time. I guess I'm not
> alone so don't say that people that don't give their opinion, don't care.
> concerning suggestions for euphoria 4.0, slow don't you move to fast.
> 
> Jacques Deschênes

38. Re: Optional "then" and "do"

• Posted by Michael J. Sabal <m_sabal at ?ah?o.com> May 16, 2008
• 954 views

Keep in mind, syntax errors (missing and, missing then, missing do) are much 
easier to find and fix than logic errors (variable being assigned value 1
instead of testing for value 1).

This feature should only be allowed by a without header, making then and do
still required by default.

In other words, if the programs starts,

without thendo

and later you see

if a = 1
   b = 2
   c = 3
end if

a will be tested, b will be assigned, and c will be assigned.  
If the intention was to test b, there will be a logic error that won't appear
until much later in the execution.

On the other hand, if the without thendo statement is missing, this code
will immediately terminate before execution with an error that something is
missing, pointing directly to this line in the program, and creating an
ex.err file.  Even though I think it's a hassle to always type then and do,
I would much rather be forced to do that knowing that I won't have any logic
errors because of a missing and/or/then than have to spend several hours 
trying to hunt down why my program isn't working the way it's supposed to.

40. Re: Optional "then" and "do"

• Posted by Michael J. Sabal <m_sabal at y?hoo?com> May 16, 2008
• 959 views

Jeremy Cowgar wrote:
> 
> I don't think we should introduce syntax changes based on with/without
> settings
> for two reasons:
> 
> 1. Now the interpreter every time it hits a if, for, or while loop has to
> check,
> "Do we require then/do?" if so, it has to do one thing, otherwise, do
> something
> else. To program, this is easy, but do we want to introduce this into the
> parser?
> I think we need to keep Eu as fast as reasonably possible.
> 
> 2. Say John never uses then/do. Jane does. Now John join's Jane's project and
> he has a hard time understanding some code, reading some code, etc...
> 
> I think Eu syntax should be the same on John's code or Jane's code.
> 
> If we allow setting of optional then/do's, we could then also, just as easy,
> allow the setting of is the keyword "continue" or "next"? So in some code you
> read you will see continue and in other code you will see next. That's taken
> a bit further than suggested, but it just helps to make the point. Eu syntax
> should be Eu syntax.

Then absolutely remove this change!  I like fixing bugs in 2 minutes rather
than two hours.  Don't break a good thing.  Rob was very slow to make
changes because Euphoria FORCED you code correctly, as much as it could.
Removing that removes the core of what makes Euphoria a superior language.
This is a deal-breaker issue.  I'll go along with rearranging the standard
includes.  I'll support improving namespaces.  Heck, I don't care if you
continue, exit, or goto.  None of those changes are going to (had better not)
slow down the creation, debugging, or execution of my code.  Making 
conditional statement end-tags optional is akin to chopping off one of the 
legs of a three-legged stool.  DON'T DO IT!

42. Re: Optional "then" and "do"

• Posted by Phil Russell <pg_russell at l?ne?ne.net> May 16, 2008
• 970 views

<unlurk>

Somewhat belatedly, I *don't* want "then" and "do" to 
be optional. I wouldn't like the current straightforward
syntax to be complicated just to save a couple of keystrokes.

wrt goto:  I'm with Jacques Deschenes on this one - within a
code block only. That said, I haven't used one in 15 years,
and I ain't about to start now...

Cheers,

Phil
</unlurk>

44. Re: Optional "then" and "do"

• Posted by Shawn Pringle <shawn.pringle at ?mail.co?> May 18, 2008
• 959 views

I suppose you have used cobol and fortran then.  I myself have never used
those two languages and I get the impression that most people here are of
the C/Java syntax users.  I used to use basic but that is as early as I 
get.  Is there anything missing, in terms of library functions or constructs
that these languages had that EUPHORIA should?

Shawn Pringle


Arthur Crump wrote:
> 
> I use Judith Evan's editor which fills in 'if' and 'for' blocks, so
> I don't have anything extra to type.  However, I agree with Phil Russell
> that they should not be optional, although it is only a slight preference.
> 
> As for 'goto' I do not approve of 'goto'.
> I started programming with low level languages (in 1958) and moved on to
> languages in which 'goto' was the only method of flow control.  Now that
> it is not there, I don't miss it and would not use it if it was implemented,
> provided that a 'next' (or 'continue' if that is what it has to be) was
> implemented.
> 
> Arthur Crump
> 
> 
> Phil Russell wrote:
> > 
> > <unlurk>
> > 
> > Somewhat belatedly, I *don't* want "then" and "do" to 
> > be optional. I wouldn't like the current straightforward
> > syntax to be complicated just to save a couple of keystrokes.
> > 
> > wrt goto:  I'm with Jacques Deschenes on this one - within a
> > code block only. That said, I haven't used one in 15 years,
> > and I ain't about to start now...
> > 
> > Cheers,
> > 
> > Phil
> > </unlurk>