Prev: clock format does not run in window service
Next: Tcl/Tk 8.5.3 RELEASED
From: Fredderic on 30 Jun 2008 12:16
On Fri, 13 Jun 2008 16:24:16 -0700 (PDT),
Alexandre Ferrieux <alexandre.ferrieux(a)gmail.com> wrote:

> In fact, as I said, it could be both an interpreter *and* compiler
> hook, since both use the same parser. The reason I mentioned [proc]
> is that it gives a natural boundary for the enabling/disabling of the
> hook. But toplevel code, callbacks, etc. could also benefit from it
> through a global setting like

So if [(...)] is made to compile as [expr {...}], what happens when
your do: after 1000 {puts stdout [($n+3)]}


Hmmm..... This looks like a nice juicy idea... ;)

> [interp preprocessor handler]

I suspect that invoking [handler] for every single command over a couple
thousand lines of script would be atrocious on load time performance.
But having it proc-local is going to cause all manner of problems such
as the one mentioned above. But, how about this:

interp preprocessor = handler

being a parse-time version of [interp alias] (where "=" is checked
against the whole first word of a statement at parse-time) with
remaining words passed as arguments, and the return value re-parsed...

The overhead in the parser would be identical to your simple case
where no handler is defined. But in the case where a handler is
defined, it eliminates the need for the handler to test itself which of
potentially several directives are being used.


For those set on really bending things, allow a single * to be present
within the token, and put it in a list that gets checked per-word:

interp preprocessor ((*)) handler

would cause the preprocessor to look for a word starting with "((",
then search (using the rules for {...} matching) for the terminating
"))", finaly invoking [handler] to filter the enclosed text prior to
further parsing. It shouldn't be too difficult to perform a binary
longest-first search to match the start of a word, which would be a
massive amount faster than any way [handler] might choose to do it
(and THEN extract the text to be processed). And if you DO need to
accept some freaky forms, then there's always the simple pattern *
which will be invoked (albeit rather painfully) for every word.


In either case, [handler] should be able to return TCL_CONTINUE to tell
the parser to keep looking for a match because this handler doesn't
want it (most notably where a shorter token is also present), and
perhaps also TCL_BREAK to tell the parser it's one of ours, but we
don't want to modify it (avoiding the need for any re-parsing), and it
should just continue on as it was.


Fredderic
From: Adrian Davis on 1 Jul 2008 08:25
> They said it's definitely [expr]. They hate to repeat [expr] everytime when
> they need to do some math.
> I must agree with them - it's pretty nasty.
> Since there is "{*}" for lists expanding, there can be also some nice syntax
> to do math, right? Like for example:
>
> set sum ($a + $b)
> set word [lindex $list ($index + 5)]
>
> Wouldn't it be great? I think it would.

How about parsing so that that...

[{$a + $b}]

....is equivalent to...

[expr {$a + $b}]

In effect "[{" is taken to be "[expr {" where the following characters
are not "*}". I've done some searches through random (but long)
examples of Tcl code and haven't found anything (yet) that would
break.

Best Regards,
=Adrian=



From: miguel on 1 Jul 2008 08:38
Adrian Davis wrote:
> How about parsing so that that...
>
> [{$a + $b}]
>
> ...is equivalent to...
>
> [expr {$a + $b}]
>
> In effect "[{" is taken to be "[expr {" where the following characters
> are not "*}". I've done some searches through random (but long)
> examples of Tcl code and haven't found anything (yet) that would
> break.

% proc {$a + $b} {} {return FOO!}
% puts [{$a + $b}]
FOO!

Note that there may be quite a bit of code out there that may generate command
names from runtime data. Maybe some parsers and suchlike thingies?
From: Adrian Davis on 1 Jul 2008 09:58
> % proc {$a + $b} {} {return FOO!}
> % puts [{$a + $b}]
> FOO!
>
> Note that there may be quite a bit of code out there that may generate command
> names from runtime data. Maybe some parsers and suchlike thingies?

What I'm proposing won't see a proc called "{$a + $b}". I'm suggesting
that the Tcl parser(?) be modified so that, in effect, it substitues
"[{" with "[expr {" , or at least treats one as if it were the other.

Best Regards,
=Adrian=

From: miguel on 1 Jul 2008 10:14
Adrian Davis wrote:
>> % proc {$a + $b} {} {return FOO!}
>> % puts [{$a + $b}]
>> FOO!
>>
>> Note that there may be quite a bit of code out there that may generate command
>> names from runtime data. Maybe some parsers and suchlike thingies?
>
> What I'm proposing won't see a proc called "{$a + $b}". I'm suggesting
> that the Tcl parser(?) be modified so that, in effect, it substitues
> "[{" with "[expr {" , or at least treats one as if it were the other.

Right ... so you break my script above! Specifically

set a 1
set b 2
proc {$a + $b} {} {return FOO!}
puts [{$a + $b}]

currently prints 'FOO!'; with your proposal it would print '3' instead.

Note that is is not "it can't be done at all", it is rather "it may not be so
easy to determine what scripts might break". Again, thinking of dynamically
generated scripts (rather than weirdos like my example).
 |  Next  |  Last
Pages: 1 2 3 4 5 6 7
Prev: clock format does not run in window service
Next: Tcl/Tk 8.5.3 RELEASED