Re: FOR i ...
Pete Lomax wrote:
>
> CChris wrote:
> >
> > Pete Lomax wrote:
> > > obviously changes are needed in the scanner no matter what <res-word> is
> >
> > Actually, the parser expects a variable name and an equal sign, so it has to
> > be modified for your syntax to work. It is a workable solution.
>
> <slaps head> Yes, I meant to say parser not scanner there.
>
>
> > }}}
<eucode>
> > type hour(integer n)
> > return n>=0 and n<=23
> > end type
> > hour n
> > for hour n=0 to 23 do big_ben_chime() end for
> > </eucode>
{{{
> > This should be legal, shouldn't it?
>
> Not really seeing any point to this. It would be at least 8 times slower than
> a non-type-checked loop [I just ran a quick test to prove this], and what you
> probably should be doing for type checking is eg calling:
> }}}
<eucode>
> procedure big_ben_chime(hour h)
> </eucode>
{{{
>
> > This is why I'd prefer either the "with" version Derek proposed, or a new
> > keyword
> > like iterate, rather.
> I don't see how as that makes the slightest bit of difference. Is a "for with
> h" or an "iterate h" going to type-check or not, or somehow type-check at zero
> cost? What I don't understand here is just how or why changing the keyword or
> introducing another confusing construct is going to magically change anything
> at all, please explain.
>
1/ There is no logical reason why the type of the loop variable should appear in
the syntax at all. Adding the type marker does add something, namely confusion.
2/ Don't forget adding }}}
<eucode>without type_check</eucode>
{{{
at the start of the
test code, and the penalty will go away.
3/ Since the loop variable exists outside the loop, it may have uses outside the
loop which require it to be of some udt - for instance, because a routine needs
to typecheck its arguments, which is done whether you run with or without
typecheck. Preventing it from being an udt by issuing a compile error would be a
quirky, useless restriction.
> Of course my "for integer i=1" does not magically change things either, just
> reads better than "for with i=1" imo, giving a better sense that "integer i"
> already exists. I suppose if the consensus is that "for hour n=1" should be
> supported and is shorthand for:
> }}}
<eucode>
> for ??=1 to ...
> n=?? (ie opASSIGN, opPROC, & opTYPE_CHECK)
> </eucode>
{{{
> Then fair do's, no skin off my nose, but sounds not good to me.
>
"for_existing" is a clearer statement of intent than "iterate" or "for with", so
I'd suggest that one rather. There is a risk of breaking code which defines a
variable named "for_existing", but the risk is probably pretty slim. Did anyone
experience any problem because "find_from" is no longer available as a valid
identifier?
As a side note, I think the scanner can be made smarter (with decisive help from
next_token()) so as to be able to tell, when encountering a redefined keyword,
whether it is a keyword or a variable. There is a decision rule for this, based
on the nature of the previous and next token. This will make extending Eu
definitely easier by reducing - hopefully to zero, but further checks are neeeded
- the problems caused by a non keyword litteral suddenly becoming a keyword. By
maintaining a separate lookahead buffer, the loss of performance will be nil -
Scanner() will elaborate the next token and return the one it had figured out
earlier, rather than processing and returning the current token.
> > by setting them to NOVALUE on exiting the loop
> I one day hope to be able to examine a for loop var after the end for, hence
> I strongly disagree with that.
>
I am not sure this makes sense at all, though I see what you want to do.
Examining a for_existing loop var after the end for_existing would completely
make sense and be possible, since it is a regular variable.
Currently you have to use a specific variable anyway; it will no longer be
needed.
> Regards,
> Pete
CChris
|
Not Categorized, Please Help
|
|
