Re: [Chicken-hackers] [PATCH] Turn chicken.condition into a module, with syntax exports!

[Evan Hanson]

On 2017-05-19 11:20, Peter Bex wrote:
> I actually prefer using that hack of "internal" modules.  Modules are a
> standard approach that users will already be familiar with, which means
> the barrier to entry should be slightly lower.  And, also important, with
> modules you get an error when you try to refer to a procedure that isn't
> exported.  So, if we remove a procedure for example, we will immediately
> know when we forgot to remove a call site.

H, this is true. I'm just a bit concerned about making things overly
complicated within core. And, it isn't nice to make users deal with
extra files just because it makes our own lives more convenient (for
example when distributing a program as C files, where they now have to
worry about an internal.c as well as runtime.c, library.c, and so on).
But maybe it won't be a problem if we're considerate about it.

> Besides, AFAIK non-exported module identifiers will be hidden by the
> compiler, so we'd have to add another hack to prevent that.

Actually, explicitly-namespaced identifiers, like qualified symbols, are
not hidden, so that's no problem.

Cheers,

Evan


signature.asc
Description: PGP signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Turn chicken.condition into a module, with syntax exports!

[Peter Bex]

On Fri, May 19, 2017 at 01:10:03PM +1200, Evan Hanson wrote:
> I think before we strip many more qualified symbols we should come up
> with an idea of how to handle their replacements. With that "escape
> hatch" change, we can now do basically whatever we want, and we can even
> (for example) get rid of the "internal" module (always a bit of a hack,
> and one that I'd like to see go away...), in favor of direct assignments
> to whatever namespace we decide to use.

I actually prefer using that hack of "internal" modules.  Modules are a
standard approach that users will already be familiar with, which means
the barrier to entry should be slightly lower.  And, also important, with
modules you get an error when you try to refer to a procedure that isn't
exported.  So, if we remove a procedure for example, we will immediately
know when we forgot to remove a call site.

Besides, AFAIK non-exported module identifiers will be hidden by the
compiler, so we'd have to add another hack to prevent that.

> On 2017-05-07 21:47, Peter Bex wrote:
> > PS: before you run "make check", you'll need to install and recompile
> > with the new compiler (or just go through a chicken-boot process),
> > there are some issues with the static linking tests otherwise.
> 
> It was actually possible to compile this with the 5.0.0pre1 snapshot
> directly, sans boot-chicken. I think any static linking test failures
> you saw are probably related to #1366 and not the version used to
> bootstrap.

Oh right, I forgot about that one.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Turn chicken.condition into a module, with syntax exports!

[Evan Hanson]

Hi Peter,

On 2017-05-07 21:45, Peter Bex wrote:
> 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.

These have been applied. Excellent work, it looks like these were tricky
changes.

> 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.

Thanks. This wasn't as tough to review as I'd expected, and that
certainly helped. Thank you also for explaining the workarounds for
bootstrapping.

I think before we strip many more qualified symbols we should come up
with an idea of how to handle their replacements. With that "escape
hatch" change, we can now do basically whatever we want, and we can even
(for example) get rid of the "internal" module (always a bit of a hack,
and one that I'd like to see go away...), in favor of direct assignments
to whatever namespace we decide to use.

On 2017-05-07 21:47, Peter Bex wrote:
> PS: before you run "make check", you'll need to install and recompile
> with the new compiler (or just go through a chicken-boot process),
> there are some issues with the static linking tests otherwise.

It was actually possible to compile this with the 5.0.0pre1 snapshot
directly, sans boot-chicken. I think any static linking test failures
you saw are probably related to #1366 and not the version used to
bootstrap.

Cheers,

Evan

___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

Re: [Chicken-hackers] [PATCH] Turn chicken.condition into a module, with syntax exports!

[Peter Bex]

On Sun, May 07, 2017 at 09:45:07PM +0200, Peter Bex wrote:
> 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.

PS: before you run "make check", you'll need to install and recompile with
the new compiler (or just go through a chicken-boot process), there are
some issues with the static linking tests otherwise.

Cheers,
Peter


signature.asc
Description: Digital signature
___
Chicken-hackers mailing list
Chicken-hackers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-hackers

[Chicken-hackers] [PATCH] Turn chicken.condition into a module, with syntax exports!

[Peter Bex]

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
From 3d3338c678425f96c45f0994f01a562a5b6d6afe Mon Sep 17 00:00:00 2001
From: Peter Bex 
Date: Sun, 7 May 2017 16:45:16 +0200
Subject: [PATCH 1/2] Add chicken.condition module

---
 README|   1 +
 chicken-install.scm   |   1 +
 chicken-syntax.scm|   7 +-
 chicken.import.scm|  26 +++---
 core.scm  |   1 +
 csi.scm   |   1 +
 data-structures.scm   |   5 +-
 defaults.make |   8 +-
 distribution/manifest |   2 +
 eval.scm  |   2 +-
 expand.scm|   3 +-
 library.scm   | 252 +++---
 modules.scm   |  12 ++-
 posixunix.scm |   1 +
 posixwin.scm  |   1 +
 rules.make|  10 ++
 scheduler.scm |   2 +-
 support.scm   |   1 +
 types.db  |  42 -
 19 files changed, 211 insertions(+), 167 deletions(-)

diff --git a/README b/README
index 27db7bb..2047a8d 100644
--- a/README
+++ b/README
@@ -286,6 +286,7 @@ _/_/_/_/_/_/  _/_/_/_/_/
 	|   |   |-- chicken.import.so
 	|   |   |-- chicken.bitwise.import.so
 	|   |   |-- chicken.compiler.user-pass.import.so
+	|   |   |-- chicken.condition.import.so
 	|   |   |-- chicken.continuation.import.so
 	|   |   |-- chicken.csi.import.so
 	|   |   |-- chicken.data-structures.import.so
diff --git a/chicken-install.scm b/chicken-install.scm
index 05f2600..0e56b0e 100644
--- a/chicken-install.scm
+++ b/chicken-install.scm
@@ -28,6 +28,7 @@
 
 (import (scheme))
 (import (chicken))
+(import (chicken condition))
 (import (chicken foreign))
 (import (chicken data-structures))
 (import (chicken keyword))
diff --git a/chicken-syntax.scm b/chicken-syntax.scm
index 65367b8..a69721f 100644
--- a/chicken-syntax.scm
+++ b/chicken-syntax.scm
@@ -873,8 +873,7 @@
 
 (##sys#extend-macro-environment
  'handle-exceptions 
- `((call-with-current-continuation . ,(##sys#primitive-alias 'call-with-current-continuation))
-   (with-exception-handler . ,(##sys#primitive-alias 'with-exception-handler)))
+