1. "case" or better? (2.6 suggestion mode)
I erm, don't erm, oh... Sigh 
))
I recently found I had written this, to handle five distinct
functions; escape key (==Cancel), return key (==OK), pressing the OK
and Cancel buttons, and closing the window:
if msg = WM_CHAR then
if wParam = VK_ESCAPE then
id = PFcncl
msg = WM_COMMAND
elsif wParam = VK_RETURN then
msg = WM_COMMAND
end if
end if
if msg = WM_COMMAND then
if id = PFcncl then -- cancel
FaceIdx=InitFaceIdx
PointIdx=InitPointIdx
applyFont()
-- else assume PFOK
end if
msg = WM_CLOSE
end if
if msg = WM_CLOSE then
isFaceName = faces[FaceIdx]
if FaceIdx>=5 then
isPointSize = sizes[FaceIdx][PointIdx]
end if
setVisible(PFwin,False)
return 1
end if
return 0
Of course, it works perfectly )
What I've done is repeatedly reset a controlling var to "fall through"
I perhaps naturally /thought/ I could rewrite it better using case,
but I couldn't. It was so appalling I refuse to post it here.
Three points sprang to mind:
1) the main argument for case is the "fall through"
2) the main argument against case is the "fall through" / forgetting
break.
3) I vote No Thanks.
It just reminded me why case/select sucks.
Regards,
Pete
2. Re: "case" or better? (2.6 suggestion mode)
Pete Lomax wrote:
<big snip>
> Three points sprang to mind:
> 1) the main argument for case is the "fall through"
> 2) the main argument against case is the "fall through" / forgetting
> break.
>
> 3) I vote No Thanks.
>
> It just reminded me why case/select sucks.
It depends on the concrete way how the "case" statement is implemented.
Yes, in C, there is a "fall through" when "break" is not used.
But e.g. in PowerBASIC, there is no "break" (or equivalent) keyword:
year = 2001
select case year
case 1900 to 1910, 1912
print "Once upon a time ..."
case 1960 to 1969
print "In the sixties ..."
case > 2000
print "Recently ..."
case else
print "Hmm?"
end select
This is equivalent to
integer year
year = 2001
if (1900 <= year and year <= 1910) or year = 1912 then
puts(1, "Once upon a time ...\n")
elsif 1960 <= year and year <= 1969 then
puts(1, "In the sixties ...\n")
elsif year > 2000 then
puts(1, "Recently ...\n")
else
puts(1, "Hmm?\n")
end if
In PowerBASIC, there is no "fall through" possible at all.
Of course, when you say:
| 1) the main argument for case is the "fall through"
then there is no main argument for implementing the "case" statement
this way.
Regards,
Juergen
3. Re: "case" or better? (2.6 suggestion mode)
Pete Lomax wrote:
>
>
> I erm, don't erm, oh... Sigh ))
>
> I recently found I had written this, to handle five distinct
> functions; escape key (==Cancel), return key (==OK), pressing the OK
> and Cancel buttons, and closing the window:
>
> }}}
<eucode>
> if msg = WM_CHAR then
> if wParam = VK_ESCAPE then
> id = PFcncl
> msg = WM_COMMAND
> elsif wParam = VK_RETURN then
> msg = WM_COMMAND
> end if
> end if
> if msg = WM_COMMAND then
> if id = PFcncl then -- cancel
> FaceIdx=InitFaceIdx
> PointIdx=InitPointIdx
> applyFont()
> -- else assume PFOK
> end if
> msg = WM_CLOSE
> end if
> if msg = WM_CLOSE then
> isFaceName = faces[FaceIdx]
> if FaceIdx>=5 then
> isPointSize = sizes[FaceIdx][PointIdx]
> end if
> setVisible(PFwin,False)
> return 1
> end if
> return 0
> </eucode>
{{{
>
>
> Of course, it works perfectly )
> What I've done is repeatedly reset a controlling var to "fall through"
>
> I perhaps naturally /thought/ I could rewrite it better using case,
> but I couldn't. It was so appalling I refuse to post it here.
>
> Three points sprang to mind:
> 1) the main argument for case is the "fall through"
> 2) the main argument against case is the "fall through" / forgetting
> break.
>
> 3) I vote No Thanks.
>
> It just reminded me why case/select sucks.
> Regards,
> Pete
>
>
Hi Pete,
Very interesting. Can i ask why you want to have multiple if's
process the same message?
I think the argument *for* the 'case' statement is to have a single test
determine
where to jump in the program so you dont have to wait for 100 elsif's
to fail before you get to the 101'th elsif.
This of course can be done with routine id's at the expense of some
added program complexity.
Take care,
Al
And, good luck with your Euphoria programming!
My bumper sticker: "I brake for LED's"
4. Re: "case" or better? (2.6 suggestion mode)
On Sun, 03 Apr 2005 08:28:03 +0200, Juergen Luethje <j.lue at gmx.de>
wrote:
>It depends on the concrete way how the "case" statement is implemented.
>Yes, in C, there is a "fall through" when "break" is not used.
>
>But e.g. in PowerBASIC, there is no "break" (or equivalent) keyword:
Ah, I didn't know that, I've never used PB.
Pete
5. Re: "case" or better? (2.6 suggestion mode)
On Sat, 02 Apr 2005 23:09:48 -0800, Al Getz <guest at RapidEuphoria.com>
wrote:
>Very interesting. Can i ask why you want to have multiple if's
>process the same message?
I'm not sure I understand your question. I suppose I could have
written:
procedure Cancel()
FaceIdx=InitFaceIdx
PointIdx=InitPointIdx
applyFont()
end procedure
function Close()
isFaceName = faces[FaceIdx]
if FaceIdx>=5 then
isPointSize = sizes[FaceIdx][PointIdx]
end if
setVisible(PFwin,False)
return 1
end function
...
if msg = WM_CHAR and wParam = VK_ESCAPE then
Cancel()
return Close()
elsif (msg = WM_CHAR and wParam = VK_RETURN)
or msg = WM_COMMAND then
if id = PFcncl then
Cancel()
end if
return Close()
elsif msg = WM_CLOSE then
return Close()
end if
return 0
Is that what you meant?
>I think the argument *for* the 'case' statement is to have a single test
>determine
>where to jump in the program so you dont have to wait for 100 elsif's
>to fail before you get to the 101'th elsif.
Any gain is only possible if you restrict the proposed case statement
to dealing with a range of n positive integers 1..n, where n must be
known at compile-time. Otherwise, in terms of performance, a case
statement is doomed to be no faster than a huge if/elsif statement,
especially if you want things like unbounded ranges (eg x>2000) or
default clauses, or be able to deal with things like windows messages,
or the dynamically-generated win32lib control-ids, even if they are
declared as "constants". Theoretically, it is not difficult to
optimise away the repeated loads if consecutive elsif clauses have the
same lhs, although I doubt Rob currently does this. I suspect you are
imagining a performance gain which is not going to materialise.
Regards,
Pete
6. Re: "case" or better? (2.6 suggestion mode)
- Posted by Eglenn4511 at aol.com
Apr 03, 2005
-------------------------------1112546331
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In a message dated 4/3/2005 7:06:03 A.M. Mountain Standard Time,
petelomax at blueyonder.co.uk writes:
>I think the argument *for* the 'case' statement is to have a single test
determine
>where to jump in the program so you dont have to wait for 100 elsif's
>to fail before you get to the 101'th elsif.
Any gain is only possible if you restrict the proposed case statement
to dealing with a range of n positive integers 1..n, where n must be
known at compile-time. Otherwise, in terms of performance, a case
Case statements may be prettier than elsif but there really isn't that much
difference in appearance or speed. The process that is both neat and fast is
'vectored execution'. A variable causes the program to jump to the proper
location without evaluating a string of if/else/then statements or
case/of/endof'/endcase statements. The programer does the evaluating when the
program is
written instead of the machine each time the program is executed.
-------------------------------1112546331
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=US-ASCII">
<META content="MSHTML 6.00.2900.2604" name=GENERATOR></HEAD>
<BODY id=role_body style="FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Arial"
bottomMargin=7 leftMargin=7 topMargin=7 rightMargin=7><FONT id=role_document
face=Arial color=#000000 size=2>
<DIV>
<DIV>In a message dated 4/3/2005 7:06:03 A.M. Mountain Standard Time,
petelomax at blueyonder.co.uk writes:</DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT
style="BACKGROUND-COLOR: transparent" face=Arial color=#000000
size=2><BR>>I think the argument *for* the 'case' statement is to have a
single test determine<BR>>where to jump in the program so you dont have to
wait for 100 elsif's<BR>>to fail before you get to the 101'th elsif.<BR>Any
gain is only possible if you restrict the proposed case statement<BR>to
dealing with a range of n positive integers 1..n, where n must be<BR>known at
compile-time. Otherwise, in terms of performance, a
case<BR><BR></FONT></BLOCKQUOTE></DIV>
<DIV></DIV>
<DIV>Case statements may be prettier than elsif but there really isn't
that much difference in appearance or speed. The process that is both neat and
fast is 'vectored execution'. A variable causes the program to jump to the
proper location without evaluating a string of if/else/then statements or
case/of/endof'/endcase statements. The programer does the evaluating when the
program is written instead of the machine each time the program is
executed.</DIV></FONT></BODY></HTML>
-------------------------------1112546331--
7. Re: "case" or better? (2.6 suggestion mode)
Eglenn4511 wrote:
>
> The process that is both neat and fast is
> 'vectored execution'. A variable causes the program to jump to the proper
> location without evaluating a string of if/else/then statements or
> case/of/endof'/endcase statements. The programer does the evaluating when
> the program is written instead of the machine each time the program is
> executed.
>
Very interesting, please elaborate. I am having trouble understanding how
this would work if a decision had to be made at run-time.
This seems common in Forth:
http://pfe.sourceforge.net/4thtutor/4thl3-3.htm
However, Forth still has if-else.
Regards,
Marc
8. Re: "case" or better? (2.6 suggestion mode)
- Posted by Eglenn4511 at aol.com
Apr 03, 2005
-
Last edited Apr 04, 2005
-------------------------------1112561998
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In a message dated 4/3/2005 11:47:32 A.M. Mountain Standard Time,
guest at RapidEuphoria.com writes:
The programer does the evaluating when
> the program is written instead of the machine each time the program is
> executed.
>
Very interesting, please elaborate. I am having trouble understanding how
this would work if a decision had to be made at run-time.
This seems common in Forth:
http://pfe.sourceforge.net/4thtutor/4thl3-3.htm
However, Forth still has if-else.
Oh my :) I am brand new to Euphoria and have done most of my programming in
Forth. I once wrote a program to help learn Morse code. Originally, I used
an if/elsif sequence as follows
if c = 'e' or 'E' then
dit()
elsif c = 't' or 'T' then
dah()
elsif c = 'i' or 'I' then
di() dah()
... etc
Then I saved a little space and time by converting alpha characters to
uppercase.
This cut the program size and increased its speed a little
Next I decided to try vectored execution. I defined each letter, aa() = di
dah, bb() = da di di dit, ... etc. I then put aa() in position 65, bb() in
position 66, etc in a table. noop was placed in each location for which there
was no Morse code symbol. Sending the letter 'a' became code_table['a']
Finally, I got rid of the "aa() = di dah" etc statements. I converted them
to binary numbers that represented dits and dahs. A dit was a '0' and a dah was
a '1'. 'A' became 110, 'b' was 10001, 'e' was 10, 't' was 11, etc. I worked
out the numbers and stored them in a table. In Euphoria, they would be stored
as a sequence. This reduced the program size and kept the speed. (For the
curious, the numbers were read from right to left. The most significant bit
said that a code symbol was represented. The numbers were shifted left after
each read and when c / 2 = 0 conversion was completed.)
I then learned that the program read text files as easily as it read
keyboard input. I now wrote a program that I could use on Amateur Radio I hated
using a key to send Morse code but could type fairly well. The program sent
perfect code which could never be said about me.
-------------------------------1112561998
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=US-ASCII">
<META content="MSHTML 6.00.2900.2604" name=GENERATOR></HEAD>
<BODY id=role_body style="FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Arial"
bottomMargin=7 leftMargin=7 topMargin=7 rightMargin=7><FONT id=role_document
face=Arial color=#000000 size=2>
<DIV>
<DIV>In a message dated 4/3/2005 11:47:32 A.M. Mountain Standard Time,
guest at RapidEuphoria.com writes:</DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT
style="BACKGROUND-COLOR: transparent" face=Arial color=#000000 size=2>The
programer does the evaluating when <BR>> the program is written
instead of the machine each time the program is<BR>> executed.<BR>>
<BR><BR>Very interesting, please elaborate. I am having trouble understanding
how<BR>this would work if a decision had to be made at run-time.<BR><BR>This
seems common in
Forth:<BR><BR>http://pfe.sourceforge.net/4thtutor/4thl3-3.htm<BR><BR>However,
Forth still has if-else.<BR></FONT></BLOCKQUOTE></DIV>
<DIV></DIV>
<DIV>Oh my :) I am brand new to Euphoria and have done most of my
programming in Forth. I once wrote a program to help learn Morse code.
Originally, I used an if/elsif sequence as follows </DIV>
<DIV>if c = 'e' or 'E' then</DIV>
<DIV> dit()</DIV>
<DIV>elsif c = 't' or 'T' then</DIV>
<DIV> dah()</DIV>
<DIV>elsif c = 'i' or 'I' then</DIV>
<DIV> di() dah()</DIV>
<DIV>... etc</DIV>
<DIV> </DIV>
<DIV>Then I saved a little space and time by converting alpha characters to
uppercase.</DIV>
<DIV>This cut the program size and increased its speed a little</DIV>
<DIV> </DIV>
<DIV>Next I decided to try vectored execution. I defined each letter, aa() = di
dah, bb() = da di di dit, ... etc. I then put aa() in position 65, bb() in
position 66, etc in a table. noop was placed in each location for which there
was no Morse code symbol. Sending the letter 'a' became code_table['a']</DIV>
<DIV> </DIV>
<DIV>Finally, I got rid of the "aa() = di dah" etc statements. I converted them
to binary numbers that represented dits and dahs. A dit was a '0' and a dah was
a '1'. 'A' became 110, 'b' was 10001, 'e' was 10, 't' was 11, etc. I worked out
the numbers and stored them in a table. In Euphoria, they would be stored as a
sequence. This reduced the program size and kept the speed. (For the curious,
the numbers were read from right to left. The most significant bit said that
a code symbol was represented. The numbers were shifted left after each
read and when c / 2 = 0 conversion was completed.)</DIV>
<DIV> </DIV>
<DIV>I then learned that the program read text files as easily as it read
keyboard input. I now wrote a program that I could use on Amateur Radio I hated
using a key to send Morse code but could type fairly well. The program sent
perfect code which could never be said about me.</DIV></FONT></BODY></HTML>
-------------------------------1112561998--
9. Re: "case" or better? (2.6 suggestion mode)
- Posted by Bernie Ryan <xotron at bluefrog.com>
Apr 03, 2005
-
Last edited Apr 04, 2005
> -------------------------------1112561998
> Content-Type: text/html; charset="US-ASCII"
> Content-Transfer-Encoding: 8bit
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD>
> <META http-equiv=Content-Type content="text/html; charset=US-ASCII">
> <META content="MSHTML 6.00.2900.2604" name=GENERATOR></HEAD>
> <BODY id=role_body style="FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Arial"
>
> bottomMargin=7 leftMargin=7 topMargin=7 rightMargin=7><FONT id=role_document
> face=Arial color=#000000 size=2>
> <DIV>
> <DIV>In a message dated 4/3/2005 11:47:32 A.M. Mountain Standard Time,
> guest at RapidEuphoria.com writes:</DIV>
> <BLOCKQUOTE
> style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT
>
> style="BACKGROUND-COLOR: transparent" face=Arial color=#000000 size=2>The
> programer does the evaluating when <BR>> the program is written
> instead of the machine each time the program is<BR>> executed.<BR>>
> <BR><BR>Very interesting, please elaborate. I am having trouble
> understanding
> how<BR>this would work if a decision had to be made at run-time.<BR><BR>This
>
> seems common in
> Forth:<BR><BR><a
> href="http://pfe.sourceforge.net/4thtutor/4thl3-3.htm">http://pfe.sourceforge.net/4thtutor/4thl3-3.htm</a><BR><BR>However,
>
> Forth still has if-else.<BR></FONT></BLOCKQUOTE></DIV>
> <DIV></DIV>
> <DIV>Oh my :) I am brand new to Euphoria and have done most of my
> programming in Forth. I once wrote a program to help learn Morse code.
> Originally, I used an if/elsif sequence as follows </DIV>
> <DIV>if c = 'e' or 'E' then</DIV>
> <DIV> dit()</DIV>
> <DIV>elsif c = 't' or 'T' then</DIV>
> <DIV> dah()</DIV>
> <DIV>elsif c = 'i' or 'I' then</DIV>
> <DIV> di() dah()</DIV>
> <DIV>... etc</DIV>
> <DIV> </DIV>
> <DIV>Then I saved a little space and time by converting alpha characters to
> uppercase.</DIV>
> <DIV>This cut the program size and increased its speed a little</DIV>
> <DIV> </DIV>
> <DIV>Next I decided to try vectored execution. I defined each letter, aa() =
> di
> dah, bb() = da di di dit, ... etc. I then put aa() in position 65, bb() in
> position 66, etc in a table. noop was placed in each location for which there
> was no Morse code symbol. Sending the letter 'a' became code_table['a']</DIV>
> <DIV> </DIV>
> <DIV>Finally, I got rid of the "aa() = di dah" etc statements. I converted
> them
> to binary numbers that represented dits and dahs. A dit was a '0' and a dah
> was
> a '1'. 'A' became 110, 'b' was 10001, 'e' was 10, 't' was 11, etc. I worked
> out
> the numbers and stored them in a table. In Euphoria, they would be stored as a
>
> sequence. This reduced the program size and kept the speed. (For the curious,
> the numbers were read from right to left. The most significant bit said that
> a code symbol was represented. The numbers were shifted left after each
> read and when c / 2 = 0 conversion was completed.)</DIV>
> <DIV> </DIV>
> <DIV>I then learned that the program read text files as easily as it read
> keyboard input. I now wrote a program that I could use on Amateur Radio I
> hated
> using a key to send Morse code but could type fairly well. The program sent
> perfect code which could never be said about me.</DIV></FONT></BODY></HTML>
>
Please POST TEXT ONLY on EUforum !!!
Bernie
My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.ew
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
10. Re: "case" or better? (2.6 suggestion mode)
- Posted by Eglenn4511 at aol.com
Apr 04, 2005
-------------------------------1112581633
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In a message dated 4/3/2005 5:18:52 P.M. Mountain Standard Time,
guest at RapidEuphoria.com writes:
Please POST TEXT ONLY on EUforum !!!
Was this statement directed to me?
-------------------------------1112581633
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=US-ASCII">
<META content="MSHTML 6.00.2900.2604" name=GENERATOR></HEAD>
<BODY id=role_body style="FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Arial"
bottomMargin=7 leftMargin=7 topMargin=7 rightMargin=7><FONT id=role_document
face=Arial color=#000000 size=2>
<DIV>
<DIV>In a message dated 4/3/2005 5:18:52 P.M. Mountain Standard Time,
guest at RapidEuphoria.com writes:</DIV>
<BLOCKQUOTE
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: blue 2px solid"><FONT
style="BACKGROUND-COLOR: transparent" face=Arial color=#000000
size=2><BR>Please POST TEXT ONLY on EUforum
!!!<BR><BR></FONT></BLOCKQUOTE></DIV>
<DIV></DIV>
<DIV>Was this statement directed to me?</DIV>
<DIV> </DIV></FONT></BODY></HTML>
-------------------------------1112581633--
11. Re: "case" or better? (2.6 suggestion mode)
> Was this statement directed to me?
Considering this message was in HTML too, I'd assume so.
~Greg
12. Re: "case" or better? (2.6 suggestion mode)
>
> > Was this statement directed to me?
>
> Considering this message was in HTML too, I'd assume so.
>
> ~Greg
>
It's possible Eglenn4511 at aol.com doesn't *realize* that his/her posts are
being sent by aol in HTML.
Dan Moyer
13. Re: "case" or better? (2.6 suggestion mode)
Eglenn4511 wrote:
> In a message dated 4/3/2005 5:18:52 P.M. Mountain Standard Time,
> guest at RapidEuphoria.com writes:
>
>
> Please POST TEXT ONLY on EUforum !!!
>
>
> Was this statement directed to me?
I think so. Here is some additional information:
http://www.efn.no/html-bad.html
Also, please quote correctly, so that it becomes clear who wrote what:
http://www.netmeister.org/news/learn2quote.html
To Rob:
I think it would be helpful if Listfilter automatically checks whether
a mail contains HTML, and send the author an appropriate private message
if required.
Regards,
Juergen
