[MSLUG] MSLUG Digest, Vol 36, Issue 1
François Pinard
pinard at iro.umontreal.ca
Thu Feb 21 11:51:49 EST 2008
[David St-Hilaire]
> Hmm, that blitzweekend thing seems pretty interesting, as I could give
> us an opportinity to show that scheme can be used to develop some
> fully functional aps quickly...
> Does anyone have a good idea for the dev. of a new technologie? I'm sure
> Marc does... hehe
Hi, people.
(This list is really English-only? What is the linguistic proportions,
here? I do not object to English, of course; I read and write English
in most of my activities. Just that French is so more comfortable :-).
I have ideas for a few possible Blitz projects, all related to current
interests. I've done a lot of Python in the recent years, but would
like to find ways to get a more solid contact with Scheme. So, my
projects are mixed in nature, and because Scheme did not fully recover
its place in my neurons, I surely need complicity of other Schemers.
* My preferred suggestion would be, after having republished Pymacs last
week, to redo something similar for Gambit. Pymacs is a communication
link and protocol between Emacs and Python, meant to ease close
interaction in applications written for both languages at once. See:
http://pymacs/progiciels-bpi.ca
The idea would go along these lines:
- Choose a name for the project! :-) The only idea I had is "Psch!",
as the noise you make when you call for the attention of a cat.
- Redesign the Pymacs API, replacing Emacs Lisp with Scheme.
Paradigms might be different enough for this to be a challenge.
- Pymacs is a bit asymmetrical, in that Emacs is the master and
the Pymacs helper is a Python slave. It would be fun if with
Scheme and Python roles were interchangeable.
- For egotistic reasons, I'm interested in Gambit, but it would
also be nice to have an open view for most Scheme
implementations.
- Creating user documentation. A project is not real without it.
Just in there, there are fights (OK: interesting discussions)
in sight! For Pymacs, I chose reST, we could start from there.
- Programming the Scheme part of the project.
- Programming the Python part of the project.
- Creating a validation suite while the programming goes on.
- Devising a Snowball to package and hold the result.
- Trying to port the result to other Scheme implementations.
- If there were enough people, or even better, if we could have
a second project in parallel, using a different team, develop an
application building on this first, and demonstrating it.
The team would need many members: all thinkers to start with,
a documentation writer who could also act as a project manager,
one or two Python programmers, one or two Scheme programmers,
one guy especially strong on Snow packaging and porting issues,
probably one more guy taking care of the validation suite.
* A second project which could build on Psch! would build an abstract
syntax tree, as a Scheme structure, out of Python source code. Instead
of recreating a lexer and parser in Scheme for Python, we could recycle
the compiler module in Python (which I did not try since it has been
redesigned and redone -- I do not know where it stands now) to build
a Python AST, to be moved into Scheme afterwards. This would mean (team
organisation ideas from the previous project could be recycle here, of
course):
- Designing the Scheme structure for the tree, as useful and generic
as possible (even extensible to other languages by design).
- For the Python part, studying the compiler module and using it.
- For the Scheme part, using Psch! to get the result, or maybe to
launch the whole work.
This second project could be made bigger and more useful in a few ways,
but these are really sub-projects that could be made independently, or
at least, be clean enough so they look like having been done
independently:
- Translating the tree back to (Python) source code.
- Much more difficult, translating the tree back to *nicely formatted*
Python source code. Fitting the result in 80 columns, say, while
using parentheses instead of backslashes for continuation lines, and
staying nice, is a challenge for a human, it should be for a program!
* A third project could be a reST processor all in Scheme. We already
have good reST modes in Emacs and Vim, and a processor suite in Python
(http://docutils.sourceforge.net/) able to produce at least HTML and
LaTeX. Why in Scheme then? The reason is that one of the weak point of
the Snow project is the little support for documentation in its design,
yet if anything happens in that area, it ought to be written in Scheme.
I considered a few other avenues before choosing reST for my own works,
it is pretty powerful on average and has its weaknesses (so the possibly
heated discussions). Providing a Scheme implementation might help its
cause, anyway.
Now, behind the power, there is a recognizing machinery which goes a bit
beyond what is usually found in competing formats. A nice thing is that
the reST designer and docutils author, David Goodger, lives in Dorion,
not so far. Who knows! We might try to convince him to participate in
such a project team as a reST specialist! :-)
The parts to be effected are, likely by different people:
- Designing an internal Scheme structure to represent a reST document.
- Parsing a reST document into the internal structure.
- Producing HTML out of the internal structure.
- Producing TeX or LaTeX out of the internal structure.
You see that such a team would require a few programmers with different
strengths and specialities.
* A fourth project pops to my mind merely because I'm preparing
a bug-fix release for Recode in these days, but it might be too much an
undertaking for a weekend, unless we really find the good guys for it.
It would be nice to have an overall recoding / codecs framework for
Snow. It might be tractable to aim 8-bit charsets and the usual Unicode
things, and there are many things already available in that direction
for Scheme. Tackling the traditional Asian charsets is quite an
undertaking. GNU libc and libiconv already have all the data, yet the
algorithms processing it would require too much study, in my opinion,
for the time available. But once again, with the right specialists
available, maybe it is a "mission: impossible" that could be considered.
* An undeveloped idea would aim the redesign of distributed extreme
programming real-time tools, merely based on Emacs *and*/*or* Vim
*and*/*or* others, and not on any proprietary package. The main goals
would be ease in setup and use, while everybody retaining the control of
their environment, with no much perceptible master/slave relation.
* I have other ideas, but a bit more insane and fuzzy, just in case you
perceive the previous ones as uninteresting trifle! Note that it could
be a Blitz project in itself, brainstorming more than anything else, and
which result would be a list of later Blitz projects :-)
--
François Pinard http://pinard.progiciels-bpi.ca
More information about the MSLUG
mailing list