On Tue, Nov 24, 2009 at 1:19 AM, Krukow karl.kru...@gmail.com wrote:
On Nov 24, 4:55 am, Allen Rohner aroh...@gmail.com wrote:
The first stumbling point I reached is that deftypes provide an
automatic implementation for IPersistentMap, but not IFn. I attempted
to write (instance key), which
Hi,
On Nov 23, 3:29 pm, Krukow karl.kru...@gmail.com wrote:
Two comments.
First is a bug.
Using newest commit of new: 75cd05080f7260c54007d7728fb280ae53b56f63
Same here:
http://groups.google.com/group/clojure-dev/browse_thread/thread/6d5cf269b18c4540
but no feedback so far. :(
Sincerely
On Nov 12, 6:10 am, Rich Hickey richhic...@gmail.com wrote:
An early version of the code for a few important new language
features, datatypes[1] and protocols[2] is now available in the 'new'
branch[3]. Note also that the build system[4] has builds of the new
branch, and that the new branch
On Thu, Nov 19, 2009 at 12:39 PM, Krukow karl.kru...@gmail.com wrote:
On Nov 19, 12:01 am, samppi rbysam...@gmail.com wrote:
Question: are the general mechanisms for accessing and setting fields
their keywords and assoc respectively:
(deftype Bar [a b c d e])
(def b (Bar 1 2 3 4 5))
On Nov 20, 5:24 pm, Rich Hickey richhic...@gmail.com wrote:
Yup. The fixed field access to deftypes via keyword literal lookup is
the fastest offered by any Clojure data structure.
Rich
While we are talking performance. Is there a simple way to explain the
performance characteristics of
On Nov 12, 1:10 pm, Rich Hickey richhic...@gmail.com wrote:
An early version of the code for a few important new language
features, datatypes[1] and protocols[2] is now available in the 'new'
branch[3]. Note also that the build system[4] has builds of the new
branch, and that the new branch
On Nov 12, 6:10 am, Rich Hickey richhic...@gmail.com wrote:
An early version of the code for a few important new language
features, datatypes[1] and protocols[2] is now available in the 'new'
branch[3]. Note also that the build system[4] has builds of the new
branch, and that the new branch
On Nov 24, 4:55 am, Allen Rohner aroh...@gmail.com wrote:
The first stumbling point I reached is that deftypes provide an
automatic implementation for IPersistentMap, but not IFn. I attempted
to write (instance key), which exploded, but (key instance) works just
fine. My existing code uses
On Thu, Nov 19, 2009 at 12:39 PM, Krukow karl.kru...@gmail.com wrote:
On Nov 19, 12:01 am, samppi rbysam...@gmail.com wrote:
Question: are the general mechanisms for accessing and setting fields
their keywords and assoc respectively:
(deftype Bar [a b c d e])
(def b (Bar 1 2 3 4 5))
On Nov 20, 8:51 pm, Chouser chou...@gmail.com wrote:
On Thu, Nov 19, 2009 at 12:39 PM, Krukow karl.kru...@gmail.com wrote:
[snip]
I guess I am just asking if the performance guarantees are those I
would expect of Clojure (i.e., too fast ;-))
This is definitely still too fast. In fact, it
On Nov 19, 12:01 am, samppi rbysam...@gmail.com wrote:
Question: are the general mechanisms for accessing and setting fields
their keywords and assoc respectively:
(deftype Bar [a b c d e])
(def b (Bar 1 2 3 4 5))
(:c b)
(def c (assoc b :e 2))
Does (:c b) and (assoc b :e 2) take
This is wonderful, wonderful, wonderful. It makes my work with FnParse
so much easier.
Question: are the general mechanisms for accessing and setting fields
their keywords and assoc respectively:
(deftype Bar [a b c d e])
(def b (Bar 1 2 3 4 5))
(:c b)
(def c (assoc b :e 2))
Does (:c b)
On Nov 16, 11:57 am, Jonas Enlund jonas.enl...@gmail.com wrote:
I made count return the number of rows because that way (count
a-matrix) == (count (seq a-matrix)). I don't know if it's the right
thing to do, maybe rows*cols would make more sense.
Good point. I don't know which is better.
-SS
A quick aside about matrices. Every dense matrix algorithm is
measured by the number of rows (n). LU factorization is O(n^3), as is
QR. If memory serves, Eigenvalues are usually O(n^2). Determinants
are O(n^3), too. These estimates change if the matrix is banded, they
usually become O(n).
can anyone explain why this doesn't work?
(defprotocol arrow
( ([f g] [f g fs]) compose left to right))
(extend clojure.lang.Fn
arrow
{: (fn
([f g] #(g (f %)))
([f g fs] (apply ( f g) fs)))})
( inc inc inc)
; gives this error:
; java.lang.IllegalArgumentException:
On Mon, Nov 16, 2009 at 2:16 AM, Michael Wood esiot...@gmail.com wrote:
This is what I get with or without rlwrap from the command line. No
IDE or anything like that:
Clojure 1.1.0-alpha-SNAPSHOT
user= ; some comment
user= #! something
(println blah)
blah
nil
user=
i.e. the same as
2009/11/16 John Harrop jharrop...@gmail.com:
On Mon, Nov 16, 2009 at 2:16 AM, Michael Wood esiot...@gmail.com wrote:
This is what I get with or without rlwrap from the command line. No
IDE or anything like that:
Clojure 1.1.0-alpha-SNAPSHOT
user= ; some comment
user= #! something
Enclojure users:
I was able to confirm John's problem in Enclojure. I found a work
around. Read more here:
http://groups.google.com/group/enclojure/browse_thread/thread/6bddd3153ece02f2
On Nov 16, 12:12 am, John Harrop jharrop...@gmail.com wrote:
On Sun, Nov 15, 2009 at 8:17 PM, David Brown
On Nov 14, 8:28 am, Jonas Enlund jonas.enl...@gmail.com wrote:
I have built a simple Matrix datatype with defprotocol and deftype.
You can take a look at it athttp://gist.github.com/234535
(constructive criticism welcome!).
Small thing: I would expect (count a-matrix) to return rows*columns,
On Mon, Nov 16, 2009 at 6:27 PM, Stuart Sierra
the.stuart.sie...@gmail.com wrote:
On Nov 14, 8:28 am, Jonas Enlund jonas.enl...@gmail.com wrote:
I have built a simple Matrix datatype with defprotocol and deftype.
You can take a look at it athttp://gist.github.com/234535
(constructive criticism
2009/11/14 John Harrop jharrop...@gmail.com:
On Sat, Nov 14, 2009 at 1:42 PM, Richard Newman holyg...@gmail.com wrote:
I like CL's package support for this kind of situation, where
unexported symbols can still be reached via foo::bar, at the cost of
an obvious code smell.
This suggests an
On Sun, Nov 15, 2009 at 8:45 AM, Michael Wood esiot...@gmail.com wrote:
2009/11/14 John Harrop jharrop...@gmail.com:
On Sat, Nov 14, 2009 at 1:42 PM, Richard Newman holyg...@gmail.com
wrote:
I like CL's package support for this kind of situation, where
unexported symbols can still be
On Sun, Nov 15, 2009 at 04:20:19PM -0500, John Harrop wrote:
That's weird. It's not documented anywhere on the site. And it seems to hang
the REPL:
user= nil #!foo
and nothing. Enter doesn't print nil and a fresh user= prompt as it
should and nothing else apparently works either. The REPL is
On Sun, Nov 15, 2009 at 8:17 PM, David Brown cloj...@davidb.org wrote:
On Sun, Nov 15, 2009 at 04:20:19PM -0500, John Harrop wrote:
That's weird. It's not documented anywhere on the site. And it seems to
hang
the REPL:
user= nil #!foo
and nothing. Enter doesn't print nil and a fresh
2009/11/16 John Harrop jharrop...@gmail.com:
On Sun, Nov 15, 2009 at 8:17 PM, David Brown cloj...@davidb.org wrote:
On Sun, Nov 15, 2009 at 04:20:19PM -0500, John Harrop wrote:
That's weird. It's not documented anywhere on the site. And it seems to
hang
the REPL:
user= nil #!foo
and
On Fri, Nov 13, 2009 at 12:58 AM, Konrad Hinsen
konrad.hin...@fastmail.net wrote:
Coming from a Python background, I don't think access restrictions are
necessary. However, flagging fields as not meant for use by
outsiders could be of interest for documentation tools, to make it
clear what
On Sat, Nov 14, 2009 at 3:45 AM, Mark Engelberg mark.engelb...@gmail.comwrote:
On Fri, Nov 13, 2009 at 12:58 AM, Konrad Hinsen
konrad.hin...@fastmail.net wrote:
Coming from a Python background, I don't think access restrictions are
necessary. However, flagging fields as not meant for use by
On 13 Nov 2009, at 23:03, Stuart Sierra wrote:
This example has maybe a problem : doesn't the symmetry of these
Arithmetic operators seems to be crying for type multiple dispatch in
this particular case ? :-)
Yes, in the general case, arithmetic requires multimethods. But
multimethods --
On 14 Nov 2009, at 02:50, Mark Engelberg wrote:
together. So would it make sense for multimethods to be included as
part of protocols, or should there be some similar grouping system for
multimethods?
The old ideas/scratchpad section of
Hi there!
I have built a simple Matrix datatype with defprotocol and deftype.
You can take a look at it at http://gist.github.com/234535
(constructive criticism welcome!). Some simple examples are provided
at the end of the file.
I have a few questions.
- Why must i write (matrix/Matrix ...)
On 14 Nov 2009, at 09:45, Mark Engelberg wrote:
In general, I really hate it when it's difficult to tell what parts of
an API are the things that the end-user is really supposed to call,
and what part of the data you're supposed to access directly versus an
accessor method. It bugs me when I
On Nov 14, 8:28 am, Jonas Enlund jonas.enl...@gmail.com wrote:
Hi there!
I have built a simple Matrix datatype with defprotocol and deftype.
You can take a look at it athttp://gist.github.com/234535
(constructive criticism welcome!). Some simple examples are provided
at the end of the
On Nov 14, 1:32 am, cody koeninger c...@koeninger.org wrote:
On Nov 13, 9:42 am, Sean Devlin francoisdev...@gmail.com wrote:
In this case, you provide the docs for each method after parameters.
Would the following be possible:
(defprotocol AProtocol :on AnInterface
A doc string for
I don't really care how strictly the language *enforces* that
separation, but I think the ability to specify that separation is a
good thing.
I'd go so far as to request that it does not enforce separation. I'm
sure anyone who's spent enough time using Other People's Libraries has
hit
On Sat, Nov 14, 2009 at 1:42 PM, Richard Newman holyg...@gmail.com wrote:
I like CL's package support for this kind of situation, where
unexported symbols can still be reached via foo::bar, at the cost of
an obvious code smell.
This suggests an alternate fix for the private functions in
On 13 Nov 2009, at 08:13, Mark Engelberg wrote:
Is there a way to customize the way that types defined by deftype
print in the REPL?
Implement the multimethod clojure.core/print-method for the associated
type tag:
(deftype Foo ...)
(defmethod clojure.core/print-method ::Foo [x] ...)
Mark Engelberg wrote:
Protocols:
I don't understand whether there's any way to provide a partial
implementation or default implementation of a given
protocol/interface, and I believe this to be an important issue.
For example, a protocol for and that provides a default
implementation
On Nov 13, 9:13 am, Krukow karl.kru...@gmail.com wrote:
I was thinking this may make syntax irregular. I suspect this is a
deliberate design choice to distinguish clojure protocols from java
interfaces? Is this the case?
As far as I understand it, in defprotocol's case, I suspect there is
no
Mark Engelberg mark.engelberg at gmail.com writes:
I'm a little worried about the strong overlap between reify/proxy,
deftype/defstruct, and defclass/gen-class. I can just imagine the
questions a year from now when people join the Clojure community and
want to understand how they differ. So
Hi,
On Nov 13, 8:13 am, Mark Engelberg mark.engelb...@gmail.com wrote:
Is there a way to customize the way that types defined by deftype
print in the REPL?
One can add a method to print-method for the type.
While these datatype and protocol constructs are taking shape, maybe
now is the
(deftype Foo [a b c])
(defprotocol P (bar [x] bar docs))
(extend ::Foo P {:bar (fn [afoo] :foo-thing)})
A common error may be to:
(extend Foo P {:bar (fn [afoo] :foo-thing)})
when (extend ::Foo ... is intended. I notice that (extend Foo...
doesn't throw - should extend check that it is
On Nov 13, 2:13 am, Mark Engelberg mark.engelb...@gmail.com wrote:
I'm still trying to get my head around the new features. Seeing more
code examples will definitely help. In the meantime, here is some
stream-of-consciousness thoughts and questions.
Datatypes:
I'm a little worried about
Hi everybody,
after playing around with protocols datatypes, I found them very fun
to use.
Some questions:
Performance
I don't see (with my limited benchmarking) any significant difference
between multifns and protocolfns:
user= (defprotocol Test (protocol-fn [it] Protocol-fn))
Test
user=
On Nov 13, 3:58 am, Konrad Hinsen konrad.hin...@fastmail.net wrote:
On 13 Nov 2009, at 08:13, Mark Engelberg wrote:
Protocols:
I don't understand whether there's any way to provide a partial
implementation or default implementation of a given
protocol/interface, and I believe this to
On Nov 13, 9:03 am, MikeM michael.messini...@invista.com wrote:
(deftype Foo [a b c])
(defprotocol P (bar [x] bar docs))
(extend ::Foo P {:bar (fn [afoo] :foo-thing)})
A common error may be to:
(extend Foo P {:bar (fn [afoo] :foo-thing)})
when (extend ::Foo ... is intended. I
On Nov 13, 4:55 am, Alex Osborne a...@meshy.org wrote:
Mark Engelberg wrote:
Protocols:
I don't understand whether there's any way to provide a partial
implementation or default implementation of a given
protocol/interface, and I believe this to be an important issue.
For example, a
On Nov 13, 5:27 am, Chris Kent cjk...@gmail.com wrote:
Mark Engelberg mark.engelberg at gmail.com writes:
I'm a little worried about the strong overlap between reify/proxy,
deftype/defstruct, and defclass/gen-class. I can just imagine the
questions a year from now when people join the
Rich,
I was wondering something about defprotocol.
Here's your example:
(defprotocol AProtocol :on AnInterface
A doc string for AProtocol abstraction
(bar [a b] bar docs :on barMethod)
(baz ([a] [a b] [a b amp; c]) baz docs))
In this case, you provide the docs for each method after
On Nov 13, 10:42 am, Sean Devlin francoisdev...@gmail.com wrote:
Rich,
I was wondering something about defprotocol.
Here's your example:
(defprotocol AProtocol :on AnInterface
A doc string for AProtocol abstraction
(bar [a b] bar docs :on barMethod)
(baz ([a] [a b] [a b amp; c])
On Nov 13, 9:26 am, AlexK alexander.konstanti...@informatik.haw-
hamburg.de wrote:
Hi everybody,
after playing around with protocols datatypes, I found them very fun
to use.
Some questions:
Performance
I don't see (with my limited benchmarking) any significant difference
between
On Nov 13, 10:48 am, Stuart Halloway stuart.hallo...@gmail.com
wrote:
But do
people feel that some degree of data hiding is worthwhile?
I don't.
Hooray for benevolent dictators!
I was just putting in my vote :)
Rich
--
You received this message because you are subscribed to the
Is there an argument for putting it after the argument list? :)
On Fri, Nov 13, 2009 at 11:11 AM, Rich Hickey richhic...@gmail.com wrote:
On Nov 13, 10:42 am, Sean Devlin francoisdev...@gmail.com wrote:
Rich,
I was wondering something about defprotocol.
Here's your example:
On Nov 13, 9:24 am, James Reeves weavejes...@googlemail.com wrote:
Are there any plans to use protocols to define polymorphic functions
like conj and get? Perhaps with an untype function to remove type
metadata so one could always get at the datastructures hidden by the
protocol. e.g.
On 13.11.2009, at 17:07, Rich Hickey wrote:
Admittedly, it is a difference from multimethods. With protocols, both
protocols and their functions/methods are immutable. Redefining or
extending a protocol modifies only the protocol and fn vars. I prefer
that, and don't consider the above
On 13.11.2009, at 17:11, Rich Hickey wrote:
On Nov 13, 10:42 am, Sean Devlin francoisdev...@gmail.com wrote:
Would the following be possible:
(defprotocol AProtocol :on AnInterface
A doc string for AProtocol abstraction
(bar bar docs [a b] :on barMethod)
(baz baz docs ([a] [a b] [a b
I agree w/ Constantine. This would be very, very useful.
Sean
On Nov 13, 1:01 pm, Constantine Vetoshev gepar...@gmail.com wrote:
On Nov 12, 7:10 am, Rich Hickey richhic...@gmail.com wrote:
[1]http://www.assembla.com/wiki/show/clojure/Datatypes
Could you please elaborate on why you chose
On 13 Nov., 17:07, Rich Hickey richhic...@gmail.com wrote:
This kind of do-nothing microbenchmarking demonstrates nothing.
Protocol dispatching is significantly faster than multimethod
dispatching, and I haven't even looked into call-site optimization.
Protocol dispatch is not as fast as
On Nov 12, 7:10 am, Rich Hickey richhic...@gmail.com wrote:
An early version of the code for a few important new language
features, datatypes[1] and protocols[2]
Very simple example here: http://paste.lisp.org/display/90329
This shows how to do arithmetic with complex numbers using deftype and
Hi,
2009/11/13 Stuart Sierra the.stuart.sie...@gmail.com:
On Nov 12, 7:10 am, Rich Hickey richhic...@gmail.com wrote:
An early version of the code for a few important new language
features, datatypes[1] and protocols[2]
Very simple example here: http://paste.lisp.org/display/90329
This
On Nov 13, 1:01 pm, Constantine Vetoshev gepar...@gmail.com wrote:
On Nov 12, 7:10 am, Rich Hickey richhic...@gmail.com wrote:
[1]http://www.assembla.com/wiki/show/clojure/Datatypes
Could you please elaborate on why you chose to make IPersistentMap an
optional interface for deftype'd
Initial gut reaction: would like a shortcut syntax for opting in(or
out), as this will be a very common use case. Suspect that most
classes would rather have it than not, but that may be the Ruby
programmer in me.
Stu
On Nov 13, 1:01 pm, Constantine Vetoshev gepar...@gmail.com wrote:
On
On Nov 13, 3:42 pm, Laurent PETIT laurent.pe...@gmail.com wrote:
Very simple example here:http://paste.lisp.org/display/90329
Why not have used add/sub/... instead of +/-/... in the extension of
Arithmetic for ::Complex ? :-p
Just a little simpler, that's all.
This example has maybe a
Rich, thanks for the extended explanation of the overlap between the
old and new constructs; I found this explanation much clearer than
what is currently on the wiki. Basically, the key for me was
realizing that these new constructs are all you're likely to need as
long as you are just
On Fri, Nov 13, 2009 at 8:50 PM, Mark Engelberg mark.engelb...@gmail.comwrote:
Rich, thanks for the extended explanation of the overlap between the
old and new constructs; I found this explanation much clearer than
what is currently on the wiki. Basically, the key for me was
realizing that
On Nov 13, 9:42 am, Sean Devlin francoisdev...@gmail.com wrote:
In this case, you provide the docs for each method after parameters.
Would the following be possible:
(defprotocol AProtocol :on AnInterface
A doc string for AProtocol abstraction
(bar bar docs [a b] :on barMethod)
(baz
An early version of the code for a few important new language
features, datatypes[1] and protocols[2] is now available in the 'new'
branch[3]. Note also that the build system[4] has builds of the new
branch, and that the new branch works with current contrib.
If you have the time and inclination,
Rich,
Just read the section on reify. I'm not quite sure what this new
mechanism lets me do. Could you provide an example of the problem it
solves? I personally would benefit from seeing the Old, painful way
contrasted to the New, awesome way. This would probably help with
the other features
On Nov 12, 8:29 am, Sean Devlin francoisdev...@gmail.com wrote:
Rich,
Just read the section on reify. I'm not quite sure what this new
mechanism lets me do. Could you provide an example of the problem it
solves? I personally would benefit from seeing the Old, painful way
contrasted to
Oh its looks like Google Go (http://golang.org) and Nice Interfaces
(http://nice.sourceforge.net/).
Good! It sounds better than overrated polyphormism and class hierarchy.
Wiadomość napisana przez Rich Hickey w dniu 2009-11-12, o godz. 15:39:
On Nov 12, 8:29 am, Sean Devlin
Hi,
Am 12.11.2009 um 13:10 schrieb Rich Hickey:
An early version of the code for a few important new language
features, datatypes[1] and protocols[2] is now available in the 'new'
branch[3]. Note also that the build system[4] has builds of the new
branch, and that the new branch works with
On Thu, Nov 12, 2009 at 7:10 AM, Rich Hickey richhic...@gmail.com wrote:
If you have the time and inclination, please try them out. Feedback is
particularly welcome as they are being refined.
For what it's worth, here are 2-3 finger trees implemented using
defprotocol and deftype.
On Thu, Nov 12, 2009 at 7:59 PM, Chouser chou...@gmail.com wrote:
On Thu, Nov 12, 2009 at 7:10 AM, Rich Hickey richhic...@gmail.com wrote:
If you have the time and inclination, please try them out. Feedback is
particularly welcome as they are being refined.
For what it's worth, here are 2-3
On Nov 12, 1:10 pm, Rich Hickey richhic...@gmail.com wrote:
An early version of the code for a few important new language
features, datatypes[1] and protocols[2] is now available in the 'new'
branch[3]. Note also that the build system[4] has builds of the new
branch, and that the new branch
I'm still trying to get my head around the new features. Seeing more
code examples will definitely help. In the meantime, here is some
stream-of-consciousness thoughts and questions.
Datatypes:
I'm a little worried about the strong overlap between reify/proxy,
deftype/defstruct, and
74 matches
Mail list logo
