On 02.03.2009, at 01:50, Rich Hickey wrote:
> I was wondering if you considered using maps or struct-maps for this.
> One of my pet peeves with algebraic data types is the unnamed,
> positional nature of the components/fields. It always bothers me you
> have to rename the fields in every pattern
On Feb 26, 4:06 pm, Konrad Hinsen wrote:
> On 26.02.2009, at 10:00, Konrad Hinsen wrote:
>
> > I know, but as I said, my current implementation is just a proof of
> > concept. It is not viable for production use for a variety of
> > reasons. I was planning to replace it by something based on ge
On 26.02.2009, at 10:00, Konrad Hinsen wrote:
> I know, but as I said, my current implementation is just a proof of
> concept. It is not viable for production use for a variety of
> reasons. I was planning to replace it by something based on gen-class
> and proxy, but I will first try to get away
Thanks for the insight, Konrad. I know this is a sideshow to the larger
discussion on types, but it does present an unexpected usability issue.
On 26 February 2009 at 02:44, Konrad Hinsen wrote:
> The fix is to provide a default implementation for print-method. Try
> executing this:
>
> (def
On Feb 25, 6:51 pm, Rich Hickey wrote:
> user=> (type #^{:type ::Fred} [1 2 3])
> :user/Fred
This is extremely appealing, as David said, for those of us building
type systems for our application data.
There's one wart for my particular use:
(binding [*print-dup* true]
(prn-str #^{:
2009/2/26 Rich Hickey
>
>
>
> On Feb 26, 8:30 am, Laurent PETIT wrote:
> > 2009/2/26 Rich Hickey
> >
> >
> >
> >
> >
> > > On Feb 26, 4:17 am, Laurent PETIT wrote:
> > > > 2009/2/26 Konrad Hinsen
> >
> > > > > On 26.02.2009, at 01:51, Rich Hickey wrote:
> >
> > > > > > You raise interesting i
On Feb 26, 8:30 am, Laurent PETIT wrote:
> 2009/2/26 Rich Hickey
>
>
>
>
>
> > On Feb 26, 4:17 am, Laurent PETIT wrote:
> > > 2009/2/26 Konrad Hinsen
>
> > > > On 26.02.2009, at 01:51, Rich Hickey wrote:
>
> > > > > You raise interesting issues and I'd like to explore them further.
> > I'm
>
Would it make sense to make instance?/type-instance?/type .. multimethods
themselves ?
2009/2/26 Konrad Hinsen
>
> On 26.02.2009, at 01:51, Rich Hickey wrote:
>
> > You raise interesting issues and I'd like to explore them further. I'm
> > not sure the issues you have with type-tag-or-class disp
2009/2/26 Rich Hickey
>
>
>
> On Feb 26, 4:17 am, Laurent PETIT wrote:
> > 2009/2/26 Konrad Hinsen
> >
> >
> >
> >
> >
> > > On 26.02.2009, at 01:51, Rich Hickey wrote:
> >
> > > > You raise interesting issues and I'd like to explore them further.
> I'm
> > > > not sure the issues you have with
On Feb 26, 6:19 am, Konrad Hinsen wrote:
> On Feb 26, 2009, at 1:51, Rich Hickey wrote:
>
> > You raise interesting issues and I'd like to explore them further. I'm
> > not sure the issues you have with type-tag-or-class dispatch are all
> > that prohibitive. In any case, I've added a type func
On Feb 26, 4:17 am, Laurent PETIT wrote:
> 2009/2/26 Konrad Hinsen
>
>
>
>
>
> > On 26.02.2009, at 01:51, Rich Hickey wrote:
>
> > > You raise interesting issues and I'd like to explore them further. I'm
> > > not sure the issues you have with type-tag-or-class dispatch are all
> > > that proh
On Feb 26, 4:00 am, Konrad Hinsen wrote:
> On 26.02.2009, at 01:51, Rich Hickey wrote:
>
> > You raise interesting issues and I'd like to explore them further. I'm
> > not sure the issues you have with type-tag-or-class dispatch are all
> > that prohibitive. In any case, I've added a type funct
On Feb 26, 2009, at 1:51, Rich Hickey wrote:
> You raise interesting issues and I'd like to explore them further. I'm
> not sure the issues you have with type-tag-or-class dispatch are all
> that prohibitive. In any case, I've added a type function that returns
> the :type metadata or the class i
2009/2/26 Konrad Hinsen
>
> On 26.02.2009, at 01:51, Rich Hickey wrote:
>
> > You raise interesting issues and I'd like to explore them further. I'm
> > not sure the issues you have with type-tag-or-class dispatch are all
> > that prohibitive. In any case, I've added a type function that returns
On 26.02.2009, at 01:51, Rich Hickey wrote:
> You raise interesting issues and I'd like to explore them further. I'm
> not sure the issues you have with type-tag-or-class dispatch are all
> that prohibitive. In any case, I've added a type function that returns
> the :type metadata or the class if
On 26.02.2009, at 08:47, Jeff Valk wrote:
> String representation obviously uses :type now in a very particular
> way. I'm not sure where this happens though. Can anyone shed some
> light on the details?
print-method now dispatches on type, rather than class as it did
before. There is no d
On 25 February 2009, Adrian Cuthbertson wrote:
>
> Hmm, I get a stack overflow when trying that make macro.
> After using macroexpand-1...
> (with-meta (struct stuff 1 2) {:type (keyword (str *ns*) (name (quote
> stuff)))})
> I still get the stack overflow.
>
> I'm on svn 1307, jdk 1.5 mac osx
Hmm, I get a stack overflow when trying that make macro.
After using macroexpand-1...
(with-meta (struct stuff 1 2) {:type (keyword (str *ns*) (name (quote stuff)))})
I still get the stack overflow.
I'm on svn 1307, jdk 1.5 mac osx.
Any ideas?
Regards, Adrian.
On Thu, Feb 26, 2009 at 7:08 AM, J
How about appending type metadata automagically...
(defstruct stuff :a :b)
(defmacro make
"Creates a new instance of struct t and appends 'type' t as metadata"
[t & vs]
`(with-meta
(struct ~t ~...@vs)
{:type (keyword (str *ns*) (name '~t))}))
user> (make stuff 1 2)
{:a 1, :b 2}
us
On Wed, Feb 25, 2009 at 10:09 PM, David Nolen wrote:
> This is nothing short of amazing for those who want to build ad-hoc type
> systems.
Plus custom printing.
(defmethod print-method ::Foo [o w]
(doto w
(.write "#")))
(defn make-foo [x]
#^{:type ::Foo} {:x x})
user=> (make-foo "whee
This is nothing short of amazing for those who want to build ad-hoc type
systems.
(defstruct #^{:type ::my-struct} my-struct :a :b)
(type #'my-struct) ; -> :user/my-struct!
I have a lot of code fixing to do now :)
Also Konrad's point that using multimethods for dispatch-fns would be ugly,
but act
On Feb 25, 12:19 pm, Konrad Hinsen wrote:
> On Feb 25, 2009, at 17:40, David Nolen wrote:
>
> > Should print and println be multimethods? It seems the ability to
> > custom print a data structure would be generally useful.
>
> It's already there, just not documented as far as I know. All the
>
On Feb 25, 9:26 am, Konrad Hinsen wrote:
> I have just added a new library to clojure.contrib. It provides a
> proof-of-concept implementation of algebraic data types. An example
> for what you can do with it:
>
> (deftype tree
> empty-tree
> (leaf value)
> (node left-tree right-tr
On Feb 25, 2009, at 17:40, David Nolen wrote:
> Should print and println be multimethods? It seems the ability to
> custom print a data structure would be generally useful.
It's already there, just not documented as far as I know. All the
printing routines end up calling clojure.core/print-m
>
> 1) User-friendly printing.
>
> I implement the multimethods print-method and print-dup for my
> classes, which allows me to specify how objects are printed. print-
> method and print-dup dispatch on class, so my types need to be
> classes or at least derive from a class that is distinct from th
On Feb 25, 2009, at 16:32, Jeffrey Straszheim wrote:
> Is there any reason they cannot be implemented as structs with some
> sort of type tag?
I suspect that could be done, but some nice features would be lost:
1) User-friendly printing.
I implement the multimethods print-method and print-du
Is there any reason they cannot be implemented as structs with some sort of
type tag?
On Wed, Feb 25, 2009 at 10:26 AM, Konrad Hinsen
wrote:
>
> I have just added a new library to clojure.contrib. It provides a
> proof-of-concept implementation of algebraic data types. An example
> for what you c
27 matches
Mail list logo
