[Chicken-users] hygienic branch (progress report, sort of)

[felix winkelmann]

Hi!


It's silent in here.... So, let me use this moment to give
some progress info on the state of the "hygienic"
chicken that I'm currently working on. In

https://chicken.wiki.br/svn/chicken-eggs/chicken/branches/hygienic

you'll find a modified version of chicken that has been completely
converted to hygienic macros (syntax-rules + explicit-renaming).
It doesn't incorporate all recent changes from trunk, but should
be fairly up to date. "define-macro" is gone (also some things
("define-record", "define-foreign-enum" and "define-foreign-record")
that where currently difficult to implement or just in the way -
these may be added back later) as it will not work reliably
in an hygeinic environment. The macro system has been heavily
overhauled and partially "de-optimized" to have cleaner, more
maintainable code. Macros can now generally be compiled to native
code (using the "compile-syntax" declaration (which replaces the
now deprecated "run-time-macros" declaration), or with
"define-compiled-syntax") and all restrictions like the interaction
of "eval-.when", "include" and "cond-expand" with "define-syntax"
should be removed. Non-contiguous local definitions, local
"define-syntax", DSSSL lambda-lists and curried define should
work now everywhere.

Moreover, a module system based on "psyntax" (a la chez) that
supports macros and compiled syntax has been implemented.
Modules can be imported into the normal toplevel or into other
modules with import-specifications that allow some control over
the set of imported bindings (specifically "only", "rename", "prefix"
and "except" modifiers as in R6RS). Loading module-definitions
(interpreted or compiled) into the compiler (using "-X" for example)
makes a module available to compiled code. To avoid the problem
of dragging around compile-time code and to be able to support
cross-compilation (where a module that exports syntax may be
compiled for a different architecture) something called
"import libraries" is provided. These contains just the module
declaration and any exported syntax and can be compiled
separately. The "import" form is able to locate these libraries
automatically, so using this feature is relatively transparent
to the user. To create import libraries use the declaration
and/or  command-line option "import-library"  (surprise).

Built-in modules are currently "scheme" (r5rs), "chicken" (library unit)
and one module for each library unit. I had to touch the build, as
the import libraries for these modules are compiled as dynamically
loadable modules - I hope I didn't break anything for the less
popular platforms.

I have done quite a number of tests (including Alex's "matchable"
and "loopy-loop" macro libraries) and think that the macro
implementation is relatively well working. The module system is
not perfect in the moment (for example, syntax-definitions are
not referentially transparent on the module level), but simple
tests seem to work ok. I have not tested any egg with this version,
I don't know if chicken-setup works at all (but it should). This branch
has version "4.0.0x" and major version "4", binary version "4". To
test it, install it into a different prefix. Remember that this is work
in progress.

There is no documentation yet - I'm going to do that next. But I'd
be delighted if people take a look and I'd also be grateful
for nasty syntax-rules test-cases, which will be added to the test-suite.

Oh, before I forget: following my usual impulse of removing things, I have
nuked the pattern matcher (use matchable) and everything that has
been deprecated in the last major release. The internal hooks for alternative
macro systems are gone.

This hygienic chicken represents in my humble opinion the direction into
which chicken should go. It breaks with backward compatibility in quite
a number of points and will require major effort to port all eggs to (some
eggs will have to be dropped). It would be helpful if the chicken users and
hackers take a moment to consider whether this is acceptable and right,
or whether we should keep the current system, which is less scalable
in terms of modularity, but nevertheless quite stable.

Please feel free to ask questions and please report any bugs you'll
find. I will update the manual and announce it once I'm ready. You
can look in tests/module-tests.scm and of course the sources for first
hints at how things work.


cheers,
felix