1. Case Construct
Is it too late to ask if Eu4.0 could be designed to implement a case-endcase
construct to replace the succession of if-else-endif's we use currently? I
would like to have that available, but regret that I'm not capable of coding
it myself. Is anyone else interested in this?
Cheers
Alex Caracatsanis
2. Re: Case Construct
I'm surprised no one has answered this.
Perhaps everyone here has been using Eu so long, they
no longer remember how useful such a construct can be.
3. Re: Case Construct
irv mullins wrote:
>
>
> I'm surprised no one has answered this.
> Perhaps everyone here has been using Eu so long, they
> no longer remember how useful such a construct can be.
Hm, I do program in C as well. A case construct is very handy. I just don't know
the backend of the interpreter enough to implement such a construct.
Anyone else who knows the interpreter internals better? Is this is a huge change
or a debated change?
--
Jeremy Cowgar
http://jeremy.cowgar.com
4. Re: Case Construct
irv mullins wrote:
>
>
> I'm surprised no one has answered this.
> Perhaps everyone here has been using Eu so long, they
> no longer remember how useful such a construct can be.
I asked for case too. I implemented it in mirc with goto. You can do it in ooeu
with goto. This is prolly why it isn't in Eu. Good luck.
Kat
5. Re: Case Construct
Jeremy Cowgar wrote:
>
> irv mullins wrote:
> >
> >
> > I'm surprised no one has answered this.
> > Perhaps everyone here has been using Eu so long, they
> > no longer remember how useful such a construct can be.
>
> Hm, I do program in C as well. A case construct is very handy. I just don't
> know the backend of the interpreter enough to implement such a construct.
>
> Anyone else who knows the interpreter internals better? Is this is a huge
> change
> or a debated change?
I think it could probably be implemented in the front end only, using existing
IL codes. It might be more efficient, however, to introduce new IL...
Matt
6. Re: Case Construct
irv mullins wrote:
>
>
> I'm surprised no one has answered this.
> Perhaps everyone here has been using Eu so long, they
> no longer remember how useful such a construct can be.
Forgive me for asking, but what benefit does case offer over elsif other than
saving a handful of keystrokes?
7. Re: Case Construct
Michael J. Sabal wrote:
>
> irv mullins wrote:
> >
> >
> > I'm surprised no one has answered this.
> > Perhaps everyone here has been using Eu so long, they
> > no longer remember how useful such a construct can be.
>
> Forgive me for asking, but what benefit does case offer over elsif other than
> saving a handful of keystrokes?
MUCH clearer code (and probably faster when it is implemented correctly)
8. Re: Case Construct
- Posted by Matt Lewis <matthewwalkerlewis at ?mail.c?m>
May 10, 2008
-
Last edited May 11, 2008
Michael J. Sabal wrote:
>
> Forgive me for asking, but what benefit does case offer over elsif other than
> saving a handful of keystrokes?
A C-style case statement also offers fall through:
switch foo do
case bar:
-- do stuff
exit
case special_baz
-- do stuff, then continue with normal baz
case baz
-- do baz stuff
exit
default
-- do stuff
end switch
Matt
9. Re: Case Construct
- Posted by CChris <christian.cuvier at ag?iculture.g?uv.fr>
May 10, 2008
-
Last edited May 11, 2008
Matt Lewis wrote:
>
> Michael J. Sabal wrote:
> >
> > Forgive me for asking, but what benefit does case offer over elsif other
> > than
> > saving a handful of keystrokes?
>
> A C-style case statement also offers fall through:
> }}}
<eucode>
> switch foo do
> case bar:
> -- do stuff
> exit
> case special_baz
> -- do stuff, then continue with normal baz
>
> case baz
> -- do baz stuff
> exit
>
> default
> -- do stuff
> end switch
> </eucode>
{{{
> Matt
Right. And, if e want, we can get it to process ranges, like in:
select(some_expr())
case -1,2: do_this() exit
case 3 thru 6: do_preparations()
default: the_real_stuff()
end select
I think that all it saves, apart from the keystrokes, is parsing the various
elsif statements.
It can be implemented in the front end, but as usual without much of a
performance gain.
It was argued that a select statement winds up coded as a REP SCASB to get the
branch address position in a table, then a JMP dword [EDI+some_offset].
Problem is that predicting these branches is difficult for the CPU, cache misses
will be the rule, and they are more and more expensive as the pipeline of Intel
CPUs lengthens. If correct (which I didn't assess by direct testing), then the
select statement would have been useful with say the early Pentiums, but less so
now.
This said, I would vote for it if it can be implemented more efficiently. It
makes code clearer, and the fall through is sometimes useful.
CChris
10. Re: Case Construct
I've been thinking about branching syntax...
if (expression) then
some_code
else
other_code
end if
if (expr)
case 1
some_code
case 2
other_code
else
more_code
end if
if_any (expr)
case 1, 25
some_code
exit
case > 10
other_code
case < 5
code_in_addition_to_other_code
else
code_if_none_of_the_above
end if
THEN and CASE after the expression distinguishes the two.
if_any allows fall through because sometimes that is useful.
Muliple cases on a single line is also very useful; Would it be
confusing to have a sequence represent the multiple cases? Probably
a comma delimited list would be better.
