Re: [Schemeway-devel] proposal

[<sch...@sy...>]

Rahul,

>1. The main objective of the fork is to provide an environment for
>Kawa Scheme development. I propose to drop support for all other
>interpreters for the reason that it will make my life simpler.

I have a different proposition: make SchemeScript more generic, with 
extension points for various features, and add support for specific dialects 
as separate plugins, all under the umbrella of the SchemeWay project. That 
was the initial goal.I simply never had time to clean all the interfaces.

The SchemeWay project (and the SchemeScript plugin in particular) now has a 
certain visibility. SchemeScript is clearly the defacto standard plugin for 
Scheme programming in Eclipse. It would be unfortunate to fragment our 
community.

>2. Incremental changes to SchemeScript:
>a) A better outline view supporting proper view of classes with fields
>inside classes

The outline view in the CVS version supports exactly that, as well as 
internal defines, macros, etc.

>b) A better REPL with paren matching and history

All Scheme systems would benefit from that, not only Kawa. But this is a 
major undertaking. Maybe a better interface than the console window would be 
interesting. Have you ever tried the Factor language/environment? This could 
be a great source of inspiration.

>3. Infrastructure changes :
>a) Shift to newer Kawa versions : some investigation suggests
>load-relative is broken in Kawa 1.9.1 Until that is fixed I wont be
>able to investigate further.

I'm not opposed to that, on the contrary.

>b) Shift to DLTK?

What will this add to SchemeScript in terms of functionality? I don't know 
yet, so I can't comment. If more features can be implemented without loosing 
anything, then great.

>4. Kawa specific extensions:
>a) A Kawa project view : Kawa Scheme projects with Kawa and Java files
>and some support for building full applications/ jar files from the
>scheme and java files. The fact that Kawa has a compiler is a big win.

This is a big thing. There are lots of difficulties involved if you want to 
do something reasonably usable. Especially if you want to track dependencies 
between Java classes and Scheme files (i.e. changing a Java file triggering 
a recompile of a Scheme file).

We had these problems at work and had to settle on a quite simple 
compilation scheme: compile the Java code, and then compile the Scheme code. 
This means that our Java classes cannot depend on Scheme classes. Also, we 
had to impose rigid naming conventions and coding style to our Scheme source 
files. Do we want to impose those restrictions to all SchemeScript users? If 
it is in order to provide great tools to the developer, I'm not opposed to 
that.

>b) Type inference and Java integration : Stuff like refactoring might
>be better supported with type inferencing. Plus being able to do
>things like 'go to class definition' , 'show type hierarchy' etc.
>Again pure vapourware.

Goto class definition is already supported, but 'show type hierarchy' could 
be nice. Also, a package explorer/dependency graph could be nice, too. Those 
are nice suggestions.

Dominique