Clojure 1.6.0 user=> (def foo (delay (str @foo))) #'user/foo user=> @foo StackOverflowError clojure.lang.Delay.deref (Delay.java:37) user=>
same with Clojure 1.7.0-master-SNAPSHOT, I don't see it returning nil as you said. On Fri, Feb 13, 2015 at 7:53 AM, Fluid Dynamics <a2093...@trbvm.com> wrote: > On Friday, February 13, 2015 at 12:47:17 AM UTC-5, Justin Smith wrote: >> >> I don't want to sound too brusque in my defense of Clojure. I'm a huge >> fan, so criticism of the language does get me a bit defensive. > > > I am a fan as well. Constructive criticism is useful as it can lead to > improvements. > >> >> But preferring different behavior is actually reasonable here. There are >> other Lisps (and languages in the ML family) that are more internally >> consistent. I'll continue to prefer the better performance and easy access >> to host interop, even if it does violate the occasional abstraction. But of >> course there is no reason to begrudge someone else holding a different >> opinion, and choosing a language that aligns with those expectations. >> >> But I do hope you give Clojure a chance, it's been very rewarding for me >> and I expect you'd find the same if you take the time to get to know it and >> get a feel for what's idiomatic > > > Actually, I've been using it for years. And I've never encountered behavior > like this, until now. It is definitely wrong for a lazy sequence to either > a) appear to have the wrong length or b) appear at different times to have > different lengths. As long as the var isn't rebound, "primes" indisputably > should appear to have a fixed, immutable value, whether parts of that value > are lazy via delay/force or otherwise. > > It appears that there is a buggy corner case with self-referencing delays, > where if you (delay code) and "code" has a reference to the delay and tries > to force it, it sees the delay's value as nil rather than, as it probably > should, throwing an exception. (Recursively calling the delay's code leading > to an eventual StackOverflowError seems like the only other *sensible* > alternative, but if you can detect that case and return nil instead you can > detect it and throw an exception directly. Something straightforward, like > an IAE with a message of "Delay tried to force itself on evaluation" or > something. This would be far preferable to exposing visible mutation in a > thing that is supposed to be semantically immutable, such as (rest x) > changing from nil to non-nil, and also exceptions are far preferable to > returning a logically-incorrect result without complaint.) > > Incidentally, I don't see the same behavior using my somewhat old copy of > Clojure 1.5.1: > > => (def foo (delay (str @foo))) > #'user/foo > => @foo > StackOverflowError clojure.core/deref (core.clj:2114) > > This is what I'd expect a naive implementation to do. So it looks like in > 1.6 this must have changed to produce nil from the inner @foo, for lazy > sequences to look like they terminate early from "inside themselves", and in > 1.7 it *may* have changed again. I think clarification is needed here on > what is going on. One thing already clear is the preference order of > possible behaviors: > > nil < StackOverflowError < more specific exception such as "delay tried to > force itself". > > Which suggests that 1.5.1 > 1.6, in this particular area... > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
