Re: Blogging About Clojure?

[David Nolen]

Lots of possibilities, but a simple solution is that you could find a
hosting service that supports easy WordPress setup  and pick a minimal theme
that's to your liking.
David

On Tue, Dec 16, 2008 at 1:05 PM, Randall R Schulz  wrote:

>
> Hi,
>
> Wordy though I am, I've never done any blogging before, but now that I'm
> finally beginning to get up-to-speed on Clojure, I think I might have
> some things to say.
>
> So I was wondering if anyone could recommend a good blog site for this
> purpose? Naturally, I'll want to include source code, so it should be
> able to present that easily and cleanly. Apart from that, I don't think
> I need much in the way of fanciness. I'd prefer a site whose
> presentation is clean and uncluttered.
>
> Does anyone have any recommendations?
>
>
> Randall Schulz
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: A quasiquote for Clojure?

[David Nolen]

You can have unresolved symbols within a macro with:
~'symbol

David

On Wed, Dec 17, 2008 at 3:30 AM, Meikel Brandmeyer  wrote:

>
> Hi,
>
> I'd like to propose/put up for discussion a change to the unquote
> handling.
> I basically ran into the following problem:
>
> I'd like to embed a DSL into my system. Using macros it should be
> possible
> to define a language, which looks like usual Clojure. Simply quote the
> form
> and pass it to a function, which knows how to handle the commands.
>
> However I hit a roadblock. Coming from Scheme, I tried the following
> approach.
>
> A hypothetical SQL embedding:
>
> (def x 5)
> (sql col1 from table1 where col2 = ~x)
>
> Or a hypothetical cljsh (inspired by scsh):
>
> (def *cmd* "/usr/bin/command")
> (run (~*cmd* -option 1 -another argument foo bar))
>
> In Scheme this is done, by quoting the macros argument using the
> quasiquote form. In Clojure, however, this style is not possible since
> we are
> missing quasiquote. Here a short list of examples on how the different
> quotations work:
>
> (quote (foo ~x bar))
> => Failure in Clojure.
> => In some Schemes: (foo (unquote x) bar), where , (aka. ~) translates
>   to some unquote form. It just quotes everything. Also the unquote.
>
> (quasiquote (foo ~x bar))
> => Not available in Clojure.
> => (foo 5 bar) in Scheme
>
> (syntax-quote (foo ~x bar))
> => (assuming ` would have a syntax-quote form as ' does with quote)
>   (my.ns/foo 5 maybe.some.other.ns/bar)
> => Not available in Scheme, AFAIK.
>
> So as you see, the above style is not possible, since in Clojure you
> only
> have the choice to be static or resolve all the symbols. If I want to
> use
> the style anyway, I have to jump through hoops and rewrite the quoted
> form in my handler function, be it replacing somehow marked or named
> symbols with values from the environment or be it renormalising all
> the
> symbols. (But what if the user injected a qualified symbol with ~?)
>
> So I came to the question of whether it is possible to include a
> similar
> quasiquote form, which does not resolve the symbols inside? It would
> be a philosophy of "Unquote, what the user wants to be unquoted, and
> leave the rest to me. I know how to handle it."
>
> And when were are at it: maybe also provide a syntax-quote, unquote
> and unquote-splice forms?
>
> Finally, I skipped the obvious question: Does this make sense at all?
> I like this way of including a sub-language. However, is it
> "idiomatic"?
> (for some definition of "idiomatic")
>
> Maybe there is already a different solution, which I just don't see at
> the moment.
>
> Sincerely
> Meikel
>
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Blogging About Clojure?

[David Nolen]

For syntax highlighting in WordPress this is a good
solution.
 It was originally written to be used for the EmacsBlog so it should handle
Clojure just fine.
David

On Fri, Dec 19, 2008 at 7:09 PM, Jason  wrote:

>
> Hi Randall,
>
> I'm in the same boat: I just set up my first blog yesterday so I could
> post some gotchas i've found and experiments i've done with clojure.
> I went the route David suggests: dreamhost.com has a special now, $10
> for a domain and 6 months free hosting, and they have a one-click
> wordpress install.  I'm not sure how best to post code, but for now
> simple  seems to work OK.
>
> -Jason
>
> On Dec 16, 11:05 am, Randall R Schulz  wrote:
> > Hi,
> >
> > Wordy though I am, I've never done any blogging before, but now that I'm
> > finally beginning to get up-to-speed on Clojure, I think I might have
> > some things to say.
> >
> > So I was wondering if anyone could recommend a good blog site for this
> > purpose? Naturally, I'll want to include source code, so it should be
> > able to present that easily and cleanly. Apart from that, I don't think
> > I need much in the way of fanciness. I'd prefer a site whose
> > presentation is clean and uncluttered.
> >
> > Does anyone have any recommendations?
> >
> > Randall Schulz
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: clojure and clojure-contrib github projects updated

[David Nolen]

Thanks!

On Sat, Dec 27, 2008 at 2:01 PM, Kevin O'Neill  wrote:

> Hi all,
> I've updated the github svn clones to pull from google code. I've also
> pushed the 20081217 branch so it's now accessible from git.
>
> Any problems please let me know.
>
> -k.
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Fibonacci sequence

[David Nolen]

>
> (defn fib-helper [a b]
>  (fib-helper b (+ a b)))
>
> (defn fib (fib-helper 0 1)) ; This doesn't work either: (defn fib (fib-
> helper '(0 1)))


You're missing your argument list for fib.


> (println (take 5 fib))


take creates a lazy list from a collection:

(take n collection)

Your fib does not produce a collection.

David

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: why two list comprehensions are different?

[David Nolen]

>
> Yes, but I think maybe there is a bug in Clojure that causes the first
> case to "work" when it should give a syntax error.  If it is not a bug
> I do not understand why it ignores the expression.
>

It's not a "bug" in Clojure because Clojure doesn't really have syntax in
the way that you seem to be referring to, and I assume that you mean this in
the sense that Python has list comprehensions as a syntactical feature of
the language.  A list comprehension in Clojure is just a macro not any part
of the "core" language so to speak.  Much of Clojure is like this.

The macro could do some sort of syntactical checking.  But in this case it
doesn't really seem like it's worth it.  You could of course re-implement
your own version of list comprehension that does incorporate this.  Unlike
Python where this is probably not realistic (you can't easily implement new
Python syntax for yourself), Clojure being a Lisp makes this quite easy.

David

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: newbie question!!

[David Nolen]

(:name @(first (:friends @bill)))

You need to dereference before trying to access name.

David
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: is it type hint?

[David Nolen]

Just made sense to me today as well.
#^Class

is short form for saying set the metadata for the symbol being defined (in
this case list) to the map {:tag Class}.

#^ is a reader macro for setting metadata for the compiler.  That code is
simple tagging the symbol clojure/list.

(meta #'list)

will give you the map representing the metadata.  :tag is used by the
compiler, but it's not clear to me in what cases...

On Fri, Jan 16, 2009 at 9:46 PM, wubbie  wrote:

>
> Hi,
>
> is #^ type hint below? I don't see any type at all.
> It's from clojure core.
>
>
> (def
>  #^{:arglists '([& items])
>:doc "Creates a new list containing the items."}
>  list (. clojure.lang.PersistentList creator))
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Inheritance & multiple inheritance using structs

[David Nolen]

After a couple of days of hacking it's clear that Clojure can support OO
structures really, really, well.  I've whipped up a little thing, jokingly
called CLJOS.  I'm curious to know what people think.  It's a fairly simple
affair combining structs, hierarchies, and some helper functions.
It's my first attempt at Clojure programming so I'm sure it could use some
cleanup, but it works.  Of course open to any thoughts improvements etc.  In
particular I'm using refs to deal with changes to the hierarchy and the
class initializers.

You can compose structs, here's a very nonsensical example:

;; multiple inheritance
(defclass beaver [object]
  (:tail true))
(defclass duck [object]
  (:bill true))
(defclass platypus [beaver duck]
  (:marsupial true))

(def aplatypus (make-instance platypus))
(isaa? aplatypus ::duck) ;; yield true
(isaa? aplatypus ::beaver) ;; yields true

isaa? takes an instance and matches it against a fully namespaced keyword.

It supports default values for keys, they are overridden according to the
class hierarchy.

(defclass shape [object]
  (:position [0 0]))

(defclass circle [shape]
  (:radius 10))

(make-instance circle :raduis 20]) ;; creates struct -> {:position [0 0],
:tag :cljos-example/circle, :radius 20}

And it support a simple system for calling multimethods up the inheritance
chain simply by re-assigning the :tag.

(defmulti area :tag)

(defmethod area ::shape [s]
  (print "Abstract method!\n"))

(defmethod area ::rect [r]
  (print "Area of rect\n")
  (area (super r))
  (* (:width r) (:height r)))

http://github.com/swannodette/clojure-stuff/blob/d5df8ad710fdb139d78b95a41ab914c30db53d6d/cljos.clj

Of course it blows my mind that this can be done in less than 100 lines of
code (Clojure is amazing!). It seems to me a decent way to deal with OO
style coding if you want to stick with pure clojure and don't need the Java
interop of gen-class.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Inheritance & multiple inheritance using structs

[David Nolen]

Of course it might be the case that not many people are interested in the
implementing ideas from CLOS for Clojure especially since there's a lot of
exciting new functional ground to cover in Clojure first ;)  I come from a
UI background so I'm interested in the OO implications/possiblities of
Clojure.
In any case a couple half-thought out notes about make-instance performance
characteristics:
make-instance is about as fast as struct-map even tho it dynamically looks
up key initializers (make sense since it's just a macro that unfolds into a
struct-map).

On a new MBP 2.4ghz you can allocate 1,000,000 instances (3 fields) in
~700ms.  Same for struct-map.  struct is a little less than 4 times faster
it seems that struct-map. One possible optimization for make-instance would
be to make make-instance automatically order all keys (seems like a bit of
work especially with multiple inheritance).  As a comparison using a
hash-map directly gives another 3-4x performance increase.

As a comparison of other implementations (probably not a fair one since CLOS
does way more bookkeeping than my measly hack ;):

SBCL instantiates 1,000,000 instances of a class with 3 fields in ~70ms
(could get closer to ~250ms in Clojure with auto-ordering of keys, if the
sorting algorithm was quick enough).
Clozure CL 64 does the same in ~1.5secs.

Cool stuff.  Clojure is zippy.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: A couple of questions concerning syntax-quote

[David Nolen]

The multiple syntax-quote and unqote behavior above seems to work in Clojure
just fine and like CL as well.

On Mon, Jan 19, 2009 at 5:58 AM, Rock  wrote:

>
> I'm trying to make the documentation (still awaiting approval) in the
> "Learning Clojure" WikiBook regarding syntax-quote expansion as
> accurate as possible (like in the CL HyperSpec).
>
> I've recently noticed something. In "The Reader" section of the
> Clojure Reference, where it explains syntax-quotes, it says:
>
> "For all forms other than Symbols, Lists, Vectors and Maps, `x is the
> same as 'x."
>
> Yet, I noticed that for *values* such as numbers, strings etc...
> that's not exactly so. Let's expand a syntax-quote expression like the
> following:
>
> `(x 5) ===> (clojure.core/concat (clojure.core/list (quote user/x))
> (clojure.core/list 5))
>
> See the difference between what happens to the symbol x ===> (quote
> user/x) and what happens to 5?
>
> It looks like `5 gets expanded to 5 and not (quote 5). Now I know that
> they evaluate to the same identical thing. But what I'm interested in,
> is the precise expansion algorithm.
>
> So my first question is:
>
> 1) Is it true that, for values, we have for instance `5 ===> 5 in a
> syntax-quote expansion (not evaluation!).
>
> There's another thing I'm curious about. Syntax-quotes are there to
> simplify such things as wiriting macros (especially) for us. Now I'm
> trying to be rigorous in the docs so that everything is clear. But the
> whole reason for syntax-quotes is to make life easier, so there's no
> point in someone having to mentally expand those expressions every
> time even if he/she knows the precise rules.
>
> Paul Graham discusses this in Ansi Common Lisp. He also illustrates
> there an equivalent way of expanding backquote expressions which is
> truly useful and possibly less confusing for a human mind especially
> when dealing with notoriously difficult nested backquotes (or syntax-
> quotes in our own terminology :-) ). I think it was taken from Scheme,
> but I'm not certain. Anyway it's pretty simple and straightforward. It
> works like this:
>
> "To evaluate a backquoted expression, you remove the backquote
> and each matching comma, and replace the expression following each
> matching
> comma with its value. Evaluating an expression that begins with a
> comma causes an
> error.
>A comma matches a backquote if there are the same number of commas
> as
> backquotes between them, where b is between a and c if a is prepended
> to an expression
> containing b, and b is prepended to an expression containing c. This
> means that in a
> well-formed expression the outermost backquote matches the innermost
> comma(s).
>Suppose that x evaluates to a, which evaluates to 1; and that y
> evaluates to b,
> which evaluates to 2. To evaluate the expression
>
> ``(w ,x ,,y )
>
> we remove the first backquote and evaluate what follows any matching
> comma. The
> rightmost comma is the only one that matches the first backquote. If
> we remove it and
> replace the expression it's prepended to, y, with its value, we get:
>
> `(w ,x ,b)
>
> and if we evaluate that in turn we get:
>
> (w a 2)"
>
> That's Common Lisp notation so mentally replace commas with ~. It took
> me some getting used too! :-)
>
> Now my other question is this:
>
> 2) Given that in Clojure a syntax-quote (`) doesn't just quote a
> *symbol* but *resolves* it in the current context, would the above
> method still be applicable or is it compromised because of this?
> That's something that isn't clear to me yet.
>
> Thanks.
>
> Rock
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: is it type hint?

[David Nolen]

Thanks much.

On Mon, Jan 19, 2009 at 11:03 AM, Michael Reid  wrote:

>
> On Fri, Jan 16, 2009 at 9:57 PM, David Nolen 
> wrote:
> > Just made sense to me today as well.
> > #^Class
> > is short form for saying set the metadata for the symbol being defined
> (in
> > this case list) to the map {:tag Class}.
> > #^ is a reader macro for setting metadata for the compiler.  That code is
> > simple tagging the symbol clojure/list.
> > (meta #'list)
> > will give you the map representing the metadata.  :tag is used by the
> > compiler, but it's not clear to me in what cases...
> >
>
> The most common case where :tag is used by the compiler is to generate
> direct method calls into Java code rather than using reflection to do
> the call, which is much slower, e.g:
>
> (defn index-of [s substr]
>  (.indexOf s substr))
>
> The call to String.indexOf will likely be compiled as a reflective
> call because in the general case, the compiler doesn't know that 's'
> and 'substr' are meant to be instances of java.lang.String. If however
> you add a couple of type hints:
>
>  (defn index-of [#^String s #^String substr]
>   (.indexOf s substr))
>
> Then the compiler will generate an optimized code path that directly
> invokes String.indexOf(String,String), and the other which will fall
> back to the reflective invocation. The reason that two code paths are
> needed is because Clojure is dynamically typed. Therefore it is
> perfectly legal to pass in any type of objects as the parameter in
> which case you want the call to .indexOf to succeed if the passed in
> instance does in fact have a method named indexOf that can accept
> 'substr' as its argument.
>
> To see where the compiler needs to help you can use the
> *warn-on-reflection* flag to ask for warnings where the compiler can't
> resolve the calls. See:
>
>  http://clojure.org/java_interop#toc35
>
> for example usage.
>
> /mike.
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

#^ Reader Macro Issues was Re: function equivalents of macro characters

[David Nolen]

On Mon, Jan 19, 2009 at 12:24 PM, Chouser  wrote:

> > #^ - metadata
>
> #^ adds metadata at read-time, so there's no way for a function to do
> exactly the same thing, though 'with-meta' does something similar at
> runtime.
>

I've noticed this as well.  It seems to me that this prevents you from
dynamically defining a var (like in a macro) that has metadata attached to
it or it's arguments (if it's a function).  Is there no way around how the
reader works?  Can the reader delay processing #^ until after all macros
have been expanded?  Seems to me it could be useful behavior since one might
want to dynamically create functions with tagged arguments and return values
right?

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #^ Reader Macro Issues was Re: function equivalents of macro characters

[David Nolen]

Wow, nice!
On Mon, Jan 19, 2009 at 1:47 PM, Stuart Sierra
wrote:

>
> On Jan 19, 1:15 pm, David Nolen  wrote:
> > I've noticed this as well.  It seems to me that this prevents you from
> > dynamically defining a var (like in a macro) that has metadata attached
> to
> > it or it's arguments (if it's a function).
>
> You can also use the new alter-meta! function, which works on
> anything:
>
> -
> clojure.core/alter-meta!
> ([iref f & args])
>  Atomically sets the metadata for a namespace/var/ref/agent/atom to
> be:
>
>  (apply f its-current-meta args)
>
>  f must be free of side-effects
>
>
> -Stuart Sierra
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #^ Reader Macro Issues was Re: function equivalents of macro characters

[David Nolen]

Actually, so this can't be used on structs for fns?

On Mon, Jan 19, 2009 at 1:47 PM, Stuart Sierra
wrote:

>
> On Jan 19, 1:15 pm, David Nolen  wrote:
> > I've noticed this as well.  It seems to me that this prevents you from
> > dynamically defining a var (like in a macro) that has metadata attached
> to
> > it or it's arguments (if it's a function).
>
> You can also use the new alter-meta! function, which works on
> anything:
>
> -
> clojure.core/alter-meta!
> ([iref f & args])
>  Atomically sets the metadata for a namespace/var/ref/agent/atom to
> be:
>
>  (apply f its-current-meta args)
>
>  f must be free of side-effects
>
>
> -Stuart Sierra
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: #^ Reader Macro Issues was Re: function equivalents of macro characters

[David Nolen]

Works. amazing.

On Mon, Jan 19, 2009 at 4:51 PM, David Nolen  wrote:

> Actually, so this can't be used on structs for fns?
>
> On Mon, Jan 19, 2009 at 1:47 PM, Stuart Sierra <
> the.stuart.sie...@gmail.com> wrote:
>
>>
>> On Jan 19, 1:15 pm, David Nolen  wrote:
>> > I've noticed this as well.  It seems to me that this prevents you from
>> > dynamically defining a var (like in a macro) that has metadata attached
>> to
>> > it or it's arguments (if it's a function).
>>
>> You can also use the new alter-meta! function, which works on
>> anything:
>>
>> -
>> clojure.core/alter-meta!
>> ([iref f & args])
>>  Atomically sets the metadata for a namespace/var/ref/agent/atom to
>> be:
>>
>>  (apply f its-current-meta args)
>>
>>  f must be free of side-effects
>>
>>
>> -Stuart Sierra
>> >>
>>
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Possible feature: consider aliases when reading namespace-qualified keywords.

[David Nolen]

My OO example from earlier deals with this case by completely removing any
need to manually derive tags.  This is done by having CLJOS keep it's own
internal hierarchy (via make-hierarchy) rather than using the default one.
 By modifying metadata on the vars holding structs created by defclass
(using alter-meta!) and tagging instances as described in existing Clojure
literature you can provide functions to shuffle away the annoyance of
dealing with keywords and their namespaces entirely.
On Mon, Jan 19, 2009 at 7:29 PM, Jason Wolfe  wrote:

>
> I've been doing some OO-type Clojure programming, and have run into
> the following (quite minor) annoyance:
>
> I've defined a struct with a :class of ::Foo in namespace
> my.long.namespace.foo.
>
> In another namespace my.long.namespace.bar, I want to define a
> subclass of this struct.
> In this namespace, I require [...foo :as foo], so that I can refer to
> multimethods like foo/method1.
>
> However, it seems I'm still required to write
> (derive ::Bar :my.long.namespace.foo/Foo)
> when I'd like to write
> (derive ::Bar :foo/Foo)
>
>  I'm not sure if this is even feasible, since given my limited
> experience it seems that aliases for symbols are handled at resolution-
> time and not read-time, and that wouldn't work for keywords.   On the
> other hand, this state of affairs seems to be possibly-confusing and a
> perhaps-needless difference between symbols and keywords.  What do
> others think about this?
>
> Thanks,
> Jason
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Multimethod Reflection?

[David Nolen]

Looking at the multimethod implementation (MultiFn.java) I noticed that
multimethod keeps an internal persistent map of dispatch values in a field
call methodTable.  It seems to me it would pretty simple to expose this
field (or a copy of it anyway) so that multimethod reflection can take
place.
(responds? astruct amultifn)

It's seems to me to be a minor change that would add a considerable amount
of reflective power to multimethods, as well providing support for something
like who-specializes in SLIME or any other IDE.

Thoughts?

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Multimethod Reflection?

[David Nolen]

Thanks!

On Tue, Jan 20, 2009 at 7:28 PM, Rich Hickey  wrote:

>
>
>
> On Jan 20, 6:48 pm, David Nolen  wrote:
> > Looking at the multimethod implementation (MultiFn.java) I noticed that
> > multimethod keeps an internal persistent map of dispatch values in a
> field
> > call methodTable.  It seems to me it would pretty simple to expose this
> > field (or a copy of it anyway) so that multimethod reflection can take
> > place.
> > (responds? astruct amultifn)
> >
> > It's seems to me to be a minor change that would add a considerable
> amount
> > of reflective power to multimethods, as well providing support for
> something
> > like who-specializes in SLIME or any other IDE.
> >
> > Thoughts?
>
> Fine idea - try SVN 1219 ;)
>
> Rich
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: struct question

[David Nolen]

Finally started a GitHub repo just for this project.
http://github.com/swannodette/cljos/tree/master

The earlier version of course was very flawed/buggy.  OK start, but the
macros in it were written with little/no understanding about how symbols are
resolved into their namespaces in Clojure (or Lisp for that matter). If
anybody is interested at all please feel free to fork or to leave comments.
 In particular I found no way to capture the symbols and their true
namespaces without resorting to eval and some wacky macros.  That said, it
does indeed work.  defclassed structs always refer to the namespace in which
they were declared, and parents correctly reflect their originating
namespace as well.

New stuff:

(instance-of? my-platypus platypus)
(member-of? a-circle shape)

No need for tags.  The only time you need tags is when defining
multimethods.  There's no real clean way to get around this except
implementing a macro around defmethod, and I'm not really sure creating a
macro around defmethod is so hot.  The discussion earlier about multiple
hierarchies for multimethod, especially predicate support would solve this
cleanly.

defclass now returns the struct.  I've also been toying around with an
optional Smalltalk message based dispatch.  Note the special applym, a
special version of apply that first checks to see if a struct responds? to a
multimethod.  If not it checks to see if there is a proxy and forwards the
message with the args to proxy.  This could allow for some interesting
interactions.

(defclass my-spore-animal [platypus]
  (:third-eye true))

(defclass bacteria [object]
  (:digest-grass true))

(def my-spore (make-instance my-spore-animal))
(def my-parasite (make-instance bacteria))

(defmulti digest :tag)
(defmethod digest ::bacteria [obj]
  (println "Munch munch!"))

;; we can pass messages to a proxy class
(applym digest (assoc my-spore :proxy my-parasite)) ;; "Munch Munch!"


The most exciting thing however is multimethod reflection (many thanks to
Rich).  The following is all the code it takes to see all the multifns that
specializes a particular tag.  In fact, really it should check all the
ancestors of the tag as well in order and I'm open to suggestions on what
the best way to implement that would be.

(defn has-dispatch? [multifn tag]
  (not (= (tag (methods multifn))
  nil)))

(defn responds? [obj multifn]
  (has-dispatch? multifn (:tag obj)))

(defn is-multi? [metadata]
  (and (:tag metadata)
  (= clojure.lang.MultiFn (:tag metadata

(defn who-specializes-tag? [tag]
  (filter #(and (is-multi? (meta %))
(has-dispatch? (var-get %) tag))
  (flatten (map #(vals (ns-interns %)) (all-ns)

(defmacro who-specializes? [constructor]
  `(who-specializes-tag?
(:class (meta (var ~(symbol (name constructor)))

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: struct question

[David Nolen]

>
> I am not entirely happy with this approach though. If everyone starts
> to use metadata for various purposes, such type tags may well
> disappear by some function replacing the metadata on an object
> without preserving the tags that are already there. This is all the
> more likely because there is nothing in the standard library to add a
> tag to an existing metadata map. All there is is (with-meta ...),
> which replaces the metadata map completely.
>
> Konrad.


Permanently changing the tag of an object after instantiation probably isn't
such a safe thing to do anyway. That's where functions like pose-as and
applym can come in handy.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: struct question

[David Nolen]

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
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
-~--~~~~--~~--~--~---

Re: struct question

[David Nolen]

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 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  > 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
-~--~~~~--~~--~--~---

Re: Possible feature: consider aliases when reading namespace-qualified keywords.

[David Nolen]

Nice :)

On Fri, Jan 23, 2009 at 2:10 PM, Jason Wolfe  wrote:

>
> On Jan 19, 4:29 pm, Jason Wolfe  wrote:
> > I've been doing some OO-type Clojure programming, and have run into
> > the following (quite minor) annoyance:
> >
> > I've defined a struct with a :class of ::Foo in namespace
> > my.long.namespace.foo.
> >
> > In another namespace my.long.namespace.bar, I want to define a
> > subclass of this struct.
> > In this namespace, I require [...foo :as foo], so that I can refer to
> > multimethods like foo/method1.
> >
> > However, it seems I'm still required to write
> > (derive ::Bar :my.long.namespace.foo/Foo)
> > when I'd like to write
> > (derive ::Bar :foo/Foo)
>
> On IRC, "duck1123" just showed me that this is already implemented;
> you just have to use the "::" form.
>
> (derive ::Bar ::foo/Foo)
>
> You learn something new every day...
>
> -Jason
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Clojure for Games/Simluation/Art (Optimization in Clojure)

[David Nolen]

Dear Clojurians,

After my obsessed stint with object orientation, I went on to a new obsessed
stint with basic functional programming with the hope of converting a nice
Java boid simulation written in the popular Processing pedagological tool.
 I would like to find out if anyone has pointers on improving the
performance of a simulation (and yes, I've read the performance
threads/docs, I have notes below about what I tried).  For reference a nice
small example of the flocking algorithm I tried to reimplement in Clojure
(along with code) can be found here:

http://www.shiffman.net/itp/classes/nature/week05_s07/flocking/

The technique was first described by Craig Reynolds in the 1980s and has
since then made it's way into many contemporary games.  The algorithm is
interesting in that it's fairly computationally intensive.  Each boid's
motion is determined by calculating it's distance from every other boid.  If
the other boids are within a threshold, 3 different vector values (cohesion,
alignment, separation) are calculated based on the location and velocites
from all other boids that are within the said neighborhood.  There's a lot
of interation, 67500 (150x150x3) iterations for 150 boids per update/render
loop.

When running this in the Processing app, you can calculate and render 150
boids in about 6-8ms (new Macbook Pro 2.4ghz).

I thought this little project would be a good exericise to get into deeper
Clojure, and to put aside my OO leanings.  First pass, I avoided premature
optimization.  I used only mapping operations and Clojure's built in
vectors.  This of course was horribly slow but I just wanted to see how
nicely the algorithm could be expressed.

Personally I think the algorithm is far more clear in the Clojure-centric
version.  However this version was awful in terms of performance.  About
100-110ms to calculate all the new positions for 150 boids.

http://github.com/swannodette/clojure-stuff/blob/a3b35bdd1254763bf3d535139f7ddab9f929fd3f/flocking.clj

I then proceeded to read about how something like this might be optimized,
and I tried a lot of things.  I struggled several days, read up a lot on
type hinting, on using Java Arrays in Clojure and I learned many many
interesting things related to raw performance (on OS X at least).

I have to say my experience with coding in Clojure thus far has been
fantastic.  Most of the performance metrics were determined simply by having
the program run and recompiling functions on the fly while dumping the
timing information into the REPL.  I could remove a single aget call and see
how that affected performance without needed to stop the running program.
 So here are some observations (would love to know if I'm way off on
anything):

1. Don't use multidimensional Java arrays.  You get a access time hit for
each dimension EVEN if you store the embedded array in a let binding.
2. aget is at least if not more expensive than a math operation.
3. Reuse Java arrays.  Making new arrays each time through a tight loop is
too demanding.  Implications for multithreading.  I would love to hear
alternative ways to implement this algorithm as well if anyone has any ideas
how to make it thread safe.
4. In Clojure functions are dirt cheap, blazingly fast, almost no overhead
here as far as I can tell.  Invisible almost.

After all of these optimization, I finally cut the framerate by a little
more than half, and now the code takes bout 41ms to update and render 150
boids:

http://github.com/swannodette/clojure-stuff/blob/e81308902cba849efbbaf197b6945c86e89e00ad/flocking.clj

Almost all the time is spent in the three functions, separate, cohesion, and
align  They all look pretty much like this:

(defn separate [{loc :loc, :as boid} #^floats distsv #^floats xs #^floats
ys]
  (let [dsep  (float 25.0)
len   (int (dec *boid-count*))
[sum acount]  (loop [i (int 0) rcount (int 0) result [0 0]]
(if (> i len)
  [result rcount]
  (let [x   (float (aget xs i))
y   (float (aget ys i))
d   (float (aget distsv i))
inhood  (and (> d (float 0))
 (< d dsep))
ncount  (int (if inhood (unchecked-inc
rcount) rcount))
nresult (if inhood
(add result
  (div (unit (sub loc [x y]))
d))
result)]
(recur (unchecked-inc i) ncount nresult]
(if (> acount (int 0))
  (div sum acount)
  sum)))

With a 150 boids, rendering consumes about 10ms (overhead from talking to
proxied Java class?) separate, cohesion, and align together add an
additional 30ms.

I am pretty much out of ideas on how to optimize this further in pure
C

Re: Clojure for Games/Simluation/Art (Optimization in Clojure)

[David Nolen]

>
> For the purpose of game development, I think it is a mistake to perform
> these calculations for every pair of birds. If you had an error of 1% in
> each of the three characteristics (cohesion, alignment, separation) would
> that still be good enough? Would this be an acceptable loss if you got a
> factor of 100 performance improvement?
>

Good point.


> In "Objective CAML for Scientists" [1] pages 92-101 Jon Harrop demonstrates
> a rapid numerical solution for a multibody gravitation problem, which looks
> similar to the problem you are solving. He refers to the method as Fast
> Multipole Method [2,3]. It trades a little accuracy for a big performance
> gain. Oh, and his implementation in OCaml uses only immutable data
> structures. No guarantees, but I have a feeling that this would completely
> eliminate your performance issues.
>

Very interesting, these book(s) look amazing!  Thanks much.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Clojure for Games/Simluation/Art (Optimization in Clojure)

[David Nolen]

On Wed, Jan 28, 2009 at 6:59 AM, bOR_  wrote:

>
> There is many ways in which you can improve the algorithm. I have seen
> flocks of 10,000 birds being rendered real-time on a laptop by Hanno
> Hildenbrandt, theoretical biology Utrecht.
>
>
> http://www.rug.nl/biologie/onderzoek/onderzoekgroepen/theoreticalbiology/peoplePages/hannoPage
>
> Also, Craig Reynolds himself has been working on speeding up crowd
> behaviour (was in contact with him a while ago about Hanno's model).
> http://www.research.scea.com/pscrowd/


More great references and readings, thanks.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: pretty-printing?

[David Nolen]

Agreed ;)

On Wed, Jan 28, 2009 at 9:54 AM, Matt Moriarity wrote:

>
> I say go for it. maybe swank could use it for macroexpansions and
> stuff. the lack of pretty-print drives me crazy!
>
> On Jan 27, 10:56 am, Mike DeLaurentis  wrote:
> > Hi,
> >
> > Is anyone aware of a pretty-print function for Clojure? I saw there
> > was some discussion about it on this thread a while ago, but I don't
> > seem to see anything related to pretty-print in either the core or
> > clojure-contrib. If no one's working on implementing it, I might take
> > a stab at it.
> >
> > Thanks,
> >
> > Mike
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Object system for Clojure?

[David Nolen]

At this point you have to roll your own, I have an experimental thing I plan
on fleshing out temporarily called CLJOS. I've implemented field
inheritance, type inheritance, basic multiple inheritance, basic
introspection.  Search the mailing list for CLJOS and you'll see more
details.  It only took 200 lines of code
You mention in particular field inheritance.  In CLJOS, you can define
default initializers for fields.  When you inherit from a class(es), a look
up table of default initializers is consulted, the values are merged in the
direction of the inheritance chain.

Admittedly, it is a bit of a toy example at this point, but it shows that
without too much effort you could build a very powerful object system based
on structs, and I've already found CLJOS to useful in my own hacking.  In
fact I would be happy to collaborate on something more substantial.
http://github.com/swannodette/cljos/blob/8167d3b58f536f89011a811d270a3cc72a289b1a/cljos.clj

Examples here and here:
http://github.com/swannodette/cljos/blob/8167d3b58f536f89011a811d270a3cc72a289b1a/cljos_example.clj
http://github.com/swannodette/cljos/blob/8167d3b58f536f89011a811d270a3cc72a289b1a/cljos_example_two.clj

Not too many people are doing heavy or fancy GUI related stuff (as far as I
can tell) so I can understand why this hasn't come up often.  I note that
you work with weblocks so I can see where you're coming from and I'm glad
you're bringing it up.

That said, I imagine if a decent, useful, and complete lightweight object
system could be designed I'm sure it could get rolled into clojure-contrib
without too much brouhaha.

On Fri, Jan 30, 2009 at 1:09 PM, Jan Rychter  wrote:

>
> There is something I don't understand about Clojure. There are
> multimethods (great), but I can't seem to find objects they can operate
> on. I come to Clojure from a Common Lisp background, having done a fair
> bit of CLOS programming. Mind you, I am not necessarily a fan of overly
> complex object hierarchies. But still -- I've been trying and I just
> can't seem to make objects in Clojure work.
>
> From what I read, the reasoning is that Clojure provides extremely
> general multimethods where you have to define a dispatch function. On
> the object side, there is metadata and you can do with it whatever you
> want. But this seems to leave a gaping hole saying "fill me with an
> object system". Is the goal for everyone to roll their own?
>
> I'm against overusing objects, but there are things which quite
> naturally map into the object-oriented paradigm. Let's take windowing
> systems for example -- let's assume you have various kinds of windows,
> each with its own unique attributes and attributes which are inherited
> (e.g. a window-id attribute is common to all windows). I can't see how
> you'd implement that in Clojure when you can't inherit structmap
> attributes. How do I build my-special-window which is a kind of window
> and also inherits window's window-id attribute? I know how to inherit
> behavior, but there is behavior that requires data, and I have no idea
> how to store and inherit that data. I looked at merge, but it seems you
> can't merge structure basis objects.
>
> Unfortunately, all discussion on Clojure polymorphism, multimethods and
> objects that I could find seems to use overly simplified examples (it
> really only shows that there are multimethods which can do multiple
> dispatch on anything), and doesn't really help. Even Stuart Halloway's
> beta "Programming Clojure" book has very simple examples that don't
> inherit attributes, just use different type tags for the same
> information.
>
> --J.
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Object system for Clojure?

[David Nolen]

>
> (defn make-window [id]
>  {:tag ::window, :id id})
>
> (defn make-color-window [id color]
>  (assoc (make-window id)
>:tag ::color-window
>:color color))
>
> (derive ::color-window ::window)
>
> (defmulti describe-window :tag)
>
> (defmethod describe-window ::window [w]
>  (println "Window with ID" (:id w)))
>
> (defmethod describe-window ::color-window [w]
>  (println (:color w) "Window with ID" (:id w)))
>
> (let [w (make-color-window 24 "blue")]
>  (describe-window w))
> ;; => prints "blue window with ID 24"


In any fairly large UI system this would become tedious in no time and a hit
on readability.  For example consider building a UI system from scratch for
a JOGL game of even medium complexity in pure Clojure (scrollbars, views,
zoomable views, sprites, physics, icons, buttons, et al.). A higher level
abstraction is required.  I'm not arguing that the language needs to provide
it directly, but at least have the framework in place so that it can be done
via macros (which already is the case).

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Object system for Clojure?

[David Nolen]

>
> On Jan 30, 3:16 pm, Stuart Sierra  wrote:
> >
> > I think the goal is to provide object-like capabilities without
> > needing actual objects.
>
> Why is that the goal?  I mean, the JVM provides a well defined, high
> performance object oriented system.  Clojure can already generate
> classes - the main issue I see looking at the API is that it doesn't
> look convenient to make "property bag" classes.
>

Except that compared to Clojure's multihierarchy multimethod system, Java's
object system seems a bit, shall we say, weak.  And why program in Java when
you can program in Clojure? Why deal with Java UI interop if you don't
need/want it? Just saying the OP has a valid point.

Perhaps someone wants to build a web based UI framework along the lines of
weblocks.  Perhaps you want to define easily extendable widgets in this UI
framework...

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Clojure is "not a serious language"

[David Nolen]

Agreed :)

On Fri, Jan 30, 2009 at 11:40 PM, Jon Harrop  wrote:

>
>
> Apologies if you've seen this before but I just thought it was absolutely
> hillarious:
>
> http://www.3ofcoins.net/2009/01/30/common-lisp-clojure-and-seriousness/
>
> --
> Dr Jon Harrop, Flying Frog Consultancy Ltd.
> http://www.ffconsultancy.com/?e
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

I've changed the name of my project since that was a joke anyway.
http://github.com/swannodette/spinoza/tree/master

Spinoza isn't just for people who want object oriented behaviors.  It's also
for anyone who plans on instantiating many structs.  Spinoza's make-instance
macro automatically orders your key/values and uses struct not struct-map.

(defclass shape [object]
  (:position [0 0]))

(defclass rect [shape]
  (:position [5 5])
  :width
  :height)

(time (dotimes [x 100]
(make-instance rect :height 100 :width 150)))
> ~280ms

(defstruct rect-struct :tag :position :width :height)
(time (dotimes [x 100]
(struct-map rect-struct :tag ::rect :position [50 50] :width 100 :height
190)))
> ~800ms

Also, it is now available under an MIT license, feel free to fork, send
patches at will etc.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

Just to be clear make-instance is a macro on struct:
(defmacro make-instance
  "Takes a defclassed struct-basis and creates a struct. Initializes
  properties to default values."
  [aclass & initializers]
  (let [class-key  (eval (make-pair aclass))
class-sym  (symbol (name aclass))
class-inits  (get-all-initializers-for-class class-key)
layout(rest (class-key @*layouts*))
layout-map (zipmap (reverse layout) (replicate (count layout)
nil))
rinitializers (vals (merge layout-map class-inits (apply
hash-map initializers)))]
`(struct ~class-sym ~class-key ~...@rinitializers)))

make-instance and struct are equivalent. make-instance just follows the
principle that the programmer should haven't to do anything a computer can
do for you (I'm still a macro noob, let me know if I'm doing anything
particularly nonsensical here).

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Clojure speed

[David Nolen]

Heh, this is a more reasoned reply than my own as it points out an actual
implementation difference between Python and Clojure. And of course you
might need arbitrary precision arithmetic in your program, but again this
just reinforces the insignificance of microbenchmarks without some context
of what you are actually trying to achieve.

On Mon, Feb 2, 2009 at 2:12 PM, Christian Vest Hansen
wrote:

>
> It is safe to assume that Python uses the GMP library for its infinite
> precision math, no? This could be a big part of the explanation as, if
> the language shootouts are to be believed, BigInteger and BigDecimal
> have inferior performance when compared to what can be achieved with
> GMP.
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Clojure speed

[David Nolen]

Please do the list a favor and read the very long threads about performance.
 You cannot expect to enter a new language run a microbenchmark you would
never see in a running programming and expect that to be anything like a
real comparison.
Here's something unlikely but far less so (something like it might
_actually_ appear in a real program):

t=timeit.Timer('class Sprite():\n\tx = 5\n\ty = 5\n\tvel = (5, 5)\n\tdef
__init__(self, nx, ny,
nvel):\n\t\tself.x=nx\n\t\tself.y=ny\n\t\tvel=nvel\n\n\nfor n in
range(100):\n\tSprite(5, 5, (9, 10))')
> 1.1212704896926879

vs.

(defstruct sprite :x :y :vel)
(time (dotimes [x 100]
(struct sprite 5 5 [9 10])))
> 262.041ms

4X faster. But it really doesn't prove anything any more than your example
does.  Play around with Clojure long enough, and you'll find for many many
things, it is far faster than Python.

This is not a rag on Python, I enjoy Python hacking myself.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

Hey, it is an extremely simplified example ;)
Which is more readable in the long run?

(struct sprite ::foobar 98 ::hunta ::laser [5.5 3.3] 4.01 78)

or

(make-instance foobar :id 98
 :mode ::hunta
 :weapon ::laser
 :position [5.5 3.3]
 :velocity 4.01)
 :targetid 78]

With Spinoza the two are equivalent, just make-instance is more readable.
 make-instance is also programmer friendly.  You don't need to memorize the
layout of a complex set of properties (imagines a sub-subclass of this
sprite both which add 3 properties).  That's 13 properties you have to
remember to type in the right order.

Say you have several different kinds of sprites.  With struct you would have
to manually define the layout for each different kind of sprite you want to
use (a lot of redundancy).  That or you have to defstruct a struct with all
the properties predetermined and create functions that create instances of
the different types (then why not use defclass at that point ? ;)

If you relied on struct and decide to change the properly layout you have to
go modify all the places where you used struct.  No so with make-instance.

Anyways, this was a goal stated earlier. I wanted make-instance to have the
readability of struct-map with the performance of struct.

Cheers.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: special forms vs. functions and macros

[David Nolen]

I think the special forms list on the Clojure main page lists all the
constructs that are not written in Clojure itself.  It seems most everything
else can be found in the .clj files in the src directory.  I'm constantly
looking in there when I'm curious how something works or is implemented,
especially if the terse argument list doesn't make sense to me.
On Mon, Feb 2, 2009 at 9:28 PM, Mark Volkmann wrote:

>
> I understand that special forms are all recognized by the Clojure
> compiler clojure.lang.Compiler. Is it the case that all function and
> macro definitions can be found in some .clj file, whether supplied
> with Clojure or not? Asked another way, are there any functions or
> macros that are included with Clojure that are implemented entirely in
> Java code?
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: need some help getting jacob com library to work

[David Nolen]

You need to add it to -cp argument when starting up the REPL, not your
environment CLASSPATH.

On Mon, Feb 2, 2009 at 9:05 PM, greg  wrote:

>
> I have recently enjoyed exploring clojure.
>
> I can use java...
> C:\myprograms\clojure>java -cp clojure.jar clojure.lang.Repl
> Clojure
> user=> (into [] (.list (new java.io.File "c:/myprograms/clojure")))
> ["build.xml" "changes.txt" "clj.ico" "clojure.jar" "epl-v10.html"
> "fractal.clj"
> "Mandelbrot.class" "Mandelbrot.java" "pi.clj" "pom.xml" "readme.txt"
> "REPL.bat"
> "snake.clj" "src" "svninfo.txt" "test.clj"]
>
> I am having trouble getting jacob to work. Jacob is in my PATH and
> CLASSPATH
>
> user=> (import '(com.jacob.com Dispatch))
> java.lang.ClassNotFoundException: com.jacob.com.Dispatch
> (NO_SOURCE_FILE:0)
> user=>
>
> pointers?
> -thanks
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Clojure speed

[David Nolen]

Even more constructive is to take a real Python program that you've written
where you actually care about it's performance.  Rewrite it Clojure.  Do
some investigation about which parts seem slow to you.  Spend some time on
this.  Come back with some code and questions and you'll probably get some
great answers.  At that point you might start to understand what the
performance characteristic of the language actually are.  Perhaps some
idioms in Python are faster, perhaps you need to learn new idioms to express
them more efficiently in Clojure.  Perhaps you'll find out some things are
ungodly faster in Clojure and, of course, some things, like BigInteger math,
aren't.
2009/2/3 Gregory Petrosyan 

>
> On Feb 3, 12:50 pm, André Thieme  wrote:
>
> > Hi, welcome in the group.
> > Can you please write that program in Java and see how well it
> > performs for you?
>
> Will try to compare Java and Clojure later.
>
> Here http://leonardo-m.livejournal.com/75825.html you can find similar
> microbenchmark. Java is more than 3х slower than Python's built-in
> integers, and more than 10x slower than GMPY ones. Seems like Java's
> BigIntegers have some problems with performance, hm?
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

Haha, nope that's probably beyond the scope of what I'm trying to achieve.
 Spinoza just adds some object orientedness to struct-maps that's all.  As
far as I can tell there not much explicit control over memory consumption in
Clojure.
On Tue, Feb 3, 2009 at 2:56 PM, Bradbev  wrote:

>
> On Feb 1, 5:22 pm, David Nolen  wrote:
> > I've changed the name of my project since that was a joke anyway.
> http://github.com/swannodette/spinoza/tree/master
> >
> > Spinoza isn't just for people who want object oriented behaviors.  It's
> also
> > for anyone who plans on instantiating many structs.  Spinoza's
> make-instance
> > macro automatically orders your key/values and uses struct not
> struct-map.
> >
> > (defclass shape [object]
> >   (:position [0 0]))
> >
> > (defclass rect [shape]
> >   (:position [5 5])
> >   :width
> >   :height)
> >
> > (time (dotimes [x 100]
> > (make-instance rect :height 100 :width 150)))
> >
> > > ~280ms
> >
> > (defstruct rect-struct :tag :position :width :height)
> > (time (dotimes [x 100]
> > (struct-map rect-struct :tag ::rect :position [50 50] :width 100 :height
> > 190)))
> >
> > > ~800ms
> >
> > Also, it is now available under an MIT license, feel free to fork, send
> > patches at will etc.
>
> Does Spinoza do anything to optimize the size of the object?  I'm
> tinkering with a project that will have several million objects in
> it.  Currently I'm using struct-maps with around 7 keys, and the
> overhead appears to be around 200 bytes per map - I'd like it to be
> around 32 bytes ideally.  I'm planning on eventually using Java
> objects to shrink the size, but it would be nice if there were a
> Clojure library I could use.
>
> Cheers,
> Brad
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Macro error

[David Nolen]

{} is a reader macro for hash-map I believe, try something like this:

(defmacro foobar [& rest]
  `(hash-map ~...@rest))

(foobar :first 1 :second 2)

On Tue, Feb 3, 2009 at 7:45 PM, Jeffrey Straszheim <
straszheimjeff...@gmail.com> wrote:

>
> Btw, I fixed the ~ needed on relation.  It didn't help.  It seems I
> just can't put a ~@ form inside of a { } set builder.
>
> On Feb 3, 7:43 pm, Jeffrey Straszheim 
> wrote:
> > I'm trying to define a macro:
> >
> > http://paste.pocoo.org/show/102695/
> >
> > But whenever I try to compile it I get:
> >
> > java.lang.ArrayIndexOutOfBoundsException: 1
> > java.lang.Exception: Unmatched delimiter: )
> > java.lang.Exception: Unmatched delimiter: )
> >
> > Note, this is when compiling the macro itself, not executing it.  I
> > don't understand.
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Type hint Java array of your own Java class

[David Nolen]

(defn foobar [#^MyClass[] myarray])
This syntax doesn't seem to work.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Type hint Java array of your own Java class

[David Nolen]

Many thanks.

On Wed, Feb 4, 2009 at 12:49 PM, Christophe Grand wrote:

>
> David Nolen a écrit :
> > (defn foobar [#^MyClass[] myarray])
> >
> > This syntax doesn't seem to work.
> Indeed it's a bit tricky:
> #^"[Lyour.package.YourClass;"
>
> You can find it by doing:
> user=> (class (into-array [(your.package.YourClass.)]))
> [Lyour.package.YourClass;
>
> Christophe
>
> --
> Professional: http://cgrand.net/ (fr)
> On Clojure: http://clj-me.blogspot.com/ (en)
>
>
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: anyone going to FOSDEM?

[David Nolen]

Raphaël,
I will be there presenting the open source meta web project ShiftSpace (
http://shiftspace.org) at the art festival Artefact (
http://www.artefact-festival.be/).  Unfortunately this project isn't really
Clojure related, it's primarily written in Javascript :) However, two people
(including myself) have been playing around with Clojure and wouldn't mind
meeting a fellow Clojurian! We arrive on Sunday and are planning on checking
FOSDEM out.

We're also giving a developer workshop on ShiftSpace in Brussels on the 12th
so if you're around come check that out as well.

David

2009/2/5 rb 

>
> Hi,
>
> are any clojure developers going to FOSDEM, next week-end in Brussels
> (Belgium)?
>
> It would be cool to meet there. (I'm a complete newbie at clojure, but
> that would make it the more interesting for me to meet other clojure
> developers:-)
>
> Cheers
>
> Raphaël
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Clojure Simulation Redux (more on Clojure Optimization)

[David Nolen]

For those who are interested in Clojure performance, I've updated my
flocking example from earlier, which uses Roland's excellent Processing
library.
http://github.com/swannodette/clojure-stuff/blob/80035bb3b76c21d39d6f8011e9a27aa1116b/flocking.clj

It is twice as fast as the previous version and purely functional, no
reusing Java arrays or reusing PVector objects.

1. Use make-arrays wisely and it works well.
2. Do your math in Java (PVector in my case), Clojure's built in vectors
just aren't designed for it, which is FINE.
3. Type-hint very very very very agressively.  *warn-on-reflection* is a
life saver, thanks Rich.

It's still a bit slower (2X-3X) than the Processing version, but I prefer
the fact that this one is functional over the original, no changing vector
objects in place.

This pretty much as far as I can see it going down this path, it is pretty
much a direct translation of the Java version minus mutation, in the next
version I hope to incorporate some of the suggestions in reply to my earlier
post (FMM in particular).

David

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

>
> I don't argue that this model is better than what you're doing with
> Spinoza, but for years (see
> http://www.mactech.com/articles/frameworks/8_2/Protocol_Evins.html
> from 1994) I've wanted an object model that explicitly separates
> structure from protocol, and since I partially built one in order to
> satisfy a need I had in a larger project, I think I'll push ahead with
> it a bit to see whether it's worthwhile.


Yes this is a good thing, but you get this behavior for free with Clojure's
multimethods.  For example:

(defprotocol clonable) ;; derives ::clonable from ::protocol

(defmulti clone dispatch-fn) ;; dispatch-fn -> [::class ::protocol]
(defmethod [::my-class ::clonable] ...)

In fact,

(defprotocol clonable [clone deep-clone ...])

could be a macro that automatically defines all of the base multifns.

(protocols object) ;; returns a list of all the protocols an object
implements via multimethod reflection

This would be easy to add to Spinoza, if you want perhaps we could hash it
out and we can add it.  Or you can forge out on your own, but I think it's
always fun to join forces.

David

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

(isa? [:spinoza-example-one/circle] [:spinoza/object]) ;; true

Just to note, the above shows that protocols could have their own
inheritance chain.  This is insanely powerful and could be implemented very
quickly.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

>
> I'm not looking for a way to statically define protocols in which
> classes participate. Consider an example similar to the one I gave in
> my reply to Laurent:


Static defining of anything is just a matter of chose, especially in
Clojure.  For example in Spinoza you have pose-as which changes the class of
an object. The primary purpose of Spinoza is structural inheritance and
basic dispatch on type, but I've been thinking about runtime modification
and your post gives me a lot of ideas.


> (make-thing {:models [::vehicle ::airborne]
>:protocols [::thing ::idea]
>   :inits {:name "test-thing1" :number 1}})
>

Something like this would be quite simple to build on top of Spinoza.  Also
allowing protocols to be defined at class definition time and runtime would
work the same way that pose-as works

(adopt-protocol obj ::some-protocol ::another-protocol)


> Note that no classes are involved. The thing in question is not an
> instance of any class (except incidentallly, by virtue of the fact
> that Clojure's runtime is built on the JVM). I never defined any
> classes, nor did I wish to. A class definition would have been just an
> obstacle, not directly relevant to my goal, which was to instantiate
> an object that reflects these models and participates in these
> protocols.


As I'm alluding above, this direction seems prototypal, and I've been
thinking about allowing for these kind of behaviors in Spinoza.

Of course no collaboration beyond healthy discussion is expected.  Thanks
for bringing the topic up again :)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

>
>  The fly in the ointment is: what happens if both
> protocols specialize frob? Then Clojure will complain that it can't
> tell which method to call. In order to resolve that problem, we must
> use prefer-method to declare that one protocol or the other is
> preferred.
>
> But what if I want to make another thing:
>
> (make-thing {:models [::thing]
>   :protocols [::idea ::thing]
>   :inits {:name "test-thing2" :number 2}})
>

make-thing could tag your thing with a runtime tag and define a prefer on
this runtime tag.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

>
>   (prefer-method frob ::idea ::thing)
>

(prefer-method [::runtime-tag1 ::idea] [::runtime-tag1 ::thing])
(prefer-method [::runtime-tag2 ::thing] [::runtime-tag2 ::idea])

Provide a dispatch fn that extracts the runtime tag.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

Have thoughts about this, will have to collect them, will reply soon.

On Thu, Feb 5, 2009 at 9:06 PM, mikel  wrote:

>
>
>
> On Feb 5, 7:12 pm, David Nolen  wrote:
> > > I'm not looking for a way to statically define protocols in which
> > > classes participate. Consider an example similar to the one I gave in
> > > my reply to Laurent:
> >
> > Static defining of anything is just a matter of chose, especially in
> > Clojure.  For example in Spinoza you have pose-as which changes the class
> of
> > an object. The primary purpose of Spinoza is structural inheritance and
> > basic dispatch on type, but I've been thinking about runtime modification
> > and your post gives me a lot of ideas.
> >
> > > (make-thing {:models [::vehicle ::airborne]
> > >:protocols [::thing ::idea]
> > >   :inits {:name "test-thing1" :number 1}})
> >
> > Something like this would be quite simple to build on top of Spinoza.
>  Also
> > allowing protocols to be defined at class definition time and runtime
> would
> > work the same way that pose-as works
> >
> > (adopt-protocol obj ::some-protocol ::another-protocol)
> >
> > > Note that no classes are involved. The thing in question is not an
> > > instance of any class (except incidentallly, by virtue of the fact
> > > that Clojure's runtime is built on the JVM). I never defined any
> > > classes, nor did I wish to. A class definition would have been just an
> > > obstacle, not directly relevant to my goal, which was to instantiate
> > > an object that reflects these models and participates in these
> > > protocols.
> >
> > As I'm alluding above, this direction seems prototypal, and I've been
> > thinking about allowing for these kind of behaviors in Spinoza.
> >
> > Of course no collaboration beyond healthy discussion is expected.  Thanks
> > for bringing the topic up again :)
>
> It's not quite the same as the usual prototype-based systems either.
> Generally, in a protoype-based system you have one of two inheritance
> schemes:
>
>  1. structure and behavior are copied (inherited) from one or more
> prototypes (or "parents"), as in Javascript
>
> or
>
>  2. structure is copied from one prototype (the "data parent");
> behavior is copied from another (the "behavior parent") as in Self
>
> The model/protocol/thing stuff does not use parent objects at all. It
> collects field specifications from model objects, but no inheritance
> relationship is established. It uses the protocols to establish
> multimethod dispatch in the manner of derive, but no delegate object
> is used.
>
> Ruben Kleiman's SK8 system had a prototype-based object model that
> would have made it easy to implement all the features of the model/
> protocol/thing subsystem, but his object system was not typical. It
> had more in common with frame systems like KEE than with typical
> class- or prototype-based object models. His object model included per-
> object configurable inheritance (and per-slot configurable accessors--
> in fact, each slot of an object--slot, not value--could itself be an
> arbitrary object with arbitrary model and protocol). I'm not entirely
> sure I want to recapitulate the entire SK8 object model for this
> project, though. :-)
>
> There are a few more things I want to get working:
>
> 1. you should be able to pass a set of map literals as the models
>
> 2. you should be able to pass a set of dynamically computed protocol
> objects (whatever those turn out to be) as the protocols
>
> 3. Given a thing, you should be able to ask it what models it
> represents and what protocols it implements
>
> 4. Given a model and a thing, you should be able to ask whether the
> thing represents the model
>
> 5. Given a protocol and a thing, you should be able to ask whether the
> thing implements the protocol
>
> 6. It should be easy and natural to create models, protocols, and
> things dynamically and without any static declarations being required.
> Classes, if they exist at all, should be optional. It should be
> possible to dynamically create a thing from arbitrary sets of models,
> protocols, and initial map entries (subject to consistency checks).
>
> 7. It should be straightforward to serialize models, protocols, and
> things (this subsystem is not an end in itself, but a component of a
> larger project in which it's important that the data objects be
> amenable to serialization and deserialization, both for storage in
> nonvolatile repositories and for t

Re: CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

>
> Yuck. Instead of defining a method on ::idea, you now must define a
> method on [something-that-has-no-meaning-in-context  ::idea] (because
> the dispatch function must now return a vector, which means the
> defmethods must now be called on vector dispatch values...).


Sure but as you mention below this could be hidden via a macro
(defprotocol-method ...).  This also could be used to implement something
that works like eql specializers...


> I was kind of sliding in another direction: I could always implement
> CLOS-style method computation and sorting. But of course that might
> mean not reusing multifn and its dispatch mechanism, and that seems a
> shame. Maybe I could bury the defmethod ugliness in syntactic sugar...


Looking at the requirements above it seems like you have something specific
in mind for this system so perhaps Spinoza is not well suited for the
particular thing you are shooting for.  However all of your ideas are quite
fantastic.

I will definitely add protocol support to Spinoza, but it will probably be
something that emphasizes static definitions with good support for runtime
modifications.  Your system sounds very interesting and it would be great to
hear how it develops if only to get more ideas for Spinoza ;)

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Tools for parsing arguments

[David Nolen]

Is there anything in core or contrib for parsing arguments to a
function? Since Clojure fns don't support optional args or even keyword
args, is there a standard set of helpers functions to do this? I looked
around but I didn't see anything obvious.
David

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Multimethod Reflection Question

[David Nolen]

(methods multifn)

Returns a hash-map where the keys are vectors if the dispatch values of the
multimethods were vectors, weird and cool :)

How does one check for the existence of a key in a hash-map if the key is
vector? I tried several things and nothing obvious seemed to work.

Thanks,
David

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Tools for parsing arguments

[David Nolen]

Thanks all, Clojure list is the best.

On Fri, Feb 6, 2009 at 11:27 AM, Christophe Grand wrote:

>
> Stuart Sierra a écrit :
> > No, but there is a pattern for keyword args:
> >
> > (defn my-function [& args]
> >   (let [options (apply hash-map args)]
> > ...))
> >
> > Then you can call (my-function :keyword value :keyword2 value)
> And you can use destructuring to add support for defaults value:
>
> (defn my-function [& args]
>  (let [{:keys [option1 option2] :or {option1 "default1" option2
> "default2"}} (apply hash-map args)]
>...))
>
>
> Christophe
>
> --
> Professional: http://cgrand.net/ (fr)
> On Clojure: http://clj-me.blogspot.com/ (en)
>
>
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

>
> I built 4 iterations of a model/protocol/thing system, accumulating
> more requirements for it with each iteration. This discussion has had
> the nice side-effect of grooming my requirements into a tidy state
> that I can use for reference. What I'm doing next is stripping out all
> of the m/p/t stuff and implementing the application in question
> without any of it, to see which of the requirements are really
> requirements.


Yes, I myself have found it tricky coming up with something that doesn't go
too far against the grain of the language.

On the subject of Spinoza, when I read through the source, it reads
> like a recapitulation of parts of tinyclos. tinyclos has the virtue of
> presenting a reasonably complete metaobject protocol that can be used
> to implement arbitrary OOP features. Maybe you don't want everything
> in tinyclos, and maybe you don't want to do things in Spinoza the same
> way that tinyclos does them, but if implementing a CLOS-like object
> system, it still seems useful to compare the implementation to
> tinyclos, if nothing else, to clarify the differences between what it
> does and what is natural or convenient in Clojure.


Thanks for the discussion and the reference.  I'll definitely check it out
tinyclos.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Multimethod Reflection Question

[David Nolen]

Hmm, for example, this does not work:
([:spinoza/object :spinoza-example-three/serializable] (methods archive))

I get the following exception:

java.lang.IllegalArgumentException: Key must be integer

even though:

(= [:spinoza/object :spinoza-example-three/serializable]  (ffirst (methods
archive)))

Returns true.

David


2009/2/6 Craig Andera 

>
> > (methods multifn)
> >
> > Returns a hash-map where the keys are vectors if the dispatch values of
> the
> > multimethods were vectors, weird and cool :)
> > How does one check for the existence of a key in a hash-map if the key is
> > vector? I tried several things and nothing obvious seemed to work.
>
> Vectors are values that compare like scalars do:
>
> ({[1 2 3] :numbers [\a \b \c] :letters} [1 2 3]) => :numbers
> ({[1 2 3] :numbers [\a \b \c] :letters} [3 4 5]) => nil
>
> Which is both surprising (to a newbie like me) and extremely logical
> in retrospect. :)
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Multimethod Reflection Question

[David Nolen]

Oops not paying attention you are right.  Hash map comes first as the
function. Works like a charm.

2009/2/6 Craig Andera 

>
> > (methods multifn)
> >
> > Returns a hash-map where the keys are vectors if the dispatch values of
> the
> > multimethods were vectors, weird and cool :)
> > How does one check for the existence of a key in a hash-map if the key is
> > vector? I tried several things and nothing obvious seemed to work.
>
> Vectors are values that compare like scalars do:
>
> ({[1 2 3] :numbers [\a \b \c] :letters} [1 2 3]) => :numbers
> ({[1 2 3] :numbers [\a \b \c] :letters} [3 4 5]) => nil
>
> Which is both surprising (to a newbie like me) and extremely logical
> in retrospect. :)
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Strapped to the JVM?

[David Nolen]

Well considering that the JVM is now open source as well as Clojure itself I
wouldn't worry too much :)
That said all languages are simply stepping stones, Clojure happens to be a
particular elegant one that you might want to pause on for a considerable
amount of time, take a deep breath, and enjoy the view.

David

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: CLJOS -> Spinoza, 3X faster than struct-map ;)

[David Nolen]

>
> On the issue list there is a patch for per-defmulti hierarchies,
> waiting for Rich's approval. Although it's not predicate dispatch
> it might help to bridge the time until the SoC project gives us
> predicate dispatch.
>
> Sincerely
> Meikel
>
>
+1 for this, without this the usefulness of make-hierarchy seems limited.

David

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: ANN: clojure.contrib.error-kit

[David Nolen]

Nice I will most definitely be checking this out and get back with thoughts.
 I've been fearing the need to define custom Java Exception for my code and
this looks most useful for people who wish to code as much as possible in
pure Clojure.

On Fri, Feb 6, 2009 at 9:10 PM, Chouser  wrote:

>
> It's not currently possible to define new Java Exceptions without
> ahead-of-time compilation, which is sometimes inconvenient.  Besides
> this, Java's try/catch exception system isn't as flexible as, for
> example, Common Lisp's condition/restart system.
>
> To address both these concerns, I've added a lib called error-kit to
> clojure-contrib.  Its still pretty experimental, so if you find it
> awkward to use of think of better names of the lib itself of anything
> it defines, please let me know.  Of course I'd also love to hear if
> anyone finds it useful.
>
> Here's a quick demo of its features:
>
>  (require '(clojure.contrib [error-kit :as kit]))
>
> This defines an error and its action if unhandled.  A good choice of
> unhandled action is to throw a Java exception so users of your code
> who do not want to use error-kit can still use normal Java try/catch
> forms to handle the error.  The throw-msg macro helps you do this:
>
>  (kit/deferror *number-error* [] [n]
>{:msg (str "Number error: " n)
> :unhandled (kit/throw-msg NumberFormatException)})
>
> This next error derives from the one above, which means if
> *odd-number-error* is raised, it can be caught by a handler for
> *number-error*:
>
>  (kit/deferror *odd-number-error* [*number-error*]
>"Indicates an odd number was given to an operation that is only
>defined for even numbers."
>[n]
>{:msg (str "Can't handle odd number: " n)})
>
> Raise an error by name with any extra args as defined by the deferror:
>
>  (defn int-half [i]
>(if (even? i)
>  (quot i 2)
>  (kit/raise *odd-number-error* i)))
>
> Since this form ends up calling 'raise', but has no 'with-hander' and
> 'handle' form, it will throw a regular Java NumberFormatException:
>
>  (vec (map int-half [2 4 5 8]))
>
> But you can handle the error, collect details from the args passed to
> 'raise', and do whatever you want with it.  In this case, just throw
> an Exception with a more specific message:
>
>  (kit/with-handler
>(vec (map int-half [2 4 5 8]))
>(kit/handle *odd-number-error* [n]
>  (throw (Exception. (format "Odd number %d in vector." n)
>
> The above is equivalent to the more complicated version below:
>
>  (kit/with-handler
>(vec (map int-half [2 4 5 8]))
>(kit/handle {:keys [n tag]}
>  (if (isa? tag `*odd-number-error*)
>(throw (Exception. (format "Odd number %d in vector." n)))
>(kit/do-not-handle
>
> Returns "invalid" string instead of a vector when an error is
> encountered.  This is like Clojure's try/catch form.
>
>  (kit/with-handler
>(vec (map int-half [2 4 5 8]))
>(kit/handle kit/*error* [n]
>  "invalid"))
>
> Inserts a zero into the returned vector where there was an error, in
> this case [1 2 0 4]
>
>  (kit/with-handler
>(vec (map int-half [2 4 5 8]))
>(kit/handle *number-error* [n]
>  (kit/continue-with 0)))
>
> Here's how to use an intermediate continue, like a CL restart.  The
> with-handler form below will return [1 2 :oops 5 4]
>
>  (defn int-half-vec [s]
>(reduce (fn [v i]
>  (kit/with-handler
>(conj v (int-half i))
>(kit/bind-continue instead-of-half [& instead-seq]
>  (apply conj v instead-seq
>  [] s))
>
>  (kit/with-handler
>(int-half-vec [2 4 5 8])
>(kit/handle *number-error* [n]
>  (kit/continue instead-of-half :oops n)))
>
> A couple questions, for anyone still reading...
>
> Should continue-names be namespace qualified, and therefore require
> pre-definition in some namespace, like this?
>
>  (kit/defcontinue skip-thing "docstring")
>
> Could add 'catch' for Java Exceptions and 'finally' support to
> with-handler forms.
>
> --Chouser
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: ANN: clojure.contrib.error-kit

[David Nolen]

So far this is fantastic! And I haven't even got around to playing with the
restart mechanism :) I'm using it in Spinoza to provide contextual errors
(malformed slot list, missing base class etc.).  I notice the contrib
libraries in general are very good at throwing exceptions so that consumers
have some idea of what is going on.  error-kit one ups this practice by
providing a standardized way to define your errors up front and presents a
definition system that removes the need to instantiate ugly Java Exceptions
inline with your code.
(defn protocol-fn [protocol-name fn-name]
  (let [protocol-keyword (symbol-to-keyword protocol-name)
dispatch (partial protocol-dispatch protocol-keyword)]
`(do
   (defmulti ~fn-name ~dispatch)
   (defmethod ~fn-name [:spinoza/object nil]
 [~'obj]
 (raise *missing-protocol-method-error*
 ~'obj ~(str protocol-name) ~(str fn-name))

Where the error is defined as you've described:

(deferror *missing-protocol-method-error* [*spinoza-error*]
  [obj protocol-name method-name]
  {:msg (str (:tag obj)
 " class does not implement "
 method-name
 " from protocol "
 protocol-name)})

Sweet!

That said I do have one minor annoyance and that is the need to leave an
empty bracket if you want to create a new error without inheriting from a
previously defined error.  Very minor.  Will provide feedback on restarts
when I get there.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Clojure, Slime and multiple file projects

[David Nolen]

A simple solution is to define a namespace that brings in all of your
different files. Is there some reason you can't do things this way?

On Mon, Feb 9, 2009 at 8:05 AM, Bradbev  wrote:

>
> Hi folks,
> I'm getting to the stage on a Clojure project that I want to start
> breaking the code into multiple files.  My primary environment is
> Emacs & Slime and interactive development.  Is there a standard way
> for me to load all of my project's files into the running VM?
> Right now I manually go to each file & load it.  I guess I could also
> write a little function that loaded all the files in the correct
> order, but if there is an actual framework tool (like ASDF) then I
> would try to use that.
>
> Cheers,
> Brad
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: How to port a mixin to clojure

[David Nolen]

There are quite a few ways to do what you're describing (and no particular
prescribed way).  You want to look at multimethods and tag hierarchies.
http://clojure.org/multimethods

Tags can have multiple parents.

I'm working on a project called Spinoza (search the mailing list for that
and CLJOS) which you might want to give a look if you want to see one
perspective on what a syntax to do the above might look like.  It also uses
multimethods and hierarchies but it removes the need to manually deal with
tags or explicitly call object initializers.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Generic functions: things, models, and protocols revisited

[David Nolen]

Neat! You've removed the need to even define a dispatch-fn.  I'll need to
chew on this for a bit (I'm a little slow :) I'm still working on my attempt
at implementing protocols, but I'm not totally clear on where it will go or
how useful it will be.
Seems like this kind of dispatch and the Datalog project might meet up soon?
Or am I totally wrong?
On Thu, Feb 12, 2009 at 12:02 PM, mikel  wrote:

>
> David Nolen and I were recently discussing CLOS and method dispatch. I
> implemented such a scheme for my own use. This post is an FYI for
> David and anyone else who might be interested in generic functions and
> predicate dispatch.
>
> Here's a transcript of a sample session in which I exercise the
> dispatch cases:
>
> (def $gf (make-generic-function))
>
> (add-gf-method $gf [nil] (fn [x] (str "found value: " (.toString x) "
> of type: " (.toString (class x)
>
> (add-gf-method $gf [java.lang.Number] (fn [x] (+ x 1)))
>
> (add-gf-method $gf [java.lang.String] (fn [x] (str "Found string: "
> x)))
>
> (add-gf-method $gf [{:equals 5}] (fn [x] (str "Found 5!")))
>
> (add-gf-method $gf [{:model {:name nil}}] (fn [x] (str "Found a thing
> whose name is " (:name x
>
> (add-gf-method $gf [java.lang.Number java.lang.Number] (fn [x y] (+ x
> y)))
>
> (add-gf-method $gf [java.lang.String java.lang.String] (fn [x y] (str
> x " " y)))
>
> (add-gf-method $gf [java.lang.String java.lang.Integer] (fn [s i]
> (apply str (take i (cycle [s])
>
> (add-gf-method $gf [{:test (fn [x] (= x "swordfish"))}] (fn [s] (str
> "You said the secret word, you win a hundred dollars!")))
>
> user> ($gf "hello" "world")
> "hello world"
> user> ($gf 2 3)
> 5
> user> ($gf {:name "Barney"})
> "Found a thing whose name is Barney"
> user> ($gf 5)
> "Found 5!"
> user> ($gf "bananas")
> "Found string: bananas"
> user> ($gf 100)
> 101
> user> ($gf 'some-symbol)
> "found value: some-symbol of type: class clojure.lang.Symbol"
> user> ($gf "foo" 5)
> "foofoofoofoofoo"
> user> ($gf "swordfish")
> "You said the secret word, you win a hundred dollars!"
>
>
> It works well enough to produce that transcript, but is very
> preliminary. I'm sure there are bugs I haven't noticed yet, and no
> doubt it's terribly slow. For one thing, I know it's doing a lot of
> redundant comparisons at the moment.
>
> It's missing a number of amenities and at least one important feature:
> next-method is not yet implemented.
>
> When called, a generic function matches the arguments it received
> against formal parameters in its dispatch table. Matching of a formal
> parameter works like so:
>
> nil: match any value passed in this position
>
> a Java class: match any value that is an instance of the class (or of
> a subclass of it)
>
> a Map of the form: {:model m}: match any value v for which (model? v
> m) returns true
>
> a Map of the form {:equals x}: match any value v for which (= v x)
> returns true
>
> a Map of the form {:test f}: match any value for which (f x) returns
> true
>
>
> Calling  ($gf 2 3) or whatever works because the object in $gf is a
> closure:
>
> (defn make-generic-function [& [dispatch-table]]
>  (let [dt-ref (or dispatch-table (ref {}))]
>(fn [& args] (apply-generic-function dt-ref args
>
> There's a little trickery with sentinel values and metadata to enable
> me to provide an API for adding and removing methods, which are stored
> in the dispatch-table created in make-generic-function. It would be
> nice to make that code a little less clever, but that would require a
> convenient way to create a new kind of callable object; I'd need to be
> able to define what happens when it's applied.
>
> Now we'll see if this thing is useful enough to make it better.
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Generic functions: things, models, and protocols revisited

[David Nolen]

>
>
> > Seems like this kind of dispatch and the Datalog project might meet up
> soon?
> > Or am I totally wrong?
>
> I have given it zero thought.


Perhaps interesting to pursue? Rich had brought it up in conversations about
predicate dispatch. Could greatly help from the performance side of things?

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Newbie at macros: Manipulating a vector of bindings

[David Nolen]

You can pretty much call anything outside of the quote, in fact all runtime
information is available (you have access to anything that was previously
read).  The main thing to understand is that all parameters passed to your
macro are unevaluated.

On Sat, Feb 14, 2009 at 10:45 AM, samppi  wrote:

>
> Thank you so much. I'm confused, however, about what functions you're
> allowed to call inside a macro outside of a quote. I read once that
> "runtime information" was unavailable during the macro phase. But it
> seems that one is still allowed to call array-map, apply, take-nth,
> and vec during the macro phase. What is the pattern for what is
> allowed or prohibited in macros?
>
> On Feb 13, 10:52 pm, Chouser  wrote:
> > On Fri, Feb 13, 2009 at 11:17 PM, samppi  wrote:
> >
> > > I'm trying to write a macro that expands from this:
> >
> > > (product-context [n rule0, m rule1)]
> > >  (rule-maker2 (+ n m)) rule3))
> >
> > > Into this (assume that conc-fn and conc-products are functions):
> >
> > > (fn [tokens]
> > >  (if-let [[remainder# n m] (conc-products [rule0 rule1] tokens)]
> > >(conc-fn [(rule-maker2 (+ n m)) rule3] remainder#)))
> > > ...but I can't figure out how to change [n rule0 m rule1] to (if-let
> > > [[remainder# n m] (conc-products [rule0 rule1] tokens)] ...).
> >
> > Try working it out outside of the macro context.
> >
> > (def bindvec '[n rule0, m rule1])
> >
> > Now you've got something to work with.  There are plenty of acceptible
> > answers.  Maybe you want to think of the vector as key/value pairs:
> >
> > (apply array-map bindvec)  ==> {n rule0, m rule1}
> > (keys (apply array-map bindvec))  ==> (n m)
> > (vals (apply array-map bindvec))  ==> (rule0 rule1)
> >
> > Or just use some seq function:
> >
> > (take-nth 2 bindvec)  ==> (n m)
> > (take-nth 2 (rest bindvec))  ==> (rule0 rule1)
> >
> > Once you've got the pieces you need, try sticking them into a
> > syntax-quote:
> >
> > user=> `(if-let [[r# ~(take-nth 2 bindvec)] (cp ~(take-nth 2 (rest
> > bindvec)))] ...)
> > (clojure.core/if-let [[r__215__auto__ (n m)] (user/cp (rule0 rule1))]
> ...)
> >
> > Well, that's close by there are extra parens around (n m) and you want
> > a vector not a list for the rules.  So play with it until it looks
> > right:
> >
> > user=> `(if-let [[r# ~@(take-nth 2 bindvec)] (cp ~(vec (take-nth 2
> > (rest bindvec] ...)
> > (clojure.core/if-let [[r__219__auto__ n m] (user/cp [rule0 rule1])] ...)
> >
> > Then you're ready to build the macro:
> >
> > (defmacro product-context [bindvec & body]
> >   `(fn [tokens#]
> >  (if-let [[remainder# ~@(take-nth 2 bindvec)]
> > (conc-products [~@(take-nth 2 (rest bindvec))] tokens#)]
> >(conc-fn [...@body] remainder#
> >
> > --Chouser
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Newbie: Separating and grouping the elements in a bunch of vectors

[David Nolen]

(map (fn [& rest] (apply vector rest)) [1 2 3] ['a 'b 'c] ["cat" "dog"
"bird"])

On Sun, Feb 15, 2009 at 7:16 PM, samppi  wrote:

>
> What would I do if I wanted this:
>
> [[a0 a1 a2] [b0 b1 b2] ...] -> [[a0 b0 ...] [a1 b1 ...] [a2 b2 ...]]
>
> I could write a loop, I guess, but is there a nice, idiomatic,
> functional way of doing this? I didn't spot a way in
> clojure.contrib.seq-utils either.
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Newbie: Separating and grouping the elements in a bunch of vectors

[David Nolen]

Actually something closer to your exact expression is this:

(apply (partial map (fn [& rest] (apply vector rest))) [[1 2 3] ['a 'b 'c]
["cat" "dog" "bird"]])

On Sun, Feb 15, 2009 at 7:42 PM, David Nolen  wrote:

> (map (fn [& rest] (apply vector rest)) [1 2 3] ['a 'b 'c] ["cat" "dog"
> "bird"])
>
>
> On Sun, Feb 15, 2009 at 7:16 PM, samppi  wrote:
>
>>
>> What would I do if I wanted this:
>>
>> [[a0 a1 a2] [b0 b1 b2] ...] -> [[a0 b0 ...] [a1 b1 ...] [a2 b2 ...]]
>>
>> I could write a loop, I guess, but is there a nice, idiomatic,
>> functional way of doing this? I didn't spot a way in
>> clojure.contrib.seq-utils either.
>> >>
>>
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Newbie: Separating and grouping the elements in a bunch of vectors

[David Nolen]

Of course ;) Keep forgetting the obvious things.

On Sun, Feb 15, 2009 at 9:36 PM, Stuart Halloway
wrote:

>
> (map vector [1 2 3] ['a 'b 'c] ["cat" "dog" "bird"])
> -> ([1 a "cat"] [2 b "dog"] [3 c "bird"])
>
> > Actually something closer to your exact expression is this:
> >
> > (apply (partial map (fn [& rest] (apply vector rest))) [[1 2 3] ['a
> > 'b 'c] ["cat" "dog" "bird"]])
> >
> > On Sun, Feb 15, 2009 at 7:42 PM, David Nolen
> >  wrote:
> > (map (fn [& rest] (apply vector rest)) [1 2 3] ['a 'b 'c] ["cat"
> > "dog" "bird"])
> >
> >
> > On Sun, Feb 15, 2009 at 7:16 PM, samppi  wrote:
> >
> > What would I do if I wanted this:
> >
> > [[a0 a1 a2] [b0 b1 b2] ...] -> [[a0 b0 ...] [a1 b1 ...] [a2 b2 ...]]
> >
> > I could write a loop, I guess, but is there a nice, idiomatic,
> > functional way of doing this? I didn't spot a way in
> > clojure.contrib.seq-utils either.
> >
> >
> >
> >
> > >
>
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

error-kit + test-is

[David Nolen]

I've been attempting to combine error-kit and test-is, but getting the
relation between assert-expr form in test-is and the handle form in
error-kit is a bit tricky. Looking at the test-is thrown? example and
Chouser's error-kit post on the mailing list I tried something like the
following:

(defmethod assert-expr 'raised? [msg form]
  (let [error-type (second form)
body (rrest form)]
`(with-handler
  (do
~...@body
(report :fail ~msg '~form nil))
  (handle {:keys [& rest#]}
  (let [tag# (last rest#)]
(println "raised!" rest# ~error-type)
(if (= ~error-type tag#)
  (report :pass ~msg '~form nil)
  (report :fail ~msg '~form nil)))

The assert-expr seems OK, but I can't seem to get the error-type tag from
handle.

So here's the promised feedback on handle Chouser ;)

David

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: ANN: clojure.contrib.error-kit

[David Nolen]

Would it be possible to make the arguments to handle be optional? Is this a
good or bad idea?

It seems to me, in the case of setting up test fixtures that check for
raised errors, often you don't care what arguments the error takes.

David

On Fri, Feb 6, 2009 at 9:10 PM, Chouser  wrote:

>  (kit/with-handler
>(vec (map int-half [2 4 5 8]))
>(kit/handle *odd-number-error* [n]
>  (throw (Exception. (format "Odd number %d in vector." n)
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Newbie: Separating and grouping the elements in a bunch of vectors

[David Nolen]

> I'm sure it can be done, but it's not clear to me if you have a vector of
> vectors
> how Stuart's solution would work:
>
> 1:15 user=> (map vector vecs)

([[:a0 :a1 :a2]] [[:b0 :b1 :b2]])


(apply (partial map vector) [[1 2 3] ['a 'b 'c] ["cat" "dog" "bird"]])

works on a vector of vectors. The OP wanted a vector of vectors as a result
where the subvector length is the same as the number of vectors originally
passed in.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: error-kit + test-is

[David Nolen]

(defmethod assert-expr 'raised? [msg form]
  (let [error-type (second form)
error-meta (meta (find-var (qualify-sym error-type)))
error-str  (str (ns-name (:ns error-meta)) "/" (:name error-meta))
body   (rrest form)]
`(with-handler
  (do
~...@body
(report :fail ~msg '~form (str ~error-str " not raised.")))
  (handle ~error-type {:as err#}
(if (= (:tag err#) (symbol ~error-str))
  (report :pass ~msg '~form nil)
  (report :fail ~msg '~form (str ~error-str " was raised."
  (handle *error* {:as err#}
(report :fail ~msg '~form (:tag err#))

Here is the macro that seems to work, any improvements much appreciated ;)
This fails when no error is raised, when the wrong error type is raised, and
I believe it's captures errors which are derived but not the exact error (is
this a weird behavior?).  Your previous post about error-kit got me on the
right track. I can now define test cases like so:

(deftest test-verify-slots
  (is (verify-slots [[:origin [0 0]] :width :height]))
  (is (raised? *malformed-slots-error* (verify-slots [[:origin] :width
:height])))
  (is (raised? *malformed-slots-error* (verify-slots [[:origin 0 0] :width
:height])))

Much nicer than those ugly Java Exceptions, no? ;)

On a last note, I've found your qualify-sym fn quite handy and have been
using it elsewhere ;)


On Sun, Feb 15, 2009 at 11:52 PM, Chouser  wrote:

>
> On Sun, Feb 15, 2009 at 10:06 PM, David Nolen 
> wrote:
> > I've been attempting to combine error-kit and test-is, but getting the
> > relation between assert-expr form in test-is and the handle form in
> > error-kit is a bit tricky. Looking at the test-is thrown? example and
> > Chouser's error-kit post on the mailing list I tried something like the
> > following:
> >
> > (defmethod assert-expr 'raised? [msg form]
> >   (let [error-type (second form)
> > body (rrest form)]
> > `(with-handler
> >   (do
> > ~...@body
> > (report :fail ~msg '~form nil))
> >   (handle {:keys [& rest#]}
> >   (let [tag# (last rest#)]
> > (println "raised!" rest# ~error-type)
> > (if (= ~error-type tag#)
> >   (report :pass ~msg '~form nil)
> >   (report :fail ~msg '~form nil)))
> >
> > The assert-expr seems OK, but I can't seem to get the error-type tag from
> > handle.
> >
> > So here's the promised feedback on handle Chouser ;)
>
> Thanks!  You're a brave man for trying such a thing, when error-kit
> has such thin documentation.
>
> I think there are a couple problems.  One is your attempt at using &
> in a :keys destructuring expression.  It amounts to something like:
>
> (let [{:keys [& etc]} {:a 1, :b 2}]
>  etc)
> -> nil
>
> You may want to use {:as err-map#} instead, and then pick out the :tag
> from the err-map# later.  Or perhaps simply insert the ~error-type
> there directly.
>
> Another issue is that what is stored in the err-map's :tag value is
> the fully-qualified symbol of the error, not the value of that symbol
> (which happens to be the fn used to construct it) which is what your
> ~error-type would evaluate to.  I know it's confusing, but it's how it
> had to be, since I need the name and functions don't really have names.
>
> To make things worse, getting the fully-qualified name from the macro
> argument, which is likely a symbol with a nil namespace, is a bit of a
> trick.  error-kit/qualify-sym does this, but it's currently private.
> It may make sense to make that public for just the kind of shenanigans
> you're trying to pull.
>
> If this has been to dense or sketchy, let me know and I'll see if I
> can help you further.  This is exactly the kind of thing error-kit
> needs to be able to do.
>
> --Chouser
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: error-kit + test-is

[David Nolen]

Heh not macro, I meant multimethod.

Here is the macro that seems to work, any improvements much appreciated ;)
> This fails when no error is raised, when the wrong error type is raised, and
> I believe it's captures errors which are derived but not the exact error (is
> this a weird behavior?).  Your previous post about error-kit got me on the
> right track. I can now define test cases like so:
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: error-kit + test-is

[David Nolen]

> I don't quite understand why you got through all that work to get
> error-str -- isn't it just (str (qualify-sym error-type))?
>
> ...and since you then use it only as an arg to 'symbol' or 'str', you
> could just use the symbol itself instead of converting it to a string
> and back.
>

If I bring the symbol back directly, it gets evaluated to the actual error
object and not the symbol.  I want to compare symbols. Or maybe I don't,
comparing symbols in general seems simpler for meta-hacky stuff like this.


>
>
> > This fails when no error is raised, when the wrong error type is raised,
> and
> > I believe it's captures errors which are derived but not the exact error
> (is
> > this a weird behavior?).
>
> I'm not sure, but I think you'd want to allow an implementation to
> change to a derived error type without breaking the tests.  But I
> could be wrong -- it should probably behave the same as the 'throws?'
> method, since Java Exceptions also do inheritance.
>

Good point. Easy enuf.


>
>
> > Much nicer than those ugly Java Exceptions, no? ;)
>
> Sure, looks good to me.  Would it ever be useful to test that the
> error has a particular set of arguments?  I guess that may be more
> detailed than any test would want to get.
>

Possibly, but I can't think of a really goo reason for this yet.


> It would also be interesting to try to test for the existence and
> behavior of any 'continue' forms.
>

Very interesting, I haven't got to continue yet, baby steps here.


>
>
> Really!?  I'd never needed it before error-kit, and I'm pretty
> suspicious of needing it even there.  I think I'd rather just use Vars
> for error tags, but they're not currently allowed in the Clojure
> inheritance hierarchies.  If Vars were Named, I think it would work,
> and it's not at all clear to me why they aren't, since they have a
> namespace and a name just like symbols and keywords do.  Rich is
> probably too busy with lazier just now, but I intend to be annoying
> about this at some later date.
>

That's the proper solution. Until then for really wacky stuff, I don't know
how to do certain things without qualify-sym.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Fully lazy sequences are coming - feedback wanted!

[David Nolen]

> butlast, doall, dorun, doseq, dosync, dotimes, doto, fnseq, gensym,
> macroexpand, macroexpand-1, mapcat, nthrest
>
>
-1

Because they are similar to other Lisps I assume.  The same reason for
println vs print-line. Changing these are a bad idea in IMHO.

Breaking the meaning of rest with Common Lisp is a consideration to take
seriously.  However as long as the documentation clearly states (highlights
in big bold colors ;) this difference (and the fact the operation is support
by next) then I think this is a change people can live with.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: compiling a GUI app and also: interference of Java's built-in architechture

[David Nolen]

On Mon, Feb 16, 2009 at 10:27 AM, rob levy  wrote:

> So if I am right about these two facts, it seems like Clojure should
> include a native way of making applets/applications that both enables the
> truly functional style that Clojure is built on, and doesn't require writing
> Java to call it (it seems like Clojure should replace Java, not perpetuate
> it, other than to build on its vast libraries, IMHO).  What do you think
> (and is there something I'm understanding wrong here)?
>

Someone correct me if I'm way off, but User Interfaces are by definition
very mutation heavy.  It has come up before that Clojure's emphasis on
immutability is a tool not a religious decree.  Mutation is fine, just don't
mindlessly sprinkle it all over your program.  Even a language like Haskell
(which I know very little about) needs special constructs for IO. But this
is exactly what your example illustrates! mouse -> I, screen -> O.
Mutability sneaks in ;)

Of course it would be interesting to see a UI framework that is more
functional, but having done a considerable amount of UI programming this
seems to me like mostly a waste of time.

Instead of dictating, Clojure simply encourages you to reflect on whether
you really need mutation. If you absolutely need mutation, Clojure isn't
going to stop you.  And that's a great thing.

David

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: error-kit + test-is

[David Nolen]

(defmethod assert-expr 'raised? [msg [_ error-type & body :as form]]
 (let [error-name (qualify-sym error-type)]
   `(with-handler
  (do
~...@body
(report :fail ~msg '~form ~(str error-name " not raised.")))
  (handle ~error-type {:as err#}
  (report :pass ~msg '~form nil))
  (handle *error* {:as err#}
(report :fail ~msg '~form (:tag err#))

You're right I think the entire first handle statement was wrong.  I believe
handle does the isa? check on the error type, correct? If so then this will
allow inherited error types to pass the test.

Many, many thanks for the feedback.

test-is + error-kit is a great combo.

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Idiomatic Way to Write the Following:

[David Nolen]

Is using subvec for something like this a bad idea?

On Wed, Feb 18, 2009 at 12:38 AM, CuppoJava wrote:

>
> Hi,
> I'm wondering if there's a terser more idiomatic way to write the
> following. I want to get a new vector with the specified indexes
> removed. I found myself doing this often enough to warrant writing my
> own function for this but I would be much happier if there's some
> terse way of expressing this using the standard clojure functions.
>
> (defn remove_at [coll & indexes]
>  (map second
>   (remove #(some #{(first %)} indexes) (map vector (iterate inc
> 0) coll
>
> Thanks a lot
>  -Patrick
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Performance of (fn [] ...)?

[David Nolen]

new MBP 2.53ghz

(defn create-fn []
  (fn [] (println "hi")))

(time (dotimes [x 4000]
(create-fn)))

> "Elapsed time: 1034.409 msecs"

Hopefully you don't need 40,000,000 functions in less than a second ;)

On Wed, Feb 18, 2009 at 1:16 AM, CuppoJava wrote:

> (defn create_fn []
>  (fn [] (println "hi")))
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Idiomatic Way to Write the Following:

[David Nolen]

My point was that you could use subvec to do vector splicing and build your
remove function off of that.  I'm sure the more experienced Clojurians can
chime in on what is the most idiomatic form.

On Wed, Feb 18, 2009 at 1:10 AM, CuppoJava wrote:

>
> Mmm, subvec doesn't quite seem to do the same thing.
>
> I want a function that removes certain indexes of a vector:
> eg. (remove_at [1 2 3 4 5 6] 0 3) => [2 3 5 6]
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: how to learn clojure ?

[David Nolen]

Practical Common Lisp is also online and free. Though there are significant
differences between the two languages many of the strange and beautiful
concepts that Clojure embraces are covered there.  Especially dynamic
variables, macros, destructuring bind, and multiple dispatch.
On Wed, Feb 18, 2009 at 7:53 AM, MarisO  wrote:

>
> All documentation I've seen about clojure assumes knowledge of lisp
> which I dont have.
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: bug affecting clojure.core/bean?

[David Nolen]

If I've been following things correct:
rest _used_ to force the seq, it does no longer.
next forces the seq

In my own mind i'm thinking next to mean (return the seq with the next value
computed), rest now means just give me the uncomputed remaining values of
the seq.

On Wed, Feb 18, 2009 at 12:00 PM, Laurent PETIT wrote:

>
>
> 2009/2/18 Mark Volkmann 
>
>
>> On Wed, Feb 18, 2009 at 10:27 AM, Rich Hickey 
>> wrote:
>> >
>> > On Feb 18, 11:04 am, Chouser  wrote:
>> >> On Wed, Feb 18, 2009 at 12:35 AM, Rob  wrote:
>> >>
>> >> > I'm wondering if I found a bug.  I have the latest source from svn
>> >> > (r1291).
>> >>
>> >> > user=> (bean 1)
>> >> > java.lang.IllegalArgumentException: Wrong number of args passed to:
>> >> > core$bean--5161$fn--5179$thisfn
>> >>
>> >> You sure did.  The conversion to lazy-seq code appears to introduce a
>> >> paren typo and an incorrect nil pun.  Patch attached.
>> >>
>> >
>> > Patch applied, svn 1293 - thanks!
>> >
>> >> Rich, I think it'd be pretty useful to have as you mentioned in IRC a
>> >> variant of & destructuring that provided an unforced lazy-seq.  It
>> >> seems pretty common to want, in the body of a lazy-seq, a destructured
>> >> 'first' but an unforced 'rest'.  This is already the third or fourth
>> >> time I've wanted to be able to do something like:
>> >>
>> >>   (fn thisfn [plseq]
>> >> (lazy-seq
>> >>   (when-let [[pkey &rest etc] plseq]
>> >> (cons (new clojure.lang.MapEntry pkey (v pkey))
>> >>   (thisfn etc)
>> >>
>> >
>> > Yes, sure. It just comes down to the name:
>> >
>> > &rest
>> > &&
>> >
>> > others?
>>
>> Of those I prefer &rest because its meaning is more explicit.
>
>
> Maybe I miss the point totally, but didn't the recent change give the
> function 'next the meaning of not forcing the seq ?
>
> So &next instead of &rest ? ... and maybe either &rest or &next , and not
> just & anymore ?
>
>
>>
>>
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>>
>>
>>
>
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: how to learn clojure ?

[David Nolen]

Of course I beg to differ.  The Stuart Halloway's book is fantastic of
course, I have it myself.  It's absolutely required reading.  Stuart does
his best to describe the ins and outs of the language while giving a crash
course on the Lisp philosophy.  And yes Clojure is syntactically different
from Scheme and Common Lisp, however many of the non-Clojure texts suggested
do a better job explaining the deeper why's of Lisp programming, concepts
that go beyond the particular implementation.  In fact I would probably
recommend the Structure and Interpretation of Computer Programs as the
indispensable Lisp text above all others.
But thats just MHO.

David

On Thu, Feb 19, 2009 at 8:46 AM, Rayne  wrote:

>
> Telling someone to read a book that isn't even focused on the language
> he's trying to learn isn't a great way to help them. Tell him to read
> Programming Clojure or something, anything but Common Lisp and Scheme
> books, he isn't learning those languages he's learning Clojure. There
> is enough information around on Clojure that someone shouldn't be
> forced to read a book on a completely different language.
>
> No offense guys.
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: how to learn clojure ?

[David Nolen]

>
> No offense here to Lispers but when I learn a new language, I try to learn
> it as it is and I make parallels
> and connections with what I know at the moment. Otherwise you end up
> learning more than one thing
> at the same time and it can get quite confusing.
>
> If your experience is made mostly of  "conventional" languages this path
> should be easier.
> After that if you are curious you can give a closer look to the Lisp
> heritage.
>
> Luc
>

No arguments with most of what you say of course. However I'm not sure what
I used to know from "conventional" languages helps much with concepts like
macros or dynamic vars or multimethods.  In fact most of my time learning
Lisp has been like "Holy ! If only I had this tool/concept 4 years ago!
I've been swindled!" ;)

David

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: how to learn clojure ?

[David Nolen]

Great list.

On Thu, Feb 19, 2009 at 11:39 AM, Stuart Halloway  wrote:

>
> Thanks for the kind words, David. I hope many people will like
> Programming Clojure and find it useful.
>
> Clojure has a *ton* of goodness in it. I think many of the chapters in
> Programming Clojure book could usefully be followed with an entire
> book. Here is a partial list of recommendations for companion reading:
>
> For Java Interop:
> * The JVM spec (free online). Know your platform. :-)
>
> For Functional Programming:
> * Real World Haskell (free online)
>
> For Concurrency:
> * Java Concurrency in Practice
>
> For Macros:
> * On Lisp (free online)
>
> For Lisp in General:
> * Practical Common Lisp (free online)
> * Paradigms of AI Programming
>
> For Multimethods:
> * The Art of the Metaobject Protocol
>
> Just Because:
> * Structure and Interpretation of Computer Programs
>
> Cheers,
> Stuart
>
> > Of course I beg to differ.  The Stuart Halloway's book is fantastic
> > of course, I have it myself.  It's absolutely required reading.
> > Stuart does his best to describe the ins and outs of the language
> > while giving a crash course on the Lisp philosophy.  And yes Clojure
> > is syntactically different from Scheme and Common Lisp, however many
> > of the non-Clojure texts suggested do a better job explaining the
> > deeper why's of Lisp programming, concepts that go beyond the
> > particular implementation.  In fact I would probably recommend the
> > Structure and Interpretation of Computer Programs as the
> > indispensable Lisp text above all others.
> >
> > But thats just MHO.
> >
> > David
> >
> > On Thu, Feb 19, 2009 at 8:46 AM, Rayne 
> > wrote:
> >
> > Telling someone to read a book that isn't even focused on the language
> > he's trying to learn isn't a great way to help them. Tell him to read
> > Programming Clojure or something, anything but Common Lisp and Scheme
> > books, he isn't learning those languages he's learning Clojure. There
> > is enough information around on Clojure that someone shouldn't be
> > forced to read a book on a completely different language.
> >
> > No offense guys.
> >
> >
> >
> > >
>
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Error Handling paradigms in Clojure

[David Nolen]

Check out Chouser's error-kit in clojure-contrib. It borrows from the
condition/restart system of Common Lisp.

On Thu, Feb 19, 2009 at 5:25 PM, levand  wrote:

>
> So, my project is reaching a sufficient level of complexity where I
> really need good error tracking - when something goes wrong, I need to
> know exactly what it was.
>
> I have programmed in Java for a long time, and my first instinct is to
> simply use the try and throw special forms more or less as I would in
> Java, even though the code in question is mostly pure Clojure without
> directly utilizing any Java classes. I would simply throw whenever I
> have an unexpected condition, and somewhere higher up the stack, where
> it is easy to deal with it, I would log it and either try to recover
> or present an error message.
>
> However, in most other areas, once I've finally grokked the functional
> practice for just about anything, I much prefer it to the Java way of
> life.
>
> So, I guess my question is, is using try/throw this way in Clojure
> considered good Clojure code, or are they there mostly for Java
> interop? Is there a more Lispy/functional way to do it?
>
> Many thanks,
> -Luke
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: structmap instance test

[David Nolen]

This not hard to implement. This exactly what Spinoza does. Feel free to
lift any of my code.

On Sat, Feb 21, 2009 at 9:08 AM, Mark Volkmann wrote:

>
> Is there a way to test whether a given object is an instance of a
> given structmap?
> For example,
>
> (defstruct dog-struct :name :breed)
>
> (def my-dog (struct dog-struct "Dasher" "whippet"))
>
> (when (some-function my-dog dog-struct)
>  (println "It's a dog!"))
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: structmap instance test

[David Nolen]

For example, with Spinoza:

(def my-circle (make-instance circle))
(instance-of? my-circle circle) ; > true

circle is just a struct.

On Sat, Feb 21, 2009 at 2:09 PM, David Nolen  wrote:

> This not hard to implement. This exactly what Spinoza does. Feel free to
> lift any of my code.
>
>
> On Sat, Feb 21, 2009 at 9:08 AM, Mark Volkmann 
> wrote:
>
>>
>> Is there a way to test whether a given object is an instance of a
>> given structmap?
>> For example,
>>
>> (defstruct dog-struct :name :breed)
>>
>> (def my-dog (struct dog-struct "Dasher" "whippet"))
>>
>> (when (some-function my-dog dog-struct)
>>  (println "It's a dog!"))
>>
>> --
>> R. Mark Volkmann
>> Object Computing, Inc.
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: generic functions update

[David Nolen]

I'm interested as well.
On Sat, Feb 21, 2009 at 3:03 PM, Dan Larkin  wrote:

>
> On Feb 21, 2009, at 2:23 PM, mikel wrote:
>
>
>
> If there's interest in having models and generic functions in contrib,
> I'll get a contributor agreement to Rich.
>
>
> Aye there is, from me at least.
>
>
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Clojure Naming Conventions

[David Nolen]

+name+ is also in line with Common Lisp patterns
http://www.cliki.net/Naming%20conventions
On Sat, Feb 21, 2009 at 4:07 PM, Luc Prefontaine <
lprefonta...@softaddicts.ca> wrote:

>  In our software, we use uppercase or +name+ as constant names.
> Both Java and RUBY use uppercase, I think it's more a matter of taste what
> you decide to use.
> Ideally it should be obvious by looking at the name that some name is a
> constant name.
>
> Both of the above satisfy this criteria.
>
> Luc
>
> On Sat, 2009-02-21 at 12:47 -0800, Howard Lewis Ship wrote:
>
> I'm kind of used to Java nowadays, where CONSTANTS_ARE_UPPERCASE.  I'mtrying 
> to figure out if Clojure has equivalent conventions.
> What I've seen:
> names-with-dashes instead of CamelCase*global* for global variables 
> (?)Parameter name conventions (from Stu's book): val, coll, a, etc.
> What are the accepted conventions?
>
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Clojure Naming Conventions

[David Nolen]

The fact that the Clojure data structures are immutable and that some of
those data structures might be used logically constants are two separate
concerns.  When reading Clojure code, we've already internalized the fact
that the data structures are immutable.  Using a naming convention for a
constant just simply marks clearly the intended use.
On Sat, Feb 21, 2009 at 4:29 PM, Phil Hagelberg  wrote:

>
> Mark Volkmann  writes:
>
> > As best I can tell Clojure doesn't have a convention for constant names.
>
> Everything that's not expected to be rebound at runtime
> (*special-variables*) is by definition a constant (with the exception of
> refs, agents, and atoms). You don't need a special "constant naming
> convention". Perhaps some kind of convention for naming non-constants
> would be more appropriate since they're the exception rather than the
> rule, but I don't know of any such convention. The fact that those
> identifiers are always prefixed with @ for deref'ing them may be enough.
>
> -Phil
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Clojure Naming Conventions

[David Nolen]

My point is simply that whether something is immutable or not has nothing to
do with how that data structure is being used in the program.  Naming
conventions signify usage.  You could write a pure Java program and make it
pretty darn functional. You would still want to mark values that are
logically treated as constants as such.
And I don't things are not so different in Clojure. In many programs you
will create structures for the intention of changing them. This is I think
Rich's point about separating state and identity.  Yes data structures are
immutable, but vars help the programmer wrap their head around the
identities.

vars in Clojure are a tool for reasoning about a program that uses immutable
data structures.

And using a naming convention for vars that represent constants is yet
another tool for reasoning about the program.

On Sat, Feb 21, 2009 at 5:24 PM, Phil Hagelberg  wrote:

>
> David Nolen  writes:
>
> > The fact that the Clojure data structures are immutable and that some
> > of those data structures might be used logically constants are two
> > separate concerns.
>
> I don't understand what this means. What's the difference between using
> a value that doesn't change and using a value as a logical constant? Are
> you talking about changing the value of a var by calling "def" on it
> again instead of using "binding"?
>
> -Phil
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: dotimes suggestion

[David Nolen]

(defmacro again [n & body]
  `(dotimes [~'_ ~n] ~...@body))

(again 3 (println "Ho"))

On Sat, Feb 21, 2009 at 5:51 PM, samppi  wrote:

>
> For now, I do:
> (dotimes [_ 3] (print "Ho"))
>
> But I also think it would be a nice, natural addition.
>
> On Feb 21, 3:07 pm, Timothy Pratley  wrote:
> > +1
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: arguments to dissoc and select-keys

[David Nolen]

dissoc is like assoc.
If you want to use collections with dissoc you can always use apply. It's
not too much to type:

(def my-map {:first "Bob", :middle "Joe", :last "Smith"})
(apply dissoc my-map [:first :middle])

On Sat, Feb 21, 2009 at 5:58 PM, samppi  wrote:

>
> Allowing dissoc and select-keys to accept both keys as arguments and
> as a collection would be nice, and backwards compatible. In any case,
> ostensibly it should be consistent; otherwise, it's just an
> idiosyncrasy in the language that people will have to deal with. I
> wonder what the reasoning is behind it, or if it was completely
> arbitrary.
>
> On Feb 21, 1:28 pm, Mark Volkmann  wrote:
> > (def popsicle-map {:red :cherry, :green :apple, :purple :grape})
> >
> > ; Note how the keys passed to dissoc are individual arguments.
> > (dissoc popsicle-map :green :blue) ; -> {:red :cherry, :purple :grape}
> >
> > ; Note how the keys passed to select-keys are in a vector, not
> > individual arguments.
> > (select-keys popsicle-map [:red :green :blue]) ; -> {:green :apple,
> > :red :cherry}
> >
> > I wonder why these were implemented differently. Maybe both dissoc and
> > select-keys should accept both individual key arguments and a sequence
> > of keys.
> >
> > --
> > R. Mark Volkmann
> > Object Computing, Inc.
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: arguments to dissoc and select-keys

[David Nolen]

Oops, sorry. It seems weird to me that a function called select-keys would
take a single parameter and not a vector. Also, as you said, this does seem
like it would require some kind of check which would probably not worth the
tradeoff. Why not write a function called select-key that does what you
want?
On Sat, Feb 21, 2009 at 6:24 PM, Mark Volkmann wrote:

>
> On Sat, Feb 21, 2009 at 5:07 PM, David Nolen 
> wrote:
> > dissoc is like assoc.
> > If you want to use collections with dissoc you can always use apply. It's
> > not too much to type:
> > (def my-map {:first "Bob", :middle "Joe", :last "Smith"})
> > (apply dissoc my-map [:first :middle])
>
> I think you misunderstood what I want. I want to be able to pass
> individual keys to select-keys. I'm not looking for a way to pass
> collections of keys to dissoc and assoc.
>
> My guess is that this inconsistency was purely accidental and could be
> fixed so select-keys also accepts individual key arguments.
>
> > On Sat, Feb 21, 2009 at 5:58 PM, samppi  wrote:
> >>
> >> Allowing dissoc and select-keys to accept both keys as arguments and
> >> as a collection would be nice, and backwards compatible. In any case,
> >> ostensibly it should be consistent; otherwise, it's just an
> >> idiosyncrasy in the language that people will have to deal with. I
> >> wonder what the reasoning is behind it, or if it was completely
> >> arbitrary.
> >>
> >> On Feb 21, 1:28 pm, Mark Volkmann  wrote:
> >> > (def popsicle-map {:red :cherry, :green :apple, :purple :grape})
> >> >
> >> > ; Note how the keys passed to dissoc are individual arguments.
> >> > (dissoc popsicle-map :green :blue) ; -> {:red :cherry, :purple :grape}
> >> >
> >> > ; Note how the keys passed to select-keys are in a vector, not
> >> > individual arguments.
> >> > (select-keys popsicle-map [:red :green :blue]) ; -> {:green :apple,
> >> > :red :cherry}
> >> >
> >> > I wonder why these were implemented differently. Maybe both dissoc and
> >> > select-keys should accept both individual key arguments and a sequence
> >> > of keys.
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: arguments to dissoc and select-keys

[David Nolen]

>
> On Feb 21, 5:58 pm, samppi  wrote:
> > Allowing dissoc and select-keys to accept both keys as arguments and
> > as a collection would be nice, and backwards compatible.
>
> Nope - Collections can be keys.


Ah the power of Clojure ;) The fact that (almost?) anything can be a key is
a pretty liberating thing.

David

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Re: Clojure Naming Conventions

[David Nolen]

Thanks for the points.
What I was thinking, was that for things like π, in Clojure (as in CL),
perhaps it makes to sense to mark it like so:

+pi+

On Sat, Feb 21, 2009 at 8:59 PM, Chouser  wrote:

>
> On Sat, Feb 21, 2009 at 5:36 PM, David Nolen 
> wrote:
> > My point is simply that whether something is immutable or not has nothing
> to
> > do with how that data structure is being used in the program.
> > Naming conventions signify usage.  You could write a pure Java
> > program and make it pretty darn functional. You would still want to
> > mark values that are logically treated as constants as such.
>
> Most named Vars are given a single value and this is never changed at
> all.  They are created with 'def' or some variation thereof, and then
> examined in various ways, but not given new values.  They are constant
> and they are named in the normal Clojure way: lowercase with dashes.
>
> Sometimes these Vars are changed later with another 'def', but this is
> meant to be a development or debugging technique, not something that
> should be incorporated into normal program logic.  Anticipating this
> kind of change (or not) shouldn't influence the name of the Var.
>
> Some named Vars are expected to be given a thread-local value with
> 'binding', and in even more rare cases then adjusted using 'set!'.
> This usage is unusual enough that the names of such Vars warrant the
> *earmuffs*.
>
> Even less commonly than any of the above is changing a Var's root
> value with 'alter-var-root'.  This is perhaps unusual enough that it
> warrants a naming convention to indicate that this particular Var will
> actually be non-constant at its root.
>
> Is there some other distinction that needs to be made?  Does logically
> constant mean something different from what I've described above?
>
> --Chouser
>
> >
>

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---