Re: [Chicken-hackers] [PATCH] Add initial version of (chicken base)

[Peter Bex]

On Sat, Sep 16, 2017 at 04:40:49PM +1200, Evan Hanson wrote:
> On 2017-09-12 10:51, address@hidden wrote:
> > > - notice (we already had "warning" and "error", however, notice seems
> > >           to be used mostly in the compiler)
> > 
> > Does this need to be exposed? I'm not sure how useful this is for user
> > code.
> 
> I think we should drop "notice" and "warning" from the public API. As
> you say they're not very useful for end users, and I'd prefer it if
> there were a well-supported egg for that sort of thing rather than
> something we have to worry about maintaining in core (kind of like how
> "test" is the de-facto standard unit testing egg).

Agreed, let's drop those from (chicken base).  This includes the
"enable-warnings" procedure, because it makes no sense to have a way
of programmatically enabling/disabling warnings that only the core
tools should be emitting anyway.

Maybe we can move this into support.scm or something similar?  I looked
into it, but saw that chicken-install and friends are using "warning"
too, and they don't use support.scm, so I think it's not too simple.

So for now I've updated the patch (attached) to simply keep warning and
notice where they are.  (chicken base) is not exporting it.  The old
patch didn't apply anymore due to a merge conflict, which I've also fixed
in this new one.

> > > - use
> > > - require-library
> > > - require-extension
> > > - quotient&{remainder,modulo}
> > > 
> > > I'm not 100% sure about require-library, require-extension and use,
> > > especially given that import is in (chicken module).
> > 
> > Hm... I thought we try to get rid of all these alternative loading forms?
> 
> Yeah, let's drop these once the "base" module has landed.
> 
> The `require-extension` macro can go in a srfi-55 egg.

I think it makes more sense to keep it in core, for compatibility with
the srfi.  Maybe we can clarify in the documentation that it's just an
alias for (import)?  I think (use) is a bit more questionable, now that
it's also just an alias for (import).

require-library is so weird and does so much (at least, it looks like it
does from the docs), I don't know what to do with it.  Maybe we can indeed
just remove it?

> I think just "scheme" and "base" would be fine, but including the
> modules you listed would also make a lot of sense. Whatever we do, I
> think it's important that compiled and interpreted code behave the same.

100% agreed!  The difference between available identifiers in compiled
and interpreted code is what really gets to people.

> I also don't think we should just include everything from library.scm
> since it includes some libraries like "gc" and "plist" that aren't
> commonly used, and we may want the freedom to shuffle things around in
> the future.

Ah, I hadn't considered that.  I suppose we should just use only
chicken.base and scheme, then, and document it clearly.

Cheers,
Peter

0001-Add-priliminary-version-of-chicken-base-module.patch
Description: Text Data

signature.asc
Description: PGP signature