Re: [Jscheme-user] (J)Scheme parsing with (or without?) jsint.InputPort

[Ken A. <kan...@bb...>]

Thanks for your work on JScheme in Eclipse!

I have downloaded your plugin, and put it in the eclispe plugin directory.  Is that all i need to do?  I such a beginner.  I can't seem to get the update manager to show me new plugins i can download.  Is there a way to do that, or do i just find them in at the plugin website and install them myself?

I seem to have JScheme hilighting, but i can't find the runas jscheme application.  How do i get to it?

How hard would it be to run JScheme inside Eclipse, like i do in EMACS?

At 12:30 PM 12/28/2003 -0900, Michael R Head wrote:
>I've been spending some time with my JScheme plugin for Eclipse again (I
>just added matching parenthesis highlighting to the version in CVS), and
>I've come to a point at which I have to really parse the input buffer to
>add the next features on my TODO:
>http://cvs.zclipse.org/viewcvs.py/zclipse/org.zclipse.jscheme/TODO?view=markup

One of the things on your todo list is a code formatter.  Why don't you use the pretty printer, src/elf/eopl2/jscheme/genwrite.scm


>For details on the plugin: http://www.zclipse.org/projects/jscheme
>
>I've toyed with rolling my own parser (which I've started twice: once
>ad-hoc, and once from the r4rs spec), writing a SableCC grammar for

Yes, i've tried it from the spec too.  

>JScheme, and using the jsint.InputPort.read() function.
>
>None of these has struck me as quite perfect. 
>
>Rolling my own gives me the most control over error reporting and
>recovery, and I would have full access to all parts of the input
>(including comments), but it's a lot of work that has already been done
>in JScheme itself, and it would likely be less sharable with other
>projects that might have similar needs.
>
>Writing a SableCC grammar is less work, more sharable in some ways
>(possibly directly contributable to the jscheme project itself), and
>generates a very pleasant AST for traversal, but isn't so good at error
>reporting or recovery during the parse (at least in the current release
>of SableCC).

Personally, i void tools like this because it takes a long time for me to learn how to use them.  Instead i use a simpler technique i can remember.  I first got the idea from Henry Baker: http://citeseer.nj.nec.com/cache/papers/cs/24786/http:zSzzSzlinux.rice.eduzSz~rahulzSzhbakerzSzPrag-Parse.pdf/baker91pragmatic.pdf

I now tend to use a functional state machine style.  See the read-case macro in
http://openmap.bbn.com/~kanderso/lisp/performing-lisp/pl-io.ps

I wrote a corba idl tokenizer in this style in 274 lines while Sun's input to lex was 353.

>Using InputPort.read() is great because I would be using precisely the
>same parsing mechanism as JScheme itself, and it's already been written.
>However, to my mind, API isn't quite amenable for general use. Since it
>returns Object, I have to use Java's RTTI features to examine and
>process the parsed data (or I have to write parts of my code in JScheme
>to process the input) -- I'd prefer a syntax tree that I implements the
>Visitor design pattern for traversal so I don't have to do any
>downcasting. My understanding is also that because it's meant for

I don't see why JScheme isn't perfect for this.  You don't need downcasts or the visitor pattern. http://norvig.com/design-patterns/ shows that in Lisp many patterns are unnecessary or trivial.

>execution, the InputPort throws away comments and will print errors to
>System.err. Basically, in my understanding, it's not meant to be a Java 
>API for parsing JScheme. 

Right, (read) just returns an object, and skips comments.

>It might not be too bad to cause the InputPort.read() to return an AST,
>instead of Object, possibly adding comments to the syntax tree. It would
>probably be harder to push error handling into the API level.
>
>Does anyone have any other recommendations for this? Once I have an AST
>that I can work with, it should be easy to add a TreeView of the source
>and a source formatter, the two major remaining features I want before I
>release 1.0.0 of the plugin.

I've been thinking that InputPort has grown to be a fairly big mess.  I've been thinking about rewriting it in a (read-case) like macro in JScheme that expands to Java code.  If you'd like to work on that with me, we can add stuff to better support Eclipse.  Keeping track of file and line numbers would even help in reporting JScheme errors.