Re: Many foolish questions
2010/1/15 Rayne disciplera...@gmail.com: Ignore this. ;) deftype and reify and all of that good stuff are now in the Clojure master branch. Rich pulled new into master a few days ago. Ah, good to know :) The last time I checked it was not yet in master. -- Michael Wood esiot...@gmail.com -- 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
Re: Many foolish questions
2010/1/15 Simon Brooke still...@googlemail.com:
OK, I'm trying to get seriously stuck in, and the first thing I'm
trying to do is reimplement an inference engine I first wrote in
Portable Standard Lisp and then in InterLisp-D in /idiomatic/ Clojure.
So please have patience with me...
If one has something which is strongly typed, is it idiomatic to make
a Java class to hold it?
I want a structure like this
(defstruct feature :name :default)
but I want in addition to constrain the binding of :name to be always
a Clojure keyword and the binding of :default to be always a boolean -
the Clojure values either true or false.
I've tried
(defstruct feature [#^Keyword :name] :default)
#^something applies to the thing to the right of it. There's no need
to enclose anything in square brackets. But this won't work here
anyway:
user= (defstruct feature #^Keyword :name :default)
java.lang.IllegalArgumentException: Metadata can only be applied to IMetas
:default
java.lang.Exception: Unmatched delimiter: )
but the reader spits an illegal argument exception. Is there different
syntax which the reader could parse? Or am I using the wrong kind of
thing?
Of course given that a struct is immutable I could have a make-feature
function which has type-hinted args:
(defn
#^{:doc Make a feature safely}
make-feature [#^Keyword name #^bool default]
(struct-map feature :name name :default default))
defn also supports docstrings more directly like this:
(defn make-feature
Make a feature safely
[...]
(struct-map ...))
This works and does sort-of what I want - I can't guarantee that
Does it?
user= (defn
#^{:doc Make a feature safely}
make-feature [#^Keyword name #^bool default]
(struct-map feature :name name :default default))
#'user/make-feature
user= (make-feature some name 42)
{:name some name, :default 42}
nothing outside my make-feature function will make features but I
don't think I need to. However, it feels clunky - I instinctively feel
there must be a better way. Is this what deftype should be used for?
If so, where is it documented? The book I'm using - Stuart Halloway's
'Programming Clojure' - doesn't seem to have it (or if it has I've
missed it). Also, I don't seem to have deftype in my 1.1.0 rc3 build :
cc.journeyman.dtree.dtree= (doc deftype)
java.lang.Exception: Unable to resolve var: deftype in this context
(NO_SOURCE_FILE:20)
I've also grepped the source code of clojure and failed to find it.
It's not in any official release yet. In your git checkout do
something like this to get it:
$ git checkout -b new origin/new
That will create a branch called new based on the new branch in
Rich's repository. Then you can git pull as usual to keep it
updated. If you want to switch back to master, just do git checkout
master.
I've not tried deftype yet, so I don't know if it's what you're looking for.
--
Michael Wood esiot...@gmail.com
--
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
Re: Many foolish questions
Ignore this. ;)
deftype and reify and all of that good stuff are now in the Clojure
master branch. Rich pulled new into master a few days ago.
On Jan 15, 4:09 am, Michael Wood esiot...@gmail.com wrote:
2010/1/15 Simon Brooke still...@googlemail.com:
OK, I'm trying to get seriously stuck in, and the first thing I'm
trying to do is reimplement an inference engine I first wrote in
Portable Standard Lisp and then in InterLisp-D in /idiomatic/ Clojure.
So please have patience with me...
If one has something which is strongly typed, is it idiomatic to make
a Java class to hold it?
I want a structure like this
(defstruct feature :name :default)
but I want in addition to constrain the binding of :name to be always
a Clojure keyword and the binding of :default to be always a boolean -
the Clojure values either true or false.
I've tried
(defstruct feature [#^Keyword :name] :default)
#^something applies to the thing to the right of it. There's no need
to enclose anything in square brackets. But this won't work here
anyway:
user= (defstruct feature #^Keyword :name :default)
java.lang.IllegalArgumentException: Metadata can only be applied to IMetas
:default
java.lang.Exception: Unmatched delimiter: )
but the reader spits an illegal argument exception. Is there different
syntax which the reader could parse? Or am I using the wrong kind of
thing?
Of course given that a struct is immutable I could have a make-feature
function which has type-hinted args:
(defn
#^{:doc Make a feature safely}
make-feature [#^Keyword name #^bool default]
(struct-map feature :name name :default default))
defn also supports docstrings more directly like this:
(defn make-feature
Make a feature safely
[...]
(struct-map ...))
This works and does sort-of what I want - I can't guarantee that
Does it?
user= (defn
#^{:doc Make a feature safely}
make-feature [#^Keyword name #^bool default]
(struct-map feature :name name :default default))
#'user/make-feature
user= (make-feature some name 42)
{:name some name, :default 42}
nothing outside my make-feature function will make features but I
don't think I need to. However, it feels clunky - I instinctively feel
there must be a better way. Is this what deftype should be used for?
If so, where is it documented? The book I'm using - Stuart Halloway's
'Programming Clojure' - doesn't seem to have it (or if it has I've
missed it). Also, I don't seem to have deftype in my 1.1.0 rc3 build :
cc.journeyman.dtree.dtree= (doc deftype)
java.lang.Exception: Unable to resolve var: deftype in this context
(NO_SOURCE_FILE:20)
I've also grepped the source code of clojure and failed to find it.
It's not in any official release yet. In your git checkout do
something like this to get it:
$ git checkout -b new origin/new
That will create a branch called new based on the new branch in
Rich's repository. Then you can git pull as usual to keep it
updated. If you want to switch back to master, just do git checkout
master.
I've not tried deftype yet, so I don't know if it's what you're looking for.
--
Michael Wood esiot...@gmail.com
--
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
Re: Many foolish questions
but the reader spits an illegal argument exception. Is there different syntax which the reader could parse? Or am I using the wrong kind of thing? Wrong kind of thing. defstruct defines a struct-map, which is simply a map with some guaranteed keys. It doesn't make any assertions about the values of those keys. You could (as you did) define a creator function for a map (doesn't have to be a struct-map) that checks the types of its arguments and errors otherwise, but -- as you observed -- generally Clojure is not designed to do this kind of static type checking. It's a dynamic language. The new new work in Rich's non-mainline branches allows much more flexibility in avoiding the need to drop down to Java to achieve this kind of object definition, but that's not in 1.1. You might be interested in this: http://www.assembla.com/wiki/show/clojure/Datatypes -- 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
