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
|
