Fwd: Re: Source Navigator (was: Content of the Perl6 talk)

[Syd Polk]

Mo DeJong wrote:
> 
> On Mon, 31 Jul 2000, Ben Elliston wrote:
> 
> >    > The coming month is sort of crazy, unfortunately.  In September, I'll be
> >    > revisiting this stuff - to make it more general.  If there's an easy way
> >    > to make this code useful for SN, I'd be happy to do so.
> >
> >    Could you post a note about this on sourcenav@sources.redhat.com? That
> >    way, other folks will know about your code and plans, there is already
> >    one other guys talking about fixing the Tcl parser.
> >
> > Would it make sense to try and make use of the parser in Tcl?  Are there
> > public Tcl library functions to get access to the parser--perhaps
> > registering semantic actions?  This way, Tcl support would never lag behind
> > Tcl itself.
> 
> That is what I was thinking. The thing about Jean-Claude's approach
> is that it is the Tcl parser, it is just an embedded verison. The
> Tcl is frozen. There really have not been any parser changes for a
> long time, so that is not much of a concern. It is really hard to
> get ANY parser change into Tcl, I am currently trying to get the
> Tcl folk to agree that "set i []" should set the variable i to
> the liternal string "[]" instead of the empty string.

But that is just wrong. If you want to set i to "[]", you should do 

set i {[]}

or something.

> The hard part is not the parser, it is the "rules"
> you would need to add after the parsing to really make
> things useful.
> 
> For instance:
> eval foo $args
> 
> This should be recorded as a call to the proc foo, not a call
> to eval. You need to ignore that fact that users could create
> a new method call eval and just do what 99% of the folks
> would expect. Of course, you could also argue that this should
> be a call to eval and a call to foo.

Tcl is hard this way. It should be recorded as both a call to eval and foo just
in case I am trying to find an eval that is causing problems.
 
> Mo DeJong
> Red Hat Inc