--qOrJKOH36bD5yhNe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 18, 2006 at 11:40:59PM -0800, Jeffrey A. Edlund wrote:
> + add a native scheme interpreter -- I was wondering what was the goal
> of this project.  There are already a number of scheme interpreters in
> pkgsrc. Was there an interest in using scheme during install or
> configuration?  If that was the case, then I was wondering if Lua has
> been considered.  I believe that it has a compatible license and it's
> small size makes it easy to audit. =20

I think Scheme is an excellent choice for an extension language, but I too
don't see why we would need it in base.

Nevertheless, there are some Schemes out there with an acceptable license,
notably lang/scheme48 and lang/chicken.  Scheme 48 even has something
called 'pre-scheme', which is a stripped down version of Scheme that maps
almost trivially to C, which makes it ideal for embedded systems
development.  This would make it excellent for use in NetBSD.  The code
is *very* clean as well.  There's one important issue right now: it
doesn't compile or run on all our supported systems.  It segfaults during
building on my amd64 and the Makefile says it is not available for Alpha
either.

Chicken, on the other hand, is probably the Scheme with the most add-on
libraries and packages today.  Its code is not very clean and compiled
programs require linking against extra libraries (pre-scheme produces
stand-alone C code).  Mostly because of all the add-on packages, its
openness of development (scheme48 is a bit of an "ivory tower" approach
as far as I can tell) and its lightning-fast compiled code it is my
Scheme of choice.  It basically allows you to get your work done with
the least amount of fuss.  There is already a Linux project that uses
Chicken intensively for scripting and extension; Adamantix.
See http://www.adamantix.org

Also very important: both Schemes come with excellent FFIs, so interfacing
to C is easy.

Then there's tinyscheme, which also has a BSD license, but I'm not sure
if it's usable right now.  Its size suggests it would be perfect for
embedded use, but it is not very complete.  It has no hygienic macros,
interfacing to foreign functions is awkward and its code is one
monolithic .c file.

Apparently lang/gauche is a very good BSD-licensed Scheme for scripting.
I haven't tried it myself yet, so I can't say much about it.

> I know that OpenBSD ships with perl and I think that freeBSD does as
> well. If we wanted to use such a large language, my own preference
> would be for Python, but I understand that people use NetBSD a lot in
> embedded environments so we might want to keep such things out of the
> base system.  (However I do think that there are a few things that the
> project could do to make things a bit more friendly for sysadmins.) =20

Exactly.  Also, Perl is deprecated IMHO.  Of course, those who love
Perl would say otherwise :)  If we would go for a language like Perl
I would recommend Ruby.  It has great support for regular expressions,
like Perl, but it is truly object-oriented and it's a little more
readable :)

Regards,
Peter
--=20
http://www.student.ru.nl/peter.bex
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
							-- Donald Knuth

--qOrJKOH36bD5yhNe
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (NetBSD)

iQEVAwUBRB06btOrBFwYag3gAQJRBgf/RR6Kc1QNBOcQYiIR2PKqqO+mXj7Q1rUu
jNNxyggq9MtqqPa5EeZyIIf+Xjob2LM7bI7QymB49z2r5r+/z+HL91iAnvrLP0EE
qpD9f1zDuswcT5N7aYzufskQAVsdFR+i339WTxz1mgcHrGnltzFdOspD7GPDN4Y1
EiKI9n9WSAeWAZsO0CgWxpDLfo98sxKYtSLTieezzKRNQwlWI7WCCTdwL3d+EOSi
lyVKgl5n8vJ6vbHwpgUP+35YEMXuGI3lNzB6fF4Ql6SzVhCMqyI5IC5UwWgYZzv0
dO02+ZCFeJPnm3alX86B9Uq86M3EFuCIzFzVXvTtOP9iup9pKJ3xow==
=uVAs
-----END PGP SIGNATURE-----

--qOrJKOH36bD5yhNe--