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

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

[Jean-Claude Wippler]

Below is a brief email exchange about a Tcl parser written in C++,
forwarded to this list as suggested by Mo DeJong.  Please don't expect
any response from me for the next month or so - I'm about drop off the
internet for a while...

You can use the code in any nice way you like, it's open source.

Regards,
Jean-Claude


---------------- Begin Forwarded Message ----------------
Subject: Re: Source Navigator (was: Content of the Perl6 talk)
Date Sent: Saturday, July 29, 2000 14:10
From: Mo DeJong <mdejong@cygnus.com>
To: Jean-Claude Wippler <jcw@equi4.com>

On Sat, 29 Jul 2000, Jean-Claude Wippler wrote:

> Hello Mo,
> 
> [...]
> > Hey, that reminds me. If anyone would like to help improve the
> > Tcl language parser in Source-Navigator, we would really like to
> > hear from you on the SN mailing list. Some folks have already
> > started working on a Perl and Python parser. Source-Navigator
> > already has a Tcl parser, but it is not that great. What we
> > really need is for someone to write a front end to the regular
> > Tcl parser that writes out Source-Navigator symbols. It would
> > not be that large a project, we already have most of the parser
> > utils in place.

That sounds cool. It might be nice to use a mini parser. We don't
really care about a Tcl runtime, we just need to find out where
methods are invoked and so on.
 
> There's a Tcl parser in TinyTcl, http://mini.net/pub/ts1/tinytcl.txt

Cool, I really like how to Jacl parser turned out. I think it is
much cleaner than the C version.

> It's written in C++, you may recognize it - I learned a lot from how you 
> did things in Jacl.
>
> There is also a standalone version, as part of another experiment:
>    http://www.equi4.com/jcw/tools/pink/wtcl.cpp

We are going to be in the GnuPro release process
for the next couple of months, so we are not going
to be able to improve Tcl support in SN. This is one
of those areas that "community involvement" is
needed.
 
> 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.

[...]

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

[Ben Elliston]

   > 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.

Ben

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

[Mo DeJong]

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.
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.

Mo DeJong
Red Hat Inc

Re: 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