Re: Text replacement capability in clojure macros (just like C #define)
f...@helpshift.com writes: > I want to write a macro > > (defmacro params [] 'a 'b 'c) > > that will be used in places like this > > ;; without macro > (fnc a b c) > > ;; with macro > (fnc pararms) => (fnc a b c) If you have a list of params, you can apply a function to it like so: (apply fnc params) e.g. (apply + [1 2 3]) ;=> 6 No macro needed. 'apply' is just another function. Does that help? -- 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.
Re: More info on Rich Hickeys ideas on Map types from "Maybe Not"
I guess I'll take a crack at this... I think generally, core.spec is an implementation of contracts, so you could look at the literature around contracts for some sources. Racket is (afaik) most integrated contract language, there are some references here to start with: https://docs.racket-lang.org/reference/contracts.html This data type you are asking for is not really a data type in how Clojure understands data types. It's more like a functor. One example from Rich's slides involves changing a function from foo :: x -> y to foo :: Maybe x -> y This will break existing callers because they need to supply a different first argument. But this can be sort of smoothed over using fmap fmap :: (a -> b) -> Maybe a -> Maybe b So instead of changing the type of foo, you would change the caller to use (fmap foo) :: Maybe x -> Maybe y. But you can't do set operations on functors, so you kinda lose a lot. You could get some of it back by introducing category theory operations, as Haskell does, but then you have to deal with category theory. I suppose that would be a great place to start, looking at the limits of set theory and category theory. Lots of literature there... Also, what's wrong with citing a presentation or an implementation as a reference? It's as valid as any other publication. Henning Sato von Rosen writes: > 1) Is this data type described in a research paper? Or Maybe Rich have > written a more precise description than given in "Maybe Not"? > 2) Does it have an established name, that can be search for on the web? The > combination of the two principles above seems very appropriate for > modelling certain domains, so it certainly deserves a name, don't you > think? Hickey Types anyone? Or Component/Shape Map Types? > 3) Is Rich the first one to combine these two principles or are there prior > art? > 4) Is the second principle covered somewhere in the clojure/spec > documentation. -- 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. signature.asc Description: PGP signature
Re: More info on Rich Hickeys ideas on Map types from "Maybe Not"
Henning Sato von Rosen writes:
> Sorry if I'm wrong here, but I'm not sure we are talking about the same
> data-type; I'm not referring to the Rich's examples with Maybe, but his
> examples with records/maps, where some fields may or may not be present.
Right, and in most other type systems, the only way to indicate
field presence is with a Maybe type:
data MyData = MyData
{ oneField = Maybe Int
, twoField = Maybe String
}
So to convey that these fields don't exist, we have to explicitly say
"Nothing":
instance Monoid MyData where
mempty = MyData { oneField = Nothing, twoField = Nothing }
which, in GHC, is known and enforced at compile-time. In lisp, if a
field isn't present in a record, you get nil:
(get {:a 1} :b) ;;=> nil
but this is only decidable at runtime. So core.spec takes this "tooling"
around typechecking and exposes it to the user so they could do program
analysis (like seeing what functions are applicable, etc) at
runtime. Racket's contract system does the same, afaik.
Presumably you could implement a Hindley-Milner type system using
core.spec. That would be cool. E.g. Shen is a lisp with a type system in
which you could implement HM in just a few pages of code.
Not sure if this is helpful, hope you get something out of it.
--
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.
signature.asc
Description: PGP signature
