1. Breaking the silence
It's fair enough that people think we don't care when we rarely speak, but just
so you don't think it's true ...
I think Euphoria's personality, as Jacques correctly put it, is founded on the
use of close-to-natural language, like pseudo-code.
Things like this:-
while 1 label something do whatever
while 1 do "top" statements
that (perhaps) look sensible when viewed next to traditional programming
languages, are complete gibberish in a natural language context. It's got nothing
to do with it being English. The constructs in other Western languages are
similar. If we want to label something, put the label at the top of the block
outside the natural language sentential flow. Because of Euphoria's style, I
prefer explicit labelling like:-
label outer:
while etc
However, the more I see the useful discussion on this, and remember my own
problems, the more I think we all have to bite the bullet on backward jumps
within blocks. You often want to retry something earlier within a block, but it's
not always at the start of a block. Sometimes you want to retry the code
immediately following the error or validity checking, or some such thing.
Sometimes you just want to go back 2 lines, and don't want to wrap it in a
procedure that excises the code to a distant place.
I favour allowing backward references to labels within blocks. For clarity, I
would like the labels to be marked in language, not symbols, and would prefer
that they have their own line (like in VB), though that is contrary to usual
Euphoria convention. I would include all blocks, if, while, for, proc, func. This
need comes up quite often, it is not due to illogical coding, and the
alternatives are often barbarous.
The demand for forward jumps is less, but the discussion about fall-throughs in
case statements highlights that it is an issue. The typical conditional involves
a forward jump. Should the default for a case fall-through, or jump to the end. I
would support forward jumps to labels in blocks, but would not be horrified if
they were omitted. Forward jumps could be used to fall through, and you wouldn't
necessarily have to fall to the next level.
I'm not mad on optional keywords, don't really like them, but not as horrified
as others. I often forget the 'then' or 'do' because I more often code in C. I
like the fact that Euphoria makes me state the logic, even though I swear harder
than most when I regularly leave out these keywords. One thing I don't do is
spend hours figuring out what I did wrong.
Not sure how many people I would represent, but I can assure you that there are
some lurkers who are actually very interested and concerned at the future of the
language. I must have become a registered user in about 1999, and barely a day
has gone by since then when I didn't read the list.
Best of luck
Pete Robinson
2. Re: Breaking the silence
Peter Robinson wrote:
>
> It's fair enough that people think we don't care when we rarely speak, but
> just
> so you don't think it's true ...
Hey, Peter! Thanks for speaking up...
I don't want you to think that I think you don't care. That was one option
I suggested that means you don't care to speak up, not that you don't care
about Euphoria or its development direction.
If you see changes being made to Euphoria with which you vehemently disagree,
I would hope that you- and everybody else who feels the same way- would
contribute an option or viewpoint in relevant discussion threads. Otherwise,
you do leave it up to a select few.
Of course, if you trust those select few- like I do- to keep Euphoria
usable and fast, you can sit back and work on your programming projects
without a concern.
> However, the more I see the useful discussion on this, and remember my own
> problems,
> the more I think we all have to bite the bullet on backward jumps within
> blocks.
> You often want to retry something earlier within a block, but it's not always
> at the start of a block. Sometimes you want to retry the code immediately
> following
> the error or validity checking, or some such thing. Sometimes you just want
> to go back 2 lines, and don't want to wrap it in a procedure that excises the
> code to a distant place.
I like the ideas of continue, retry, and exit for both program flow control
and error handling... even if I can't immediately come up with pseudo-code
that demonstrates its effective use.
> Not sure how many people I would represent, but I can assure you that there
> are some lurkers who are actually very interested and concerned at the future
> of the language. I must have become a registered user in about 1999, and
> barely
> a day has gone by since then when I didn't read the list.
Howdy, lurkers! I appreciate all of you. :D
3. Re: Breaking the silence
Hi CK
Thanks for reply. I certainly wasn't bothered by anyone's comments, nor by their
actions in advancing Euphoria. In view of the fact that I'm responsible for not
speaking up often, I think it's fair enough that people read some indifference
into that.
But I have been looking at a pattern requiring backward jumps:-
<pre-loop loop-related initialisations>
<pre-loop loop-related statements>
<outer loop start>
<stuff>
<inner loop start>
<error tests>
<general data check>
<if start>
<case 1> -- data passes with flying colours
<do the business>
<case 2> -- data not right, but not hopeless
<modify or prune data>
<retry> -- goto ????????????
<case 3> -- different data not right, not hopeless
<modify or prune data>
<retry> -- goto ????????????
<case 4> -- hopeless data
<return or exit>
<end if>
<end inner loop>
<end outer loop>
This is a fairly typical pattern where you might want to back up. The <elements>
could represent statements or groups of statements with or without more loops and
conditionals.
What are the likely re-try points for the retries in this pattern?
I think they could easily be before the pre-loop code, at the start of the outer
loop (either before or after another increment of the loop), after the error
tests or the general data check (since the data has already passed those tests)
or before case 1. I don't think you can say that one of those is overwhelmingly
more likely than another. Nor can you say that a programmer who visualises an
algorithm in this way is off his scone. So, the software tool (the language)
should allow him to map these thoughts to code as directly as possible, without
having to re-frame them or translate them into a different concept.
The present solutions sometimes have problems. If you want to jump to the
pre-initialisation point you could wrap up the pre-code in a procedure, the loop
in a different procedure, then call both (the second recursively) from within the
conditional. But this can be awkward if the two retry cases want different parts
of the precode, or if the excised code, removed from context, is meaningless
(leading to a mysterious procedure dissociated from its context), or if it's all
just too messy.
Jumping within a loop is more complicated because a procedure may need to read
and write substantial local data that has to be passed or globalised. It can also
be harder to hive off code into a procedure because the desired code is in the
midst of nested blocks. For example, the desired routine might include the 'end
if', but not the 'if' (e.g Its natural start is an 'elsif'. In this case, you
have to break up the select-case flow into pieces).
In the example, if you want to jump back to the start of the conditional, you
could simply jump back to the start of the inner loop and redundantly re-run code
that you know will pass because the data has already passed that way. I suspect a
lot of us do that to save trouble.
Flags, or tagging the reformed data, can also be a solution, but it means extra
conditional checks on the majority data to check for a minority cases.
If someone thinks these solutions are good, they should ask themselves why they
want a 'continue' construct, as the same solutions apply to it.
Since the problem involves retreats to different spots, things like 'continue'
can only ever be a partial solution. So after reading all the stuff on
'continue', I have gone over to the 'jumps within blocks' stable.
Cheers
Peter Robinson
4. Re: Breaking the silence
Peter Robinson wrote:
>
> Hi CK
>
> Thanks for reply. I certainly wasn't bothered by anyone's comments, nor by
> their
> actions in advancing Euphoria. In view of the fact that I'm responsible for
> not speaking up often, I think it's fair enough that people read some
> indifference
> into that.
>
> But I have been looking at a pattern requiring backward jumps:-
>
> <pre-loop loop-related initialisations>
> <pre-loop loop-related statements>
> <outer loop start>
> <stuff>
> <inner loop start>
> <error tests>
> <general data check>
> <if start>
> <case 1> -- data passes with flying colours
> <do the business>
> <case 2> -- data not right, but not hopeless
> <modify or prune data>
> <retry> -- goto ????????????
> <case 3> -- different data not right, not hopeless
> <modify or prune data>
> <retry> -- goto ????????????
> <case 4> -- hopeless data
> <return or exit>
> <end if>
> <end inner loop>
> <end outer loop>
>
> This is a fairly typical pattern where you might want to back up. The
> <elements>
> could represent statements or groups of statements with or without more loops
> and conditionals.
>
> What are the likely re-try points for the retries in this pattern?
>
> I think they could easily be before the pre-loop code, at the start of the
> outer
> loop (either before or after another increment of the loop), after the error
> tests or the general data check (since the data has already passed those
> tests)
> or before case 1. I don't think you can say that one of those is
> overwhelmingly
> more likely than another. Nor can you say that a programmer who visualises an
> algorithm in this way is off his scone.
Thanks so much for stating the following:
> So, the software tool (the language)
> should allow him to map these thoughts to code as directly as possible,
> without
> having to re-frame them or translate them into a different concept.
>
I'd like to see this principle overriding any simplicity based concept in the
design of Euphoria. Quite a few things need to be done to this end.
> The present solutions sometimes have problems. If you want to jump to the
> pre-initialisation
> point you could wrap up the pre-code in a procedure, the loop in a different
> procedure, then call both (the second recursively) from within the
> conditional.
> But this can be awkward if the two retry cases want different parts of the
> precode,
> or if the excised code, removed from context, is meaningless (leading to a
> mysterious
> procedure dissociated from its context), or if it's all just too messy.
>
> Jumping within a loop is more complicated because a procedure may need to read
> and write substantial local data that has to be passed or globalised. It can
> also be harder to hive off code into a procedure because the desired code is
> in the midst of nested blocks. For example, the desired routine might include
> the 'end if', but not the 'if' (e.g Its natural start is an 'elsif'. In this
> case, you have to break up the select-case flow into pieces).
>
> In the example, if you want to jump back to the start of the conditional, you
> could simply jump back to the start of the inner loop and redundantly re-run
> code that you know will pass because the data has already passed that way. I
> suspect a lot of us do that to save trouble.
>
> Flags, or tagging the reformed data, can also be a solution, but it means
> extra
> conditional checks on the majority data to check for a minority cases.
>
> If someone thinks these solutions are good, they should ask themselves why
> they
> want a 'continue' construct, as the same solutions apply to it.
>
> Since the problem involves retreats to different spots, things like 'continue'
> can only ever be a partial solution. So after reading all the stuff on
> 'continue',
> I have gone over to the 'jumps within blocks' stable.
>
If "retry" makes its way into the language (who knows, after all Æ has it), then
you can do
label "retry-it"
while <whatever> do
<code to jump back to>
if do_that_again() then
retry "retry-it"
end if
-- stuff
end while
> Cheers
> Peter Robinson
CChris
5. Re: Breaking the silence
Yes, and it reads simply, intuitively, wherever the jump label occurs. If the
placement is constrained by a block, then I don't see a risk of accidental
spaghetti code. Of course, if you think like spaghetti ... GIGO
Cheers
Peter
6. Re: Breaking the silence
CChris wrote:
>
> Peter Robinson wrote:
>
> > So, the software tool (the language)
> > should allow him to map these thoughts to code as directly as possible,
> > without having to re-frame them or translate them into a different concept.
>
> I'd like to see this principle overriding any simplicity based concept in the
> design of Euphoria. Quite a few things need to be done to this end.
I don't disagree with this sentiment, but we've obviously had disagreements
about how to translate something into code in the past. It's relatively
easy to do this for a special purpose language or library. Less so for
something meant to be general purpose.
But I don't think that we should ignore simplicity. Especially when something
simple gets the same job done as something complex. In general, simpler
things are easier to remember, and easier to do correctly. Also, different
people will see different methods of framing as direct maps.
Matt
7. Re: Breaking the silence
CChris wrote:
>
> If "retry" makes its way into the language (who knows, after all Æ has it),
> then you can do
> }}}
<eucode>
> label "retry-it"
> while <whatever> do
> <code to jump back to>
> if do_that_again() then
> retry "retry-it"
> end if
> -- stuff
> end while
> </eucode>
{{{
>
I think retry should be put into the language, however, for labeling, I really
do like the idea of:
while <whatever> label "retry-it" do
.......
end while
To me, that's much clearer that the label is associated with the while
statement. Otherwise people will be trying:
label "hello"
puts(1, "Hello\n")
if ask_user_sayitagain() then
retry "hello"
end if
Now, maybe that's valid in AE? If it is, I think retry is the wrong name, it
should be goto. Otherwise, I think the labeling needs to be part of the while
statement.
--
Jeremy Cowgar
http://jeremy.cowgar.com
8. Re: Breaking the silence
Jeremy Cowgar wrote:
>
> CChris wrote:
> >
> > If "retry" makes its way into the language (who knows, after all Æ has it),
> > then you can do
> > }}}
<eucode>
> > label "retry-it"
> > while <whatever> do
> > <code to jump back to>
> > if do_that_again() then
> > retry "retry-it"
> > end if
> > -- stuff
> > end while
> > </eucode>
{{{
> >
>
> I think retry should be put into the language, however, for labeling, I really
> do like the idea of:
>
> }}}
<eucode>
> while <whatever> label "retry-it" do
> .......
> end while
> </eucode>
{{{
>
> To me, that's much clearer that the label is associated with the while
> statement.
> Otherwise people will be trying:
>
> }}}
<eucode>
> label "hello"
> puts(1, "Hello\n")
> if ask_user_sayitagain() then
> retry "hello"
> end if
> </eucode>
{{{
>
> Now, maybe that's valid in AE? If it is, I think retry is the wrong name, it
> should be goto. Otherwise, I think the labeling needs to be part of the while
> statement.
>
> --
> Jeremy Cowgar
> <a href="http://jeremy.cowgar.com">http://jeremy.cowgar.com</a>
I have no religion on this. I simply wonder whether a label clause at the end of
a long text line that doesn't wrap is clearer than a plain label statement,
indented like the block header that follows, since it it would be yet another
statement. It would be ignored if not followed by a block header - so far -, so
retry is not a goto, even with a label.
But again, I have nothing against either. What about allowing both forms? The
separate label statement has been valid at some point in Æ, and I turned to a
label clause instead for ease of implementation only. This shows how much the
distinction matters to me.
CChris
9. Re: Breaking the silence
CChris wrote:
>
> Jeremy Cowgar wrote:
> >
> > CChris wrote:
> > >
> > > If "retry" makes its way into the language (who knows, after all Æ has
> > > it),
> > > then you can do
> > > }}}
<eucode>
> > > label "retry-it"
> > > while <whatever> do
> > > <code to jump back to>
> > > if do_that_again() then
> > > retry "retry-it"
> > > end if
> > > -- stuff
> > > end while
> > > </eucode>
{{{
> > >
> >
> > I think retry should be put into the language, however, for labeling, I
> > really
> > do like the idea of:
> >
> > }}}
<eucode>
> > while <whatever> label "retry-it" do
> > .......
> > end while
> > </eucode>
{{{
> >
> > To me, that's much clearer that the label is associated with the while
> > statement.
> > Otherwise people will be trying:
> >
> > }}}
<eucode>
> > label "hello"
> > puts(1, "Hello\n")
> > if ask_user_sayitagain() then
> > retry "hello"
> > end if
> > </eucode>
{{{
> >
> > Now, maybe that's valid in AE? If it is, I think retry is the wrong name, it
> > should be goto. Otherwise, I think the labeling needs to be part of the
> > while
> > statement.
> >
>
> I have no religion on this. I simply wonder whether a label clause at the end
> of a long text line that doesn't wrap is clearer than a plain label statement,
> indented like the block header that follows, since it it would be yet another
> statement. It would be ignored if not followed by a block header - so far -,
> so retry is not a goto, even with a label.
>
> But again, I have nothing against either. What about allowing both forms?
I do not think we should allow both forms. I think syntax should be set in stone
so one Euphoria application looks like another. Obviously there are style
differences puts( 1, "John" ) vs. puts(1, "John"), but everything is in the same
order. If we allow things to be rearranged, things become confusing when working
with other people or figuring out code in a library you are using.
--
Jeremy Cowgar
http://jeremy.cowgar.com
10. Re: Breaking the silence
- Posted by gshingles <gshingles at ?mail?com>
May 18, 2008
-
Last edited May 19, 2008
CChris wrote:
>
> Jeremy Cowgar wrote:
> > I think retry should be put into the language, however, for labeling, I
> > really
> > do like the idea of:
> > ...
> I have no religion on this. I simply wonder whether a label clause at the end
> of a long text line that doesn't wrap is clearer than a plain label statement,
> indented like the block header that follows, since it it would be yet another
> statement. It would be ignored if not followed by a block header - so far -,
> so retry is not a goto, even with a label.
>
> But again, I have nothing against either. What about allowing both forms? The
> separate label statement has been valid at some point in Æ, and I turned to
> a label clause instead for ease of implementation only. This shows how much
> the distinction matters to me.
I think that's a good point about the label not standing out, particularly if it
is at the end of a very long line.
I don't know if it is bad practise to put so many conditional tests in a loop
condition test but it is the way I tend to work in Euphoria, rapidly, and
Euphoria greatly reduces the chances that you are accidentally assigning, or
incrementing, or looking at the wrong pointer, or not dereferencing the array
reference instead of the array index etc etc in any of the tests, that I am
comfortable doing that.
However, if you see a 'retry label' later in the code it probably won't take
that much effort to track down which loop it is referring to.
Gary
