http://lispnyc.org/soc2009.clp
Forget most of what I said, it seems the BDFL already has these things in mind ;) Enough of types and structs for me, time for me dive into the less familiar territory of Clojure. On Thu, Jan 22, 2009 at 12:25 PM, David Nolen <dnolen.li...@gmail.com>wrote: > Can't some elements of the problem be solved with some form of predicate > dispatching as proposed by Meikel? Predicate dispatching would allows us to > use _anything_ as a type (i.e. structs themselves), as well as allowing user > defined functions to do the matching instead of being limited to isa? and > the global hierarchy. This of course has some performance implications I > imagine... > > http://groups.google.com/group/clojure/browse_thread/thread/f8b1be403c927b03/438c21a80072a105?lnk=gst&q=hierarchy#438c21a80072a105 > > I have to say that I find the lack of a type system around structs to be > fairly liberating. You can invent one if you need one, but you are not > constrained by it. However, if somebody comes up with something like CLJOS > as a set of handy macros, or extracts whatever parts they deem relevant, why > not put that in clojure-contrib so that people can at least have something > to use for the simple cases as pointed out by Konrad? > > > On Thu, Jan 22, 2009 at 10:25 AM, Konrad Hinsen <konrad.hin...@laposte.net > > wrote: > >> >> On 22.01.2009, at 15:26, Rich Hickey wrote: >> >> > It's pretty easy to write a trivial struct system, much harder to >> > address performance, interop, compilability, dynamicity etc >> > constraints. >> >> Indeed. >> >> > As a simple case, if a defstruct is re-evaluated, will objects created >> > after that be of the same 'type' as objects created before? >> >> I'd say no, which resolves the next question: >> >> > What if fields have been added/removed? >> >> Anyway, I don't think that re-evaluation is a serious issue, except >> in interactive development sessions. The typical use would be >> defining a struct once and then not touch it any more. >> >> > I'd prefer people experiment with libraries built on the existing >> > facilities, with an open mind as to the possibilities of categorizing >> > things other than by their structure. >> >> The added flexibility of multimethods is quite appreciable in non- >> trivial situations. But at the moment there is no simple way to >> handle simple situations. Using structs is straightforward and >> familiar from other languages. It is certainly not *the* solution to >> categorizing, but it's a simple one that is good enough for many >> applications. >> >> Konrad. >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
