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?

alexmiller03: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

alexmiller14:08:28

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

alexmiller14: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

alexmiller15:08:46

that is also not how metadata is designed to work