-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
These are all very important issues...
On 10-Mar-07, at 6:12 AM, Alexander Sepp wrote:
hi,
i'm new now to scheme, and of course snow. after fiddling around with snow and esp. gambit a while, i stumbled over some things that keep me thinking and grumbling. So i have few questions regarding the scheme now framework:
- Signature handling
afaics, every file in a snowball archive has it's own signature. why is this the case? wouldn't it be cleaner (and simpler) to provide the signature over the complete snowball archive itself? the problem is, that if i can not verify the origin of a tarball, i do not even want to untar it.
The snowball structure is designed so that a package's parts can be contributed, and signed, by different people. For example someone may be working on the Bigloo port while someone else is working on a Gambit port. The maintainer can then collect these (separately signed) parts and just drop them into the package directory, then upload the package.
- Performance
i did some quick tests with the digest package. i noticed a performance drop of 2/3 using gambit compared to the version in ~~lib/digest.scm (delivered with the gambit system). how do i get the performance back, still using the snowball?
That is odd. There is no reason why Snow packages should run slower. I will investigate.
- snow-* namespace
if i want to use fixnum arithmetic, i have to write (snow-fxadd a b); wouldn't be (fxadd a b) simpler and maybe confrom to the upcoming R6RS? the same holds for (snow-u8vector...). latter is from my point of view another workaround for various duplicated srfi's?
The "snow-XXX" name is used when there is a possible name conflict with an XXX operation on some Scheme system. Often snow-XXX and XXX are related operations, but they may have slightly different semantics (accepted number of arguments, result in special cases, signaling of errors, etc).
I don't particularly like the "snow-" prefix and I hope that with time the Snow packages can deprecate those names when the various Scheme systems adopt a consistent semantics. A good example is fx+, fx*, etc which should be standardized by R6RS.
i hope these questions are not totally superfluous and already answered. i think the scheme now framework is a very clean approach to provide the fundamental base libraries needed by todays applications. i also appreciate to see native scheme implementions of crypto algorithms. normally, there are only questionable ffi wrappers provided.
Thanks. It was a lot of work to write those algorithms in Scheme. The goal of course was to have a 100% pure Scheme implementation, so that snowman could do package signing and certificate management without requiring external tools (allowing one to run Snow on embedded systems for example).
Marc