[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] Re: sequences egg
From: |
F. Wittenberger |
Subject: |
Re: [Chicken-users] Re: sequences egg |
Date: |
Mon, 22 Nov 2010 17:45:41 +0100 |
Am Montag, den 22.11.2010, 15:03 +0100 schrieb Jörg F. Wittenberger:
> Am Montag, den 22.11.2010, 03:11 -0500 schrieb Felix:
> > >
> > > For a Scheme (who would never ever - promised - participate in a
> > > religious war ;-) the file kinda feels like Felix haven read too much CL
> > > recently.
> > >
> >
> > Yes, that may be, but being able to use a common API over various
> > sequences appears to be something that especially newcomers to
> > chicken might miss, since most dynamic languages more or less do
> > this. It is not meant pedagogically, and I don't even consider it
> > a shortcoming of Scheme to chose different names for the same
> > operation over different sequence-types. But it still may be
> > useful or make things more accessible.
>
> How about stealing most from SRFI-1 like this?
... which does not actually work because
- an error in srfi-1 reference, which is fixed in chicken
- a typo
- an logical error when it comes to repeated traversal of a sequence in
the "weird case".
here's a better version if that's interesting.
> Another appealing would be to have a file with definitions like
>
> (define (sequence:= = . lists) ...)
>
> Note, that the first, rest, empty? args are missing.
>
> Those plus some constructors for result sequences would be imported
> within the modules, which includes these definitions. One module per
> sequence type.
>
> Together with the suggestion of export prefix stripping (see other
> posting), it would we a matter of a pretty simple module clause to
> implement a 89 or alike well debugged procedures.
>
> (Actually I'm not sure, whether or not there is an advantage in having
> the full code compiled specific to a certain type. Though this would
> probably better for optimisation. Would it? But it nevertheless
costs
> the full code per type.)
Though I forgot to mention the real advantage of the latter approach:
the constructors for the result sequence could be imported syntax.
Thereby easily turning the whole thing into version operating over
streams. (Where the seqeunce:= example is a bad one to use if the
streams where infinite.)