From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: [ANN] New library stream.el in ELPA Date: Wed, 14 Oct 2015 14:37:50 +0200 Message-ID: <87d1whaan5.fsf@web.de> References: <87d1whk75h.fsf@petton.fr> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1444826421 14947 80.91.229.3 (14 Oct 2015 12:40:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Oct 2015 12:40:21 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 14 14:40:12 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZmLLl-0006o1-OW for ged-emacs-devel@m.gmane.org; Wed, 14 Oct 2015 14:40:09 +0200 Original-Received: from localhost ([::1]:42121 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmLLl-0007fd-1R for ged-emacs-devel@m.gmane.org; Wed, 14 Oct 2015 08:40:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42384) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmLJu-0007Ka-69 for emacs-devel@gnu.org; Wed, 14 Oct 2015 08:38:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZmLJp-0006xe-Pb for emacs-devel@gnu.org; Wed, 14 Oct 2015 08:38:14 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:49106) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZmLJp-0006xQ-IV for emacs-devel@gnu.org; Wed, 14 Oct 2015 08:38:09 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZmLJm-0004wy-Eb for emacs-devel@gnu.org; Wed, 14 Oct 2015 14:38:06 +0200 Original-Received: from ip-90-186-1-49.web.vodafone.de ([90.186.1.49]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Oct 2015 14:38:06 +0200 Original-Received: from michael_heerdegen by ip-90-186-1-49.web.vodafone.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 14 Oct 2015 14:38:06 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 47 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip-90-186-1-49.web.vodafone.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:57c3GL+XOsCLKy2sL33yLF+bS/o= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:191556 Archived-At: Nicolas Petton writes: > I just pushed to ELPA the first version of `stream', a new library that > provides an implementation of streams. Streams are implemented as > delayed evaluation of cons cells, and are immutable. In that sense they > are similar to streams in the SICP book[1] or to Clojure's lazy > sequences. FWIW, I implemented quite the same some years ago, but never got happy with it. The problem was that streams defined via delayed conses end up to be massively nested lambda structures. Emacs has no tail recursion, and sooner or later, I always ended with very simple examples, like computing the 500nth prime in the stream of primes, hitting the `max-lisp-eval-depth' limit. I don't recall the details of a counterexample, but I ended up dismissing the approach completely, because it was hopeless. Then I switched to working with generator.el, and defined a different form of streams I called "ilists". These are like normal lists, but (speaking simplified) the last cdr contains a rule to compute more elements on the fly when they are referenced. That approach gives you a quite similar kind of semantical thing offering the same functionality, without the deadly recursion problem. My fear is that you will soon see `max-lisp-eval-depth' related errors when doing very simple things with your streams and trying to reference element 500 or so. Sorry, but I really don't recall a good counterexample. It would be great if I'm proven wrong by your implementation, but I'm not optimistic. I tried with your package (defun fib (a b) (stream-cons a (fib b (+ a b)))) (seq-elt (fib 0 1) 10) but got the error unless: Symbol’s value as variable is void: #:forced Regards, Michael.