[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