chicken-users
[Top][All Lists]
Advanced

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






reply via email to

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