chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-hackers] [PATCH] Turn chicken.condition into a module, with syn


From: Peter Bex
Subject: [Chicken-hackers] [PATCH] Turn chicken.condition into a module, with syntax exports!
Date: Sun, 7 May 2017 21:45:07 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

Hi all,

The core-library-reorganization page has "(chicken condition)" under
"undecided", but I think it's fine the way it is.  The attached patches
add this module.

The first patch is a straightforward change to wrap the relevant
procedure definitions in a module definition.  I decided to also
add the call chain accessing stuff to this module, as I think this
is a better place than (chicken base).

This time around, I minimised the number of ##sys# prefix removals,
to avoid complicating things too much.  It's better to do that in
another pass; this changeset is complicated enough as it is.

Because of the way the bootstrapping process works, the first patch
also defines "#%with-exception-handler" as an alias for the
with-exception-handler from chicken.condition.  That's because we use
the handle-exceptions macro in a few places in the compiler itself.

When we're building with an old compiler, it will use the macro
definitions from that compiler, which will expand to the *old* procedure
names.  The unprefixed "with-exception-handler" is assigned a #% prefix
as always, so it can be accessed from any module, regardless of renames
that have been done.  Thus, we need to ensure that a procedure by the
name of "#%with-exception-handler" can be found.  I added that to the
code of library.scm just after importing chicken.condition.


The second patch is a bit of a mindfuck, but it paves the way to adding
other modules that include syntax exports.  Because we also have the
syntax definitions "handle-exceptions" and "condition-case", I think
those belong in this module too.  But can't put macro definitions in
library.scm or at least, I haven't been able to figure out how to do so:
when I tried, I got into nasty dependency issues with the eval, expand
and/or module units being required, and they depend on library itself.

So instead, I wrote a custom import library, much like we do for the
"chicken" module.  This import library contains all the usual procedure
mappings, but it also contains a syntax environment, which it takes from
a global "##sys#chicken.condition-macro-environment" definition, analogous
to ##sys#chicken-macro-environment.

This is defined in expand.scm and assigned by chicken-syntax.scm, again
much like ##sys#chicken-macro-environment and ##sys#chicken-ffi-
macro-environment.  When compiling with an old CHICKEN version, it will
load the new chicken.condition import library into the compiler and choke
on the non-existent "##sys#chicken.condition-macro-environment", so I added
a temporary workaround to make it use the chicken macro environment as a
fallback when the new definition doesn't exist.

I hope all of this makes sense.  If this works out, we can do a similar
thing for all the other core modules that need to export syntax
definitions.  It's all copy and paste from here on out :)

Cheers
Peter

Attachment: 0001-Add-chicken.condition-module.patch
Description: Text Data

Attachment: 0002-Add-syntax-exports-to-chicken.condition.patch
Description: Text Data

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]