Fork me on GitHub
#clojure-dev
<
2015-08-13
>
danielcompton00:08:40

@alexmiller: I’ve been thinking about building software to test new versions of Clojure against existing Clojure libraries to help detect breakages early. Is this something that would be useful?

Alex Miller (Clojure team)03:08:47

Sure. I know Andy has something like this and there was in the past something like this inside Relevance before I was there

andrewhr12:08:26

so... decomplecbot 😉

ghadi13:08:30

looks like adding meta calls seq()

mpenet13:08:50

yup I noticed

mpenet13:08:00

this feels like a bug, right?

mpenet13:08:07

if not this should be documented

ghadi13:08:44

can't pass the same internal thunk to two different LazySeq instances, else it will be realized twice

ghadi13:08:53

(and lazy seq bodies are ^:once fns)

ghadi13:08:33

I suppose it can be rationalized...

mpenet13:08:39

it can be, but this is impl details imho, a lambda user would expect a new LazySeq instance with the metadata attached

mpenet13:08:58

I got a bug caused by this, and it took me a while to drill down to find the cause, and I don't think I'd be considered a casual user. as I said, either it should be changed or documented imho

ghadi13:08:38

I guess file a jira...my hunch is that it will be a doc clarification. I don't see how to implement it properly

ghadi13:08:52

*er change the impl to handle it

Alex Miller (Clojure team)14:08:28

I thought this a bit and I think it has to be this way

Alex Miller (Clojure team)14:08:09

Not sure where it could be doc'ed other than the metadata page

mpenet14:08:13

I guess this could be a special case where metadata is "set" and the same LazySeq instance returned, but this might be a bit hairy to implement, documenting it is what seems to be the least horrible here

Alex Miller (Clojure team)15:08:46

that is also not how metadata is designed to work