[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: API for introduction of bindings
From: |
Michael Livshin |
Subject: |
Re: API for introduction of bindings |
Date: |
18 Dec 2000 19:20:24 +0200 |
User-agent: |
Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (20 Minutes to Nikko) |
Mikael Djurfeldt <address@hidden> writes:
> address@hidden writes:
>
> > At 17 Dec 2000 20:00:38 +0100,
> > Mikael Djurfeldt wrote:
> > >
> > > I suggest that we instead focus on the problem of dividing the current
> > > set of bindings into a nice hierarchy of modules, like
> > > "(core safe-r5rs)", "(core r5rs)", etc. (I think Maciej and Jim had a
> > > preliminary proposal, Maciej? Jim?)
> >
> > I'd prefer modules like "(core list)", "(core string)", etc. according
> > to their functionality rather than standards. We can build standard
> > modules like "(scheme r5rs)" by importing the core modules and exporting
> > necessary bindings, right?
>
> That's certainly possible.
>
> Is this useful? (It's not meant as a rhetoric question.)
not to the end-users, IMHO. but in the implementation -- maybe.
perhaps it would make building different Scheme dialect modules
easier.
like:
(dialect R4RS): (...)
(dialect iScheme): ((dialect R4RS) (core GOOPS) ...)
(dialect R5RS): ((dialect R4RS) (core macro-system) (core dynwind))
(dialect Guile): ((dialect R5RS) (core syntax-case) (core modules) ...)
I'm not sure things like list or string primitives need to be
segregated, though.
--
There are few personal problems which can't be solved by the suitable
application of high explosives.
- scm_system_environment, Mikael Djurfeldt, 2000/12/15
- Re: scm_system_environment, Mikael Djurfeldt, 2000/12/15
- scm_system_environment - OK, Mikael Djurfeldt, 2000/12/16
- Re: scm_system_environment - OK, Dirk Herrmann, 2000/12/17
- Re: scm_system_environment - OK, Marius Vollmer, 2000/12/17
- Re: scm_system_environment - OK, Mikael Djurfeldt, 2000/12/17
- API for introduction of bindings, Mikael Djurfeldt, 2000/12/17
- Re: API for introduction of bindings, Dirk Herrmann, 2000/12/18
- Re: API for introduction of bindings, kxn30, 2000/12/18
- Re: API for introduction of bindings, Mikael Djurfeldt, 2000/12/18
- Re: API for introduction of bindings,
Michael Livshin <=
- Re: API for introduction of bindings, Martin Grabmueller, 2000/12/18