From: ············@gmail.com
Subject: series and lazy evaluation
Date: 
Message-ID: <58b6efe8-dcbe-48f1-9ddc-061e857acea9@d4g2000prg.googlegroups.com>
From anyone who is familiar with series, http://series.sourceforge.net/,
is there a way to use series like lazy lists in haskell in the
following:

fibs = 1 : 1 : zipwith (+) fibs (tail fibs)

Thanks in advance,

Andrew

From: ············@gmail.com
Subject: Re: series and lazy evaluation
Date: 
Message-ID: <096f0035-e025-4100-a12d-574dda6eb652@e10g2000prf.googlegroups.com>
That is a great question -- one of the best I've seen to this group in
a while!  I just wanted to add to all the other replies, have you
checked out heresy? Looks pretty good and it even has a direct
translation of your haskell expression.

http://cl-heresy.sourceforge.net/Heresy.htm

Kind regards,

Andrew
From: Slobodan Blazeski
Subject: Re: series and lazy evaluation
Date: 
Message-ID: <57d61c55-815a-4b5c-b7bc-9bdd87712d27@e6g2000prf.googlegroups.com>
On Feb 10, 8:26 pm, ·············@gmail.com" <············@gmail.com>
wrote:
> From anyone who is familiar with series,http://series.sourceforge.net/,
> is there a way to use series like lazy lists in haskell in the
> following:
>
> fibs = 1 : 1 : zipwith (+) fibs (tail fibs)
>
> That is a great question -- one of the best I've seen to this group in
> a while!  I just wanted to add to all the other replies, have you
> checked out heresy? Looks pretty good and it even has a direct
> translation of your haskell expression.
>
> http://cl-heresy.sourceforge.net/Heresy.htm

Series is an obscure library even in the lisp, many seasoned lispers
never tried, also c.l.l is populated with lispers. Set intersection of
people who know Haskell, series, and used heresy might 0.
So if you're coming from Haskell why don't you try series and heresy
and judge for yourself, than you can come here and enlighten us.

Slobodan
From: Tayssir John Gabbour
Subject: Re: series and lazy evaluation
Date: 
Message-ID: <96aeb8fd-427b-4a6e-bfbe-4546296f18da@u10g2000prn.googlegroups.com>
On Feb 13, 7:36 pm, David Golden <············@oceanfree.net> wrote:
> Slobodan Blazeski wrote:
> > Series is an obscure library even in the lisp,
>
> It _did_ get a whole appendix in CLTL2, it's not /all that/ obscure.

I'm just looking at the source of cl-ledger, and they certainly depend
on Series. Suspect it's one of those unusual-looking things that
people feel the desire to climb...

Heresy looks cool...


Tayssir
From: David Golden
Subject: Re: series and lazy evaluation
Date: 
Message-ID: <GMGsj.24517$j7.452438@news.indigo.ie>
Slobodan Blazeski wrote:
> 
> Series is an obscure library even in the lisp, 

It _did_ get a whole appendix in CLTL2, it's not /all that/ obscure.

Okay, CLTL2 is "old" now and standards-wise superseded by ANSI, so maybe
there's a crowd sweeping in that haven't seen it, but it is available
online:

http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/cltl/mirrors.html
From: Kent M Pitman
Subject: Re: series and lazy evaluation
Date: 
Message-ID: <uk5l8flrw.fsf@nhplace.com>
David Golden <············@oceanfree.net> writes:

> Slobodan Blazeski wrote:
> > 
> > Series is an obscure library even in the lisp, 
> 
> It _did_ get a whole appendix in CLTL2, it's not /all that/ obscure.
> 
> Okay, CLTL2 is "old" now and standards-wise superseded by ANSI, so maybe
> there's a crowd sweeping in that haven't seen it, but it is available
> online:
> 
> http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/cltl/mirrors.html

"old" is a weird word.  Specs don't age.  Neither do good ideas.
Things either work or they don't and the word "superseded" is only
meaningful if it's given more texture than is mentioned here.  Let's work
through this...

First of all, the tree of inheritance for documents about CL is like the
following.  Steele knew he was doing a personal thing and that some people
might not like it.  It wasn't done behind anyone's back, but it was the 
source of some mild controversy.  His preface to the second edition records
the fact of the controversy--I don't have it here before me as I write, but
I think it's around page xiv, if memory serves.

   Maclisp  others
      |    / 
      |   /
     [CLTL] = an ad hoc committee of interested parties,
      |       acting as a committee, chaired by Steele
      |       this version of CLTL was committee endorsed
      |       and committee reviewed, and the actual work
      |       product of the committee
      |
 ANSI process starts, using
  CLTL as base document)
      |
      |
      v
    various 
   drafts of - - - - - > [CLTL2]
     spec                a personal work of Steele,
      |                  a snapshot at a random time convenient to him,
      |                  unsynchronized with X3J13, and also
      |                  not approved by nor later reviewed by X3J13
      v                  [I'm not sure whether his snapshot is before or
   dpANS1, dpANS2,       after the dpANS stream started, but it is not
   dpANS3, dpANS3R       a proper representation of the dpANS state]
      |
      v
   ANSI CL

The whole point of the picture is to say that ANSI CL did not supersede
CLTL2.  They are each descended from CLTL, but they are half-siblings,
at best.

One reason this is true is that the progress to make the final spec
was not monotonic--we backed out of various things that we had partly
done in the intermediate times, so Steele documents some stuff that
was believed to be coming that didn't actually end up in the spec.
The tools related to macro environments as first class objects was the
main thing there, but there were other small issues, too.  (The macro
environments thing was largely regarded as a good idea, it just had
bugs we didn't think we could resolve reliably by time we had to cast
the standard into stone for all time, so we removed it rather than
publishing it wrong, figuring that it could be added later as a
compatible extension if someone worked out the details and got a
working implementation.  Standards are not, as I've so often
mentioned, a good forum for design work--they are much better when you
have a design that is deployed and tested and just needs to be written
up.)

HOWEVER, as to Series, I think the right thing to understand is that
SERIES was never in ANSI CL at all.  Steele just liked it.  It's got
some good ideas, and he wanted to promote it for possible future
work/interest/consideration.  So the fact that ANSI CL had no place
for it doesn't suggest that it is obsolete in any way, and I think all
concerned would be disappointed if you construed that its failure to
appear as a suggestion in a later document that had no suggestions
meant it shouldn't be considered. (If that were a rational and known
theory of how people would draw inferences about it, I'm quite sure
Steele would have just left it out so that he didn't prematurely
implement its demise.)

The reason I personally never got excited about SERIES was that I was
always slightly distrustful of its implementation... and I'm not sure
whether for any good reason.  I just know it needed to do full
tree-walking and he was wishing for a full macroexpansion facility,
and we didn't have very good answers to that (exactly because of the
absence of the environments as first-class objects problem), so I
worried that if we didn't have a good answer he might be cutting
corners.  Was he?  I don't know.  And I don't mean to disparage the
good efforts of Dick Waters, its creator--he's a very intelligent and
talented guy who's done some tremendously thoughtful things.  The
facility may well work fine, or maybe if it fails it fails in
predictable ways that don't hurt anyone.  Also, the implementation
relies on COMPILER-LET for data/control flow, and it was VERY
difficult to translate it to not do so--I spent several days trying
with no success, and finally had to time out because it exceeded the
quantum of time I had to work on it.  A more modern implementation of
the ideas would be really cool to see.... especially if some
implementor worked out the details of the environment stuff and built
a code walker on that for this to use in its implementation.
From: tim
Subject: Re: series and lazy evaluation
Date: 
Message-ID: <13r6qlngaku4a29@corp.supernews.com>
On Wed, 13 Feb 2008 18:36:21 +0000, David Golden wrote:

> Slobodan Blazeski wrote:
>> 
>> Series is an obscure library even in the lisp,
> 
> It _did_ get a whole appendix in CLTL2, it's not /all that/ obscure.
> 
> Okay, CLTL2 is "old" now and standards-wise superseded by ANSI, so maybe
> there's a crowd sweeping in that haven't seen it, but it is available
> online:
> 
> http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/cltl/mirrors.html

I think it's well worth reading. In fact I ended up reading it twice. With
Lisp it seems that you just need to know what functions are there so you
know to go and look them up (in the Hyperspec). The function names are
often very unexpected so knowing what they all are seems to be the only
way:

Eg "remove-if-not" - if I'd known about that I would not have coded my own
routine called "filter".

CLTL also explains a lot of the reasons for things, and good ways to use
Lisp. It is a good bridge between books like Practical Common Lisp and the
Hyperspec.

Tim Josling
From: Slobodan Blazeski
Subject: Re: series and lazy evaluation
Date: 
Message-ID: <d0e4e897-8138-407a-a2d0-1f3ff04845d7@z17g2000hsg.googlegroups.com>
On Feb 13, 7:36 pm, David Golden <············@oceanfree.net> wrote:
> Slobodan Blazeski wrote:
>
> > Series is an obscure library even in the lisp,
>
> It _did_ get a whole appendix in CLTL2, it's not /all that/ obscure.
>
> Okay, CLTL2 is "old" now and standards-wise superseded by ANSI, so maybe
> there's a crowd sweeping in that haven't seen it, but it is available
> online:
>
> http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/cl...

Maybe obscure was wrong word, probably used very rarely is better
explanation.
beside cltl2 doc I never found any other doc re it. And last time when
I asked only one person
said he used it. Or maybe series users don't dwell on c.l.l.

cheers
Slobodan
http://tourdelisp.blogspot.com/
From: Jan Rychter
Subject: Re: series and lazy evaluation
Date: 
Message-ID: <m2prutyhyr.fsf@tnuctip.rychter.com>
Slobodan Blazeski <·················@gmail.com> writes:

> On Feb 13, 7:36 pm, David Golden <············@oceanfree.net> wrote:
>> Slobodan Blazeski wrote:
>>
>> > Series is an obscure library even in the lisp,
>>
>> It _did_ get a whole appendix in CLTL2, it's not /all that/ obscure.
>>
>> Okay, CLTL2 is "old" now and standards-wise superseded by ANSI, so maybe
>> there's a crowd sweeping in that haven't seen it, but it is available
>> online:
>>
>> http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/cl...
>
> Maybe obscure was wrong word, probably used very rarely is better
> explanation.
> beside cltl2 doc I never found any other doc re it. And last time when
> I asked only one person
> said he used it. Or maybe series users don't dwell on c.l.l.

I've used Series. I found it rather tricky to use correctly. I don't
think I would use it now -- the only benefit that I can see is good
performance while keeping a functional programming style.

--J.
From: ············@gmail.com
Subject: Re: series and lazy evaluation
Date: 
Message-ID: <b2b5e0cb-d339-48c4-9d42-94904a85cebf@2g2000hsn.googlegroups.com>
Sorry for the long delay in reply -- I've been busy with work and
haven't had time to look at this question.  It turns out that series
is quite suitable.  Below I define a series (basically a lazy
sequence) *fibs* to hold the fibonacci series (the whole thing).

CL-USER> (asdf 'series)
...
NIL
CL-USER> (use-package :series)
T
CL-USER> (defvar *fibs*
	   (scan-fn '(values integer integer)
		    #'(lambda () (values 1 1))
		    #'(lambda (a b)
			(values b (+ a b)))))
*FIBS*
CL-USER> (defun take (n series) (subseries series 0 n))
TAKE
CL-USER> (take 10 *fibs*)
#Z(1 1 2 3 5 8 13 21 34 55)
CL-USER> (defun drop (n series) (subseries series n))
DROP
CL-USER> (defun head (series) (collect-first series))
HEAD
CL-USER> (defun nth-fib (n)
	   (head (drop n *fibs*)))
NTH-FIB
CL-USER> (nth-fib 1000)
70330367711422815821835254877183549770181269836358732742604905087154537118196933579742249494562611733487750449241765991088186363265450223647106012053374121273867339111198139373125598767690091902245245323403501