Hi Ben, Thanks for answering!
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. Example: Multiple functions manipulate the same datatype, e.g. a map containing name and address etc, and a given function might need only the street address and postal code, and this is usage/context dependent, so you shouldn't have to *hide optionality* by declaring that attributes need to be present but might contain null. In stead you should just leave out the attributes that are not given. So this givenness/or not of attributes becomes an actual signature of the data-types informational status, that can be used to decide e.g. what functions are applicable, what buttons to enable in the UI etc etc. Sorry if I'm missing something here! Regards/Henning On Wed, Apr 24, 2019 at 7:06 PM Ben Sima <b...@bsima.me> wrote: > 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 <henning.von.ro...@gmail.com> 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.
