chicken-hackers
[Top][All Lists]
Advanced

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

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


From: Evan Hanson
Subject: Re: [Chicken-hackers] [PATCH] Add initial version of (chicken base)
Date: Sat, 16 Sep 2017 16:40:49 +1200

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

- 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 by default the entire scheme and (chicken base) modules should
be available at the regular and meta toplevels.

Sounds good to me.


I'm less certain what we should add to the non-macro toplevel default
Perhaps (chicken type), (chicken fixnum), (chicken flonum) and
(chicken foreign) [the latter for compiled code], but we could also
keep it otherwise empty, or even add everything from library.scm, much
like we do today in CHICKEN 4.  This would make it easier for scripts,
but perhaps a bit more confusing for beginners ("what do you mean,
sometimes I have to import and sometimes it's already there?!!")

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

Cheers,

Evan



reply via email to

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