This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-07-03
Channels
- # admin-announcements (21)
- # beginners (13)
- # boot (215)
- # cider (36)
- # clojure (24)
- # clojure-berlin (7)
- # clojure-japan (59)
- # clojure-korea (2)
- # clojure-russia (5)
- # clojure-seattle (1)
- # clojure-uk (5)
- # clojurescript (119)
- # clojurex (4)
- # code-reviews (4)
- # cursive (8)
- # editors (3)
- # euroclojure (27)
- # ldnclj (15)
- # off-topic (57)
- # re-frame (1)
- # reagent (108)
- # yada (3)
Just to confirm, this won’t cause a stack overflow, right: (fn iter [f n] (cons n (lazy-seq (iter f (f n)))))
@pupeno: that's how iterate is defined
so no..
Cool. Thanks.
Out of curiosity. At euroclojure, Alex Kachayev talked about muse https://github.com/kachayev/muse
And I guess what I'm wondering about is if this could have been done with a normal map
, if you in some way could tell map to do something special when the collections were muse related.
It seems like the arguments to fmap
need to be something which implements the protocol ComposedAST. I guess where I would want to go is if the collections which are passed to the normal map
had to implement some protocol IMappable
which then the muse datastructures also could have implemented?
arguments to muse/fmap
need to be something which implements the protocol muse/MuseAST
or muse/ComposedAST
or muse/DataSource
(the last one is how it was meant to be used)
event if you have technical ability to implement this with clojure map
, it still will be very confusing for most developers
Yes, but if clojure map
was defined in terms of a protocol, you could let your protocols extend the protocol of map
I guess my real question is, what would a protocol for the arguments of map
look like
So, if ISeq were a protocol and not an interface, your protos could extend ISeq and you could have used map?
they can't, afaik. Clojure isn't designed around subtyping (in most of it's places anyway)
Protocols can extend interfaces
It can get a bit tricky when a concrete type has multiple applicable paths in a protocol though - it's possible for the choice of path to be arbitrary as protocols have no preference info like multimethods