On Nov 12, 6:10 am, Rich Hickey 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 works with curren
Hi,
On Nov 23, 3:29 pm, Krukow 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
Meikel
--
You rec
On Tue, Nov 24, 2009 at 1:19 AM, Krukow wrote:
>
>
> On Nov 24, 4:55 am, Allen Rohner 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) w
On Nov 24, 4:55 am, Allen Rohner 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 (instance key)
On Nov 12, 6:10 am, Rich Hickey 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 works with curren
On Nov 12, 1:10 pm, Rich Hickey 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 works with curren
On Nov 20, 5:24 pm, Rich Hickey 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 protocols versus int
On Thu, Nov 19, 2009 at 12:39 PM, Krukow wrote:
> On Nov 19, 12:01 am, samppi 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
On Nov 20, 8:51 pm, Chouser wrote:
> On Thu, Nov 19, 2009 at 12:39 PM, Krukow 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 keeps getting worse.
>
> --Ch
On Thu, Nov 19, 2009 at 12:39 PM, Krukow wrote:
> On Nov 19, 12:01 am, samppi 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
On Nov 19, 12:01 am, samppi 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 advantage of Bar
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) an
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.IllegalA
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).
The
On Nov 16, 11:57 am, Jonas Enlund 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
--
You received th
On Mon, Nov 16, 2009 at 6:27 PM, Stuart Sierra
wrote:
> On Nov 14, 8:28 am, Jonas Enlund 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
On Nov 14, 8:28 am, Jonas Enlund 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,
not the number of row
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 wrote:
> On Sun, Nov 15, 2009 at 8:17 PM, David Brown wrote:
> > On Sun,
2009/11/16 John Harrop :
> On Mon, Nov 16, 2009 at 2:16 AM, Michael Wood 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
>>
On Mon, Nov 16, 2009 at 2:16 AM, Michael Wood 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 Dav
2009/11/16 John Harrop :
> On Sun, Nov 15, 2009 at 8:17 PM, David Brown 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. E
On Sun, Nov 15, 2009 at 8:17 PM, David Brown 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 use
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
On Sun, Nov 15, 2009 at 8:45 AM, Michael Wood wrote:
> 2009/11/14 John Harrop :
> > On Sat, Nov 14, 2009 at 1:42 PM, Richard Newman
> 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 o
2009/11/14 John Harrop :
> On Sat, Nov 14, 2009 at 1:42 PM, Richard Newman 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 priva
On Sat, Nov 14, 2009 at 1:42 PM, Richard Newman 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 macros problem:
1
> 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 in
On Nov 14, 8:28 am, Jonas Enlund 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 file.
>
> I have a fe
On Nov 14, 1:32 am, cody koeninger wrote:
> On Nov 13, 9:42 am, Sean Devlin 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"
> > (b
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 whe
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 ...) ins
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
http://www.assembla.com/wiki/show/clojure/
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
> multimeth
On Sat, Nov 14, 2009 at 3:45 AM, Mark Engelberg wrote:
> On Fri, Nov 13, 2009 at 12:58 AM, Konrad Hinsen
> 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 doc
On Fri, Nov 13, 2009 at 12:58 AM, Konrad Hinsen
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 client code can safely r
On Nov 13, 9:42 am, Sean Devlin 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 "baz docs" ([a
On Fri, Nov 13, 2009 at 8:50 PM, Mark Engelberg wrote:
> 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 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 programming
On Nov 13, 3:42 pm, Laurent PETIT 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 problem : doesn't the
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 wrote:
>> On Nov 12, 7:10 am,
On Nov 13, 1:01 pm, Constantine Vetoshev wrote:
> On Nov 12, 7:10 am, Rich Hickey 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 types, rather than making it
> autom
Hi,
2009/11/13 Stuart Sierra :
> On Nov 12, 7:10 am, Rich Hickey 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 nu
On Nov 12, 7:10 am, Rich Hickey 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
defprotocol. It d
On 13 Nov., 17:07, Rich Hickey 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 interface dispatch,
I agree w/ Constantine. This would be very, very useful.
Sean
On Nov 13, 1:01 pm, Constantine Vetoshev wrote:
> On Nov 12, 7:10 am, Rich Hickey wrote:
>
> > [1]http://www.assembla.com/wiki/show/clojure/Datatypes
>
> Could you please elaborate on why you chose to make IPersistentMap an
> option
On 13.11.2009, at 17:11, Rich Hickey wrote:
> On Nov 13, 10:42 am, Sean Devlin 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 & c])
On Nov 12, 7:10 am, Rich Hickey 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 types, rather than making it
automatic?
I'm asking because I found the automatic defstruct-map eq
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 beh
On Nov 13, 9:24 am, James Reeves 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.
>
> (defn sql-get [table ke
Is there an argument for putting it after the argument list? :)
On Fri, Nov 13, 2009 at 11:11 AM, Rich Hickey wrote:
>
>
> On Nov 13, 10:42 am, Sean Devlin wrote:
> > Rich,
> > I was wondering something about defprotocol.
> >
> > Here's your example:
> >
> > (defprotocol AProtocol :on AnInterfa
I place my vote for no data hiding.
On Fri, Nov 13, 2009 at 10:48 AM, Stuart Halloway wrote:
> >> But do
> >> people feel that some degree of data hiding is worthwhile?
> >
> > I don't.
>
>
> Hooray for benevolent dictators!
>
> --
> You received this message because you are subscribed to the G
On Nov 13, 10:48 am, Stuart Halloway
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 Google
Groups "Clo
On Nov 13, 9:26 am, AlexK 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 multifns and protocolfns:
>
...
> This is what I
On Nov 13, 10:42 am, Sean Devlin 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 & c]) "baz docs"))
>
>
>> But do
>> people feel that some degree of data hiding is worthwhile?
>
> I don't.
Hooray for benevolent dictators!
--
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
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 & c]) "baz docs"))
In this case, you provide the docs for each method after para
On Nov 13, 9:03 am, MikeM 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 notice that (extend
On Nov 13, 4:55 am, Alex Osborne 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 p
On Nov 13, 5:27 am, Chris Kent wrote:
> Mark Engelberg 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
> >
On Nov 13, 3:58 am, Konrad Hinsen 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 be an important
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, 2:13 am, Mark Engelberg 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 the strong overla
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.
(defn sql-get [table key]
(sql-query
(str "select * from " table " wher
> (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
On Fri, Nov 13, 2009 at 2:13 AM, Krukow wrote:
>
>
> On Nov 12, 1:10 pm, Rich Hickey 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
Hi,
On Nov 13, 8:13 am, Mark Engelberg 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 time to discuss what kin
Mark Engelberg 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 I think that
On Nov 13, 9:13 am, Krukow 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 dot because the sp
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
> impleme
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] ...)
> Wh
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 defclass/ge
On Nov 12, 1:10 pm, Rich Hickey 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 works with curren
On Thu, Nov 12, 2009 at 7:59 PM, Chouser wrote:
> On Thu, Nov 12, 2009 at 7:10 AM, Rich Hickey 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 usin
On Thu, Nov 12, 2009 at 7:10 AM, Rich Hickey 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.
http://tinyurl.com/yeh5fgg/fi
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 curr
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 wrote:
>> Ri
On Nov 12, 8:29 am, Sean Devlin 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 the "New, awesome wa
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 feature
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,
79 matches
Mail list logo
