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

[Michael R H. <bu...@zc...>]

On Mon, 2003-12-29 at 08:08, Ken Anderson wrote: 
> 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've used Eclipse for so long, it's hard for me to realize what's
obvious and non-obvious. Thanks for taking the role of the
eclipse-beginner for me ;-)

I'm a little unfamiliar with the update manager. Currently, the update
manager is a bit tricky to use, IMHO. Plus, since I always set up a
shared installation of Eclipse, it's not so useful to me, so I don't use
it. However, I do know that you need to add various bookmarks to URLs
(like http://zclipse.org/updates) to the "Sites to Visit" region. Then
you should see available updates in that same view.


So first of all, I've only tested the JScheme plugin with Eclipse 2.1
(through 2.1.2), so if you got one of the 3.0 milestones, it might be
issueful. If you're using 2.1.2, then the contents of
org.zclipse.jscheme_0.1.6.zip should be extracted to the plugins
directory inside eclipse's home directory (so
eclipse/plugins/org.zclipse.jscheme_0.1.6/plugin.xml should exist). Once
that's there, then you should restart eclipse and everything _should_
work.

I assume you got that far since you said below that you have the
hilighting working.

Since the "running man" icon isn't there, I'm betting you're not in the
Java perspective. I'm always in that perspective. Anyway, there are two
ways to make the running man icon appear: one is to simply switch to the
Java Perspective (Window/Open Perspective/Java); the other is to
customize the current perspective to show it (Window/Customize
Perspective, drill down through "Other" and check off "Launch").

I think I will be adding a feature to auto-jump to the new JScheme
perspective, thereby adding the laucnh buttons, when a .scm file is
created or opened, if it turns out not to be too hard.

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

My needs for the plugin called for running each JScheme program in a
separate JVM. I don't think it would be too hard add a button that just
launched REPL into the console for user interaction. 

In fact, you, as a user can do this rather simply by creating an (empty)
.scm file, and running it with the launcher. After launching the empty
.scm file, Eclipse should raise the console view and display the
familiar line "Jscheme 6.1.1 5/5/2003 http://jscheme.sourceforge.net"
followed by the angle prompt. Keyboard input in that view will be sent
to System.in of REPL. 

It might not be hard to add a button that would send the current file to
System.in of the REPL process, but it's not one of my 1.0 critical
features, and it could possibly be a bit hairy to implement if some
obvious API isn't there or doesn't work the way I expect. I'll add that
to my future TODO, though.

Launching REPL from withing Eclipse's own Java process would be a bit
trickier, since I don't know where System.in or System.out would be.

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

Good idea. I might see about doing that on my flight back to Boston
tomorrow night. I really ought to have a reasonable way to have the
plugin run JScheme programs on the source files.

I hadn't thought to look for such a thing, since I figured a code
formatter/pretty printer would be a good way to exercise the syntax
tree. but exercising a JScheme callout feature might be a better and
easier short term goal.

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

> 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

Cool. I've used SableCC in the past and really like the parsers it
generates compared to JLex+JavaCUP and JavaCC (they're very OO and
present a very traversable syntax tree). I've found that hand-coded
parsers to be a bit harder to manipulate, but I will definitely check
out the links you provided.

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

That's certainly not a bad metric for success ;-)

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

Yeah, doing it right in JScheme might be the easiest way. My only
concern is that I want to be able to recover from unbalanced parentheses
as gracefully as I can, which seems easier if I can write code that
interacts with the parser. 

I have been considering about extending my plugin with JScheme, but
haven't been quite prepared to think about the details of that quite
yet, as I'm still trying to figure out which Eclipse hooks need to be
used to do everything I need, and adding a language barrier at this
point would complicate things (for me, anyway).

As far as downcasting goes, my concern is not the actual downcast
itself, but the ability to use static typing as much as possible. The
point of the visitor pattern, for me, is to ensure that the compiler
spits errors when the AST changes. My language preference is for strong-
and static- typing, hence why I wanted to do the Eclipse plugin in the
first place -- I'm mostly a Java developer that from time to time hacks
on some JScheme apps, but there's no need to start a religious war: my
most important directive here is to find the quick-but-not-dirty
solutions, if that happens to mean implementing things on the JScheme
side, then I'm all for it ;-) 

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

That would be cool. From my point of view, if it could spit back a
Java-based AST (with line and column numbers, comments, ...), then it
would be perfect, but as long as all the data is available, I could also
easily work with JScheme, too -- since that's clearly a very natural way
to work with trees of lists.

Let me know what I can do to help,

mike

-- 
Michael R Head <bu...@zc...>
ZClipse -- OpenSource Eclipse plugins