Re: modified interpreter
Kat wrote:
>
> On 29 Jun 2005, at 3:40, Matt Lewis wrote:
>
> > posted by: Matt Lewis
> >
> > Kat wrote:
> > >
> > }}}
<eucode>
> > :some_label
> > puts(1, "Some label\n" )
> >
> > :another_label
> > puts(1, "Another label\n" )
> >
> > g = "some_label"
> > goto g -- same as goto "some_label"
> > </eucode>
{{{
</font>
>
> That's a good example, yes. Not good coding style, but a good goto example
> for what i meant.
> > I think that if I were implementing this, I'd make the argument for goto
> > be some sort of value (i.e., not a label bareword).
>
> You mean not a string variable label? Ouch, i was going to use almost
> exclusively strings!
>
> > I'm not sure what
> > 'goto 5 + variable' means, though.
>
> }}}
<eucode>
> integer x
> x = 12
>
> puts(1,sprintf("%d",x)&"\n")
>
> -- goto x
> goto x + 3
>
> :1
> :2
> puts(1,sprintf("%d",x)&"\n") goto end
> :3
> :12
> puts(1,sprintf("%d",x)&"\n") goto end
> :15
> puts(1,sprintf("%d",x)&"\n") goto end
> :end
> </eucode>
{{{
</font>
>
> prints:
> 15
>
> Yes, another good example of rather bad coding AND the "evaluated goto" i
> meant. The interesting part is, if the label isn't there, there's no error and
> it
> doesn't go anywhere. And if there's labels and no goto to call them, that's ok
>
> too! Makes a nice case (or switch) statement.
OK. So a label is really an object. I think that could work. It's maybe
possible to allow barewords, but then I don't think I should allow you
to pass a variable. Doing both sounds like a recipe for trouble. So to
goto a label, you could use:
goto "lable1"
goto "lable" & sprint(x)
:label1
>
> I really believe this is a good idea also:
>
> }}}
<eucode>
> function(sequence example)
> --code
> for loop = 1 to whatever do
> -- code
> while blah do
> -- code
> if zortched then goto end end if
> -- code
> end while -- blah
> -- code
> end for -- whatever
> return blarg
> :end
> -- special zortched code
> end function
> <font color="#330033"></eucode>
{{{
</font>
>
> The reason is it gets terribly non-normal exceptions out of the normal
> program flow as it's read, plus it's faster and cleaner than flag vars being
> constantly tested for "break"ing and "exit"ing or "continue"ing. It provides
> for
> a consistant block of zortch-handling code inside the function.
>
> Naturally, any jump out of any loop, in any direction, resets the loop vars.
I don't think this is a problem. In Eu, the loop vars get set inside the
loop, and you can ignore them otherwise, so it's just a jump.
No promises on time lines, though. :)
Matt Lewis
|
Not Categorized, Please Help
|
|