Re: [ANN] Instaparse 1.0.0

[Tassilo Horn]

Mark Engelberg  writes:

Hi Mark,

> Example:
>
> (def as-and-bs
>   (parser
> "S = AB*
>  AB = A B
>  A = 'a'+
>  B = 'b'+"))

Nice, but providing the grammar as a plain string looks somewhat
unnatural to me.  Why not something like this (parser being a macro)?

(def as-and-bs
  (parser
S  = AB* .
AB = A B .
A  = "a" + .
B  = "b" + .))

I.e., symbols denote non-terminals, strings denote terminals, and the
dot indicates the end of a rule.

Bye,
Tassilo

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Something goofy you can do in Clojure.

[Cedric Greevey]

This may look mildly surprising, and suggests one more thing *not* to ever
do in production code:

user=> (+ .3 1.7)
2.1
user=>

:)

Shouldn't be hard to figure out how to put a repl in a state where that
expression will evaluate to that result. I'm sure mathematicians everywhere
are deeply offended by the clojure reader now. :)

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Opinions on Equality Semantics

[Tassilo Horn]

JvJ  writes:

> This is just an idle curiosity up for discussion, but in Clojure, if
> (= a b) is true, then given some function f, it is not necessarily
> true that (= (f a) (f b))

I think this axiom isn't true in any language.  Take `str` / toString()
as an example.  If that statement was true, then equal objects would
need to have equal string representations.  Then you either couldn't
have 1 and 1.0 be equal, or you would need to print all numbers as
floats.  An even better counter example are sets versus sorted sets.

Bye,
Tassilo

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Instaparse 1.0.0

[Mark Engelberg]

On Tue, Apr 9, 2013 at 1:33 AM, Tassilo Horn  wrote:

> Nice, but providing the grammar as a plain string looks somewhat
> unnatural to me.  Why not something like this (parser being a macro)?
>
> (def as-and-bs
>   (parser
> S  = AB* .
> AB = A B .
> A  = "a" + .
> B  = "b" + .))
>
> I.e., symbols denote non-terminals, strings denote terminals, and the
> dot indicates the end of a rule.
>
> Bye,
> Tassilo
>

I played around with that, but even if you suppress evaluation by using a
macro, Clojure's reader makes strong assumptions about certain symbols.
For example, it is standard in EBNF notation for {} to mean zero-or-more.
But if you include {A B C} in your grammar using the macro approach,
Clojure's reader will throw an error because it treats {} as a map and
expects an even number of forms to follow.  That was the main reason, but
it also makes the notation much more sensitive to whitespace (for example,
AB * versus AB*).  Gradually, those little issues start making it look less
and less like traditional notation.  There's something really nice about
just being able to copy and paste a grammar off of a website and have it
just work.

I understand where you're coming from, though.  It definitely is part of
the Clojure culture to avoid string representations for many kinds of data
(e.g., SQL queries).  We do accept it for regular expressions, and for
things like #inst "2011-12-31T19:00:00.000-05:00", though, and that's the
kind of feel I was going for.  Would it be more psychologically palatable
to type:
#insta/parser "S = 'a' 'b'"
rather than
(insta/parser "S = 'a' 'b'")
?

What do you think would be gained by making it a macro?  From my
perspective, a macro is essentially just a string that is being processed
by the Clojure reader (and thus subject to its constraints).  If the
grammar were expressed in the way you propose, is it any easier to build up
a grammar programmatically?  Is it any easier to compose grammars?  If
anything, I think it might be harder.

Thanks for the comments,

Mark

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Something goofy you can do in Clojure.

[Mark Engelberg]

What version are you running?

As far as I know, .3 isn't even a valid representation for a number --
you'd have to write it as 0.3.  So I'm not sure where you're running that
code snippet such that you don't get an immediate error.

On 1.5.1:

=> (+ 0.3 1.7)
2.0

That said, I think most programmers know that floating point
representations of numbers are inexact.  That's why, if you care about
exactness, you should write:

=> (+ 0.3M 1.7M)
2.0M

On Tue, Apr 9, 2013 at 1:53 AM, Cedric Greevey  wrote:

> This may look mildly surprising, and suggests one more thing *not* to ever
> do in production code:
>
> user=> (+ .3 1.7)
> 2.1
> user=>
>
> :)
>
> Shouldn't be hard to figure out how to put a repl in a state where that
> expression will evaluate to that result. I'm sure mathematicians everywhere
> are deeply offended by the clojure reader now. :)
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Something goofy you can do in Clojure.

[Jim foo.bar]

Hey Mark, don't get paranoid :)... this is all Cedric did!

user=> (def .3 0.4)
#'user/.3
user=> (+ .3 1.7)
2.1

Jim



On 09/04/13 10:46, Mark Engelberg wrote:

What version are you running?

As far as I know, .3 isn't even a valid representation for a number -- 
you'd have to write it as 0.3.  So I'm not sure where you're running 
that code snippet such that you don't get an immediate error.


On 1.5.1:

=> (+ 0.3 1.7)
2.0

That said, I think most programmers know that floating point 
representations of numbers are inexact.  That's why, if you care about 
exactness, you should write:


=> (+ 0.3M 1.7M)
2.0M

On Tue, Apr 9, 2013 at 1:53 AM, Cedric Greevey > wrote:


This may look mildly surprising, and suggests one more thing *not*
to ever do in production code:

user=> (+ .3 1.7)
2.1
user=>

:)

Shouldn't be hard to figure out how to put a repl in a state where
that expression will evaluate to that result. I'm sure
mathematicians everywhere are deeply offended by the clojure
reader now. :)

-- 
-- 
You received this message because you are subscribed to the Google

Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com

Note that posts from new members are moderated - please be patient
with your first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com

For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to clojure+unsubscr...@googlegroups.com
.
For more options, visit https://groups.google.com/groups/opt_out.



--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient 
with your first post.

To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google 
Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to clojure+unsubscr...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.




--
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups "Clojure" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Something goofy you can do in Clojure.

[Niels van Klaveren]

In Clojure 1.5.1:

=> (+ .3 1.7)
CompilerException java.lang.RuntimeException: Unable to resolve symbol: .3 
in this context, compiling:(NO_SOURCE_PATH:1:1) 

So the only way you can do this is if you def'd .3 before

=> (def .3 0.4)
=> (+ .3 1.7)
2.1

On Tuesday, April 9, 2013 10:53:06 AM UTC+2, Cedric Greevey wrote:
>
> This may look mildly surprising, and suggests one more thing *not* to ever 
> do in production code:
>
> user=> (+ .3 1.7)
> 2.1
> user=>
>
> :)
>
> Shouldn't be hard to figure out how to put a repl in a state where that 
> expression will evaluate to that result. I'm sure mathematicians everywhere 
> are deeply offended by the clojure reader now. :)
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Instaparse 1.0.0

[Philipp Meier]

Am Dienstag, 9. April 2013 11:41:38 UTC+2 schrieb puzzler:
>
> On Tue, Apr 9, 2013 at 1:33 AM, Tassilo Horn  >wrote:
>
>> Nice, but providing the grammar as a plain string looks somewhat
>> unnatural to me.  Why not something like this (parser being a macro)?
>>
>> (def as-and-bs
>>   (parser
>> S  = AB* .
>> AB = A B .
>> A  = "a" + .
>> B  = "b" + .))
>>
>>
> I played around with that, but even if you suppress evaluation by using a 
> macro, Clojure's reader makes strong assumptions about certain symbols.  
> For example, it is standard in EBNF notation for {} to mean zero-or-more.  
> But if you include {A B C} in your grammar using the macro approach, 
> Clojure's reader will throw an error because it treats {} as a map and 
> expects an even number of forms to follow.  That was the main reason, but 
> it also makes the notation much more sensitive to whitespace (for example, 
> AB * versus AB*).  Gradually, those little issues start making it look less 
> and less like traditional notation.  There's something really nice about 
> just being able to copy and paste a grammar off of a website and have it 
> just work.
>
>
What about something like this, a little like enlive does encode selectors?

 (insta/parser :S [:AB :*] :AB [:A :B] :A ["a" :*] :B ["b" :*])

-billy.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Instaparse 1.0.0

[Mark Engelberg]

On Tue, Apr 9, 2013 at 2:41 AM, Mark Engelberg wrote:

> What do you think would be gained by making it a macro?  From my
> perspective, a macro is essentially just a string that is being processed
> by the Clojure reader (and thus subject to its constraints).  If the
> grammar were expressed in the way you propose, is it any easier to build up
> a grammar programmatically?  Is it any easier to compose grammars?  If
> anything, I think it might be harder.
>
>
I should also point out, for anyone who hasn't had a chance to read through
the tutorial, that instaparse does include a combinator interface that lets
you build the parsers entirely through functions.   The way I look at it is
that if you're going for human writing and readability, it's hard to beat
strings (or reading from a resource file), and if you're going for a
grammar that will be generated by a program, it's hard to beat functions.
So both are included.  But targeting some sort of functional-ish looking
thing that doesn't look quite right and doesn't compose effectively -- that
doesn't seem to serve either purpose well.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Something goofy you can do in Clojure.

[Gary Verhaegen]

Technically, this is a user error, since . (dot) is not a valid character
inside user-defined symbols. Clojure does mostly take the stance that it is
a sharp tool and you are allowed to cut yourself, should you really want to.

See http://clojure.org/reader for reference, especially these two sentences
:

"Symbols begin with a non-numeric character and can contain alphanumeric
characters and *, +, !, -, _, and ?"
"Symbols beginning or ending with '.' are reserved by Clojure."


On 9 April 2013 11:51, Niels van Klaveren wrote:

> In Clojure 1.5.1:
>
> => (+ .3 1.7)
> CompilerException java.lang.RuntimeException: Unable to resolve symbol: .3
> in this context, compiling:(NO_SOURCE_PATH:1:1)
>
> So the only way you can do this is if you def'd .3 before
>
> => (def .3 0.4)
> => (+ .3 1.7)
> 2.1
>
>
> On Tuesday, April 9, 2013 10:53:06 AM UTC+2, Cedric Greevey wrote:
>>
>> This may look mildly surprising, and suggests one more thing *not* to
>> ever do in production code:
>>
>> user=> (+ .3 1.7)
>> 2.1
>> user=>
>>
>> :)
>>
>> Shouldn't be hard to figure out how to put a repl in a state where that
>> expression will evaluate to that result. I'm sure mathematicians everywhere
>> are deeply offended by the clojure reader now. :)
>>
>>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Instaparse 1.0.0

[David Powell]

Looks awesome.

Would it be possible to plug in support for the ABNF[1] notation that the
IETF use?  Might be useful for implementing standards.  Mostly just a
different syntax for repetition, and has support for comments.

[1] http://www.rfc-editor.org/std/std68.txt

-- 
Dave

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Opinions on Equality Semantics

[Gary Verhaegen]

Since Clojure is not a pure language, you cannot even expect (a == a) ==>
((f a) == (f a)), so I do not think it is a stretch to break that theorem
for b != a.

Most importantly, Clojure's notion of equality is centered around the
notion of simple data, irrespective of the specific type of object you have
built to encapsulate it.


On 9 April 2013 11:00, Tassilo Horn  wrote:

> JvJ  writes:
>
> > This is just an idle curiosity up for discussion, but in Clojure, if
> > (= a b) is true, then given some function f, it is not necessarily
> > true that (= (f a) (f b))
>
> I think this axiom isn't true in any language.  Take `str` / toString()
> as an example.  If that statement was true, then equal objects would
> need to have equal string representations.  Then you either couldn't
> have 1 and 1.0 be equal, or you would need to print all numbers as
> floats.  An even better counter example are sets versus sorted sets.
>
> Bye,
> Tassilo
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Instaparse 1.0.0

[Softaddicts]

I am not convinced that typing more delimiter characters is a better thing.
The string representation is ... shorter and less error prone.

As Mark said, a string isolates you from the reader which could change 
its behavior over time introducing other undesirable side effects like {}
with an uneven # of args.

Thank you for this parser Mark, it's just in time, I have a need for this that
came to life a week ago :) Will definitively try this in the next month or so. 

Luc P.


> Mark Engelberg  writes:
> 
> Hi Mark,
> 
> > Example:
> >
> > (def as-and-bs
> >   (parser
> > "S = AB*
> >  AB = A B
> >  A = 'a'+
> >  B = 'b'+"))
> 
> Nice, but providing the grammar as a plain string looks somewhat
> unnatural to me.  Why not something like this (parser being a macro)?
> 
> (def as-and-bs
>   (parser
> S  = AB* .
> AB = A B .
> A  = "a" + .
> B  = "b" + .))
> 
> I.e., symbols denote non-terminals, strings denote terminals, and the
> dot indicates the end of a rule.
> 
> Bye,
> Tassilo
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 
> 
--
Softaddicts sent by ibisMail from my ipad!

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Instaparse 1.0.0

[Mark Engelberg]

Thanks for the suggestion.  I based the syntax off of EBNF, and hadn't run
across ABNF notation before your link just now.  It shouldn't be too hard
to add support for ABNF's repetition syntax and comments.  Getting the
semantics of the terminal values to precisely match the ABNF spec seems
like more effort -- how essential is that piece do you think, versus just
using strings and regexes for the terminals?

Support for comments in the EBNF notation is probably a good idea too.

On Tue, Apr 9, 2013 at 3:29 AM, David Powell  wrote:

>
> Looks awesome.
>
> Would it be possible to plug in support for the ABNF[1] notation that the
> IETF use?  Might be useful for implementing standards.  Mostly just a
> different syntax for repetition, and has support for comments.
>
> [1] http://www.rfc-editor.org/std/std68.txt
>
> --
> Dave
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Something goofy you can do in Clojure.

[Mark Engelberg]

Ah.  That's pretty funny :)

On Tue, Apr 9, 2013 at 2:48 AM, Jim foo.bar  wrote:

>  Hey Mark, don't get paranoid :)... this is all Cedric did!
>
> user=> (def .3 0.4)
> #'user/.3
>
> user=> (+ .3 1.7)
> 2.1
>
> Jim
>
>
>
>
> On 09/04/13 10:46, Mark Engelberg wrote:
>
> What version are you running?
>
> As far as I know, .3 isn't even a valid representation for a number --
> you'd have to write it as 0.3.  So I'm not sure where you're running that
> code snippet such that you don't get an immediate error.
>
> On 1.5.1:
>
> => (+ 0.3 1.7)
> 2.0
>
> That said, I think most programmers know that floating point
> representations of numbers are inexact.  That's why, if you care about
> exactness, you should write:
>
> => (+ 0.3M 1.7M)
> 2.0M
>
> On Tue, Apr 9, 2013 at 1:53 AM, Cedric Greevey  wrote:
>
>>   This may look mildly surprising, and suggests one more thing *not* to
>> ever do in production code:
>>
>>  user=> (+ .3 1.7)
>> 2.1
>>  user=>
>>
>> :)
>>
>>  Shouldn't be hard to figure out how to put a repl in a state where that
>> expression will evaluate to that result. I'm sure mathematicians everywhere
>> are deeply offended by the clojure reader now. :)
>>
>>  --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>  --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Signing libraries on clojars

[Marko Topolnik]

Most probably it is waiting for you to enter the passphrase to unlock your 
private key. You should be seeing a message to that effect, though.

On Monday, April 8, 2013 11:42:20 AM UTC+2, puzzler wrote:
>
> When I do "lein deploy clojars", the tool hangs after reporting that it 
> has created the jar.
>
> Any idea what might be causing it to hang?
>
> On Fri, Apr 5, 2013 at 7:19 PM, Nelson Morris 
> 
> > wrote:
>
>> Yep.  There is an issue for making it work over scp, which the
>> lein-clojars plugin uses, at
>> https://github.com/ato/clojars-web/issues/118. Unfortunately the
>> commits mentioning they "fix" it are incorrect.
>>
>> At the moment, `lein deploy clojars` is the way to send signatures.
>> This command is built in to lein 2.x.
>>
>> -
>> Nelson
>>
>> On Fri, Apr 5, 2013 at 8:35 PM, Phil Hagelberg 
>> > 
>> wrote:
>> > I'm not sure Clojars supports sending signatures over scp yet. You might
>> > need to do an HTTP deploy with `lein deploy`. The docs around this are 
>> a bit
>> > scarce; sorry about that.
>> >
>> > Phil
>> >
>> > --
>> > --
>> > You received this message because you are subscribed to the Google
>> > Groups "Clojure" group.
>> > To post to this group, send email to clo...@googlegroups.com
>> > Note that posts from new members are moderated - please be patient with 
>> your
>> > first post.
>> > To unsubscribe from this group, send email to
>> > clojure+u...@googlegroups.com 
>> > For more options, visit this group at
>> > http://groups.google.com/group/clojure?hl=en
>> > ---
>> > You received this message because you are subscribed to the Google 
>> Groups
>> > "Clojure" group.
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an
>> > email to clojure+u...@googlegroups.com .
>> > For more options, visit https://groups.google.com/groups/opt_out.
>> >
>> >
>>
>> --
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Instaparse 1.0.0

[Laurent PETIT]

I find this library very exciting. It is incredibly well documented,
already covers a broad range of use cases, I can't wait for trying it.

There are also a lot of interesting ideas that may pollinate outside
it, I love the cross-pollination capability of open source software !
(i.e. I'd love to see some of these features into parsley).

Do you have a roadmap for the next releases ?

Of interest to me:
- restartable version ? (probably doable, if internal implementation
uses immutable datastructures)
- incremental version ? (Dunno if that's an easy one, and way beyond
my current programming skills anyway to be able to even judge)
- possibility to have transform-map(s) passed as an argument to parse,
so that a collection of views can be applied in parallel and the tree
be "traversed" once ?

Have you tried some tests to compare performance with e.g. same
grammars in Antlr ?

Thanks again for the hard work,

--
Laurent

2013/4/9 Mark Engelberg :
> Instaparse is an easy-to-use, feature-rich parser generator for Clojure.
> The two stand-out features:
>
> 1. Converts standard EBNF notation for context-free grammars into an
> executable parser.  Makes the task of building parsers as lightweight and
> simple as working with regular expressions.
>
> 2. Works with *any* context-free grammar.  This means you don't have to
> learn the esoteric subtleties of LR, LL, LALR or any other specialized
> subset.  Left-recursion, right-recursion, ambiguous grammars -- instaparse
> handles it all.
>
> Example:
>
> (def as-and-bs
>   (parser
> "S = AB*
>  AB = A B
>  A = 'a'+
>  B = 'b'+"))
>
> => (as-and-bs "abbbbb")
> [:S
>  [:AB [:A "a" "a" "a" "a" "a"] [:B "b" "b" "b"]]
>  [:AB [:A "a" "a" "a" "a"] [:B "b" "b"]]]
>
> https://github.com/Engelberg/instaparse for full feature list and extensive
> tutorial.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Basic multiplication incorrent?!?

[Rostislav Svoboda]

Can anyone explain me please why I get:

Clojure 1.5.1
user=> (* 148.52 0.0256)
3.80211206

The correct result should be:
https://www.google.com/search?q=148.52+*+0.0256
3.802112

If you don't believe me try it on: http://tryclj.com/

thx

Bost

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Basic multiplication incorrent?!?

[Plínio Balduino]

Nothing weird there. Looks like an usual floating point operation.

On Tue, Apr 9, 2013 at 9:27 AM, Rostislav Svoboda
 wrote:
> Can anyone explain me please why I get:
>
> Clojure 1.5.1
> user=> (* 148.52 0.0256)
> 3.80211206
>
> The correct result should be:
> https://www.google.com/search?q=148.52+*+0.0256
> 3.802112
>
> If you don't believe me try it on: http://tryclj.com/
>
> thx
>
> Bost
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Basic multiplication incorrent?!?

[Plínio Balduino]

This article explains better how it works:
http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems

Regards

Plínio

On Tue, Apr 9, 2013 at 9:27 AM, Rostislav Svoboda
 wrote:
> Can anyone explain me please why I get:
>
> Clojure 1.5.1
> user=> (* 148.52 0.0256)
> 3.80211206
>
> The correct result should be:
> https://www.google.com/search?q=148.52+*+0.0256
> 3.802112
>
> If you don't believe me try it on: http://tryclj.com/
>
> thx
>
> Bost
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Basic multiplication incorrent?!?

[Michael Wood]

On 9 April 2013 14:27, Rostislav Svoboda  wrote:
> Can anyone explain me please why I get:
>
> Clojure 1.5.1
> user=> (* 148.52 0.0256)
> 3.80211206
>
> The correct result should be:
> https://www.google.com/search?q=148.52+*+0.0256
> 3.802112

Plínio's answer is correct, but just to demonstrate this is not just
Clojure doing something stupid, here's Python doing the same thing:

Python 2.6.5 (r265:79063, Oct  1 2012, 22:04:36)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 148.52 * 0.0256
3.80211206

and here's how you should be able to get exact values in Clojure:

user=> (* 148.52M 0.0256M)
3.802112M

> If you don't believe me try it on: http://tryclj.com/
>
> thx
>
> Bost

-- 
Michael Wood 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Basic multiplication incorrent?!?

[Rostislav Svoboda]

I see. I did some testing. It's not clojure, it's not java, it's deeper.

People of planet Earth! Stop wasting time on SETI if your machines
can't properly calculate 148.52 * 0.0256 !!!

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Basic multiplication incorrent?!?

[Plínio Balduino]

In languages that doesn't give you support to arbitrary precision like
Clojure do, it's a usual practice compare values using round
functions.

In pseudo-C it would be like that:

float a = 148.52 * 0.0256;
float b = 3.802112;

a == b;
=> false

round(a, 5) == round(b, 5);
=> true

Or, if possible, don't use float type.

I saw some coworkers spend a whole night debugging until they figured
that float trick.

On Tue, Apr 9, 2013 at 10:17 AM, Rostislav Svoboda
 wrote:
> I see. I did some testing. It's not clojure, it's not java, it's deeper.
>
> People of planet Earth! Stop wasting time on SETI if your machines
> can't properly calculate 148.52 * 0.0256 !!!
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Instaparse 1.0.0

[Michael Klishin]

2013/4/9 Laurent PETIT 

> I find this library very exciting. It is incredibly well documented,
> already covers a broad range of use cases, I can't wait for trying it.
>

I concur. Thank you Mark for not letting your users down and writing
the docs.


-- 
MK

http://github.com/michaelklishin
http://twitter.com/michaelklishin

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Instaparse 1.0.0

[Tassilo Horn]

Mark Engelberg  writes:

Hi Mark,

>> (def as-and-bs
>>   (parser
>> S  = AB* .
>> AB = A B .
>> A  = "a" + .
>> B  = "b" + .))
>
> I played around with that, but even if you suppress evaluation by
> using a macro, Clojure's reader makes strong assumptions about certain
> symbols.  For example, it is standard in EBNF notation for {} to mean
> zero-or-more.  But if you include {A B C} in your grammar using the
> macro approach, Clojure's reader will throw an error because it treats
> {} as a map and expects an even number of forms to follow.

Indeed, I didn't think about this one.

> That was the main reason, but it also makes the notation much more
> sensitive to whitespace (for example, AB * versus AB*).  Gradually,
> those little issues start making it look less and less like
> traditional notation.  There's something really nice about just being
> able to copy and paste a grammar off of a website and have it just
> work.

That's nice.

> I understand where you're coming from, though.  It definitely is part of
> the Clojure culture to avoid string representations for many kinds of data
> (e.g., SQL queries).  We do accept it for regular expressions, and for
> things like #inst "2011-12-31T19:00:00.000-05:00", though, and that's the
> kind of feel I was going for.  Would it be more psychologically palatable
> to type:
> #insta/parser "S = 'a' 'b'"
> rather than
> (insta/parser "S = 'a' 'b'")
> ?

No, not really.

> What do you think would be gained by making it a macro?

I don't really care if it's a macro or a function, but if the grammar
was represented using symbols, keywords, and clojure collections, you'd
get at least a bit syntax highlighting and maybe a bit support for
indentation or refactoring.

> From my perspective, a macro is essentially just a string that is
> being processed by the Clojure reader (and thus subject to its
> constraints).  If the grammar were expressed in the way you propose,
> is it any easier to build up a grammar programmatically?  Is it any
> easier to compose grammars?  If anything, I think it might be harder.

I think it would be nice if grammars were expressed in a format
processable by Clojure in the very same respect as why homoiconicity in
general is a strength of Lisps.

FWIW, the Bison equivalent Emacs Lisp parser Wisent uses grammars
represented as s-exps.

  
http://www.gnu.org/software/emacs/manual/html_node/wisent/Grammar-format.html#Grammar-format

IMHO, it would be cool if a clojure parser library would use a similar
format (exploiting clojure data structures beyond lists where they make
sense), at least internally.  Of course, one could still have other
frontends like for the EBNF you are using which would be translated to
the internal format.

Bye,
Tassilo

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Instaparse 1.0.0

[Rich Hickey]

That looks stunning - congrats and thanks!

On Apr 9, 2013, at 1:18 AM, Mark Engelberg wrote:

> Instaparse is an easy-to-use, feature-rich parser generator for Clojure.  The 
> two stand-out features:
> 
> 1. Converts standard EBNF notation for context-free grammars into an 
> executable parser.  Makes the task of building parsers as lightweight and 
> simple as working with regular expressions.
> 
> 2. Works with *any* context-free grammar.  This means you don't have to learn 
> the esoteric subtleties of LR, LL, LALR or any other specialized subset.  
> Left-recursion, right-recursion, ambiguous grammars -- instaparse handles it 
> all.
> 
> Example:
> 
> (def as-and-bs
>   (parser
> "S = AB*
>  AB = A B
>  A = 'a'+
>  B = 'b'+"))
> 
> => (as-and-bs "abbbbb")
> [:S
>  [:AB [:A "a" "a" "a" "a" "a"] [:B "b" "b" "b"]]
>  [:AB [:A "a" "a" "a" "a"] [:B "b" "b"]]]
> 
> https://github.com/Engelberg/instaparse for full feature list and extensive 
> tutorial.
> 
> 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Accessing Java members, from Clojure

[Timothy Washington]

Hi all,

I have a polyglot project, comprising of a little Java and mostly Clojure
code. The Java class is a concrete callback for an external library. There
will be sub-second firing of that callback, and event map objects will get
pushed onto a list.

>From Clojure, I need to access that list in the callback. The problem is
that, in Clojure, we have STM (like refs) that can control access to the
data. If that data member is in Java, how can I control the access? From
Clojure, I could potentially access and flush the list, while the Java
callback is writing to it.

Is there a better strategy here? Can Java access a STM ref in Clojure? How
might that work?


Thanks
Tim

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Disable undocumented #= reader macro to prevent unsafe code injection?

[rebcabin]

Hello -- I would like to use Clojure to build a safe code-remoting 
application for query injection (moving queries closer to the data for 
affinity and privacy). One alternative for this application is to read 
Clojure code from strings WITHOUT evaluating it, then analyze the presented 
code and / or eval it with a custom eval function in a sandbox. It's easier 
to do this in Clojure than in JavaScript because it's easier to write a 
custom eval in Clojure than in JavaScript. 

One problem with my plan is that the #= reader macro evaluates the code at 
read-time, before I have a chance to analyze or sandbox it. The workarounds 
seem to be disabling or removing the #= reader macro or writing my own 
custom reader (in addition to a custom evaluator).

I'd be grateful for guidance and advice. 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Disable undocumented #= reader macro to prevent unsafe code injection?

[David Powell]

On Tue, Apr 9, 2013 at 6:03 PM, rebcabin  wrote:

> Hello -- I would like to use Clojure to build a safe code-remoting
> application for query injection (moving queries closer to the data for
> affinity and privacy). One alternative for this application is to read
> Clojure code from strings WITHOUT evaluating it, then analyze the presented
> code and / or eval it with a custom eval function in a sandbox. It's easier
> to do this in Clojure than in JavaScript because it's easier to write a
> custom eval in Clojure than in JavaScript.
>
> One problem with my plan is that the #= reader macro evaluates the code at
> read-time, before I have a chance to analyze or sandbox it. The workarounds
> seem to be disabling or removing the #= reader macro or writing my own
> custom reader (in addition to a custom evaluator).
>
> I'd be grateful for guidance and advice.
>

#= was an issue that was addressed in Clojure 1.5.  (Though you should use
1.5.1 which fixes a memory leak).

The read and read-string [1] functions have always been controllable by
setting *read-eval* [2] to nil or false to disable the eval-reader.
 However, in Clojure 1.4 and below, this still allowed execution of record
and class constructors, which probably isn't desired.
In Clojure 1.5.1 setting *read-eval* to nil or false should (I think)
disable all eval-on-read facilities.  (Though I'd get a second opinion on
that before relying on it)


Clojure 1.5.1 also brought the new clojure.edn [3] namespace, which provide
safe reading of clojure data structures as data, but doesn't support all of
the features of the reader that might be used in code.  For your usage, it
sounds like this might be unsuitable.

[1]
http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/read-string
[2]
http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/*read-eval*
[3] http://clojure.github.io/clojure/clojure.edn-api.html

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Disable undocumented #= reader macro to prevent unsafe code injection?

[David Powell]

Also - take a look at:
https://github.com/flatland/clojail

-- 
Dave

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Disable undocumented #= reader macro to prevent unsafe code injection?

[Andy Fingerhut]

On Tue, Apr 9, 2013 at 10:03 AM, rebcabin  wrote:

> The workarounds seem to be disabling or removing the #= reader macro or
> writing my own custom reader (in addition to a custom evaluator).
>

Disabling #= by binding *read-eval* to false would cause an exception if
such an expression ever occurred within the code, yes.  I don't know off
hand exactly which functionality this would cut out from the application
you are considering, but probably at least some, if not a crucial part of
what you want.

Note that even when binding *read-eval* to false, there is no promise that
clojure.core/read or read-string won't have other side effects.  They
*might* happen to be free of side effects in Clojure 1.5.1, but you'd need
to do your own code review, testing, etc. if it matters to you.  In Clojure
1.3 and 1.4, even binding *read-eval* to false allows some side effects
during reading.  Examples of this are given at
http://clojuredocs.org/clojure_core/clojure.core/read

I would recommend asking the authors of clojail or other sandbox
environments whether you can call clojure.core/read or read-string from
*within* the sandbox, and have the sandbox's restrictions apply to any #=
expressions encountered during the reading.  Again, not sure if that would
achieve your goals, but if it does, it sounds quicker than writing your own
custom reader.

If you do end up writing your own custom reader, and you prefer developing
in Clojure rather than Java, and the Eclipse Public License doesn't present
any problems for you, consider starting with the tools.reader contrib
library: https://github.com/clojure/tools.reader

Andy

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Instaparse 1.0.0

[Mark Engelberg]

Wow, the enthusiastic response has been really gratifying.  Thanks for the
kind words;  I hope as people try it out that it lives up to the hype.

On Tue, Apr 9, 2013 at 4:47 AM, Laurent PETIT wrote:

> Do you have a roadmap for the next releases ?
>

Initially, my focus will be on gathering feedback from users: making sure
it's as stable as I think it is, gathering feature requests.

Beyond that, my next objective is to produce a version that can leverage
multiple threads.  I'm not sure whether the parser really needs to be any
faster than it currently is, but Clojure makes it so easy, I might as well
offer that.


> Of interest to me:
> - restartable version ? (probably doable, if internal implementation
> uses immutable datastructures)
>
- incremental version ? (Dunno if that's an easy one, and way beyond
> my current programming skills anyway to be able to even judge)
>

I don't know offhand how doable these are either.  I'd need to investigate
further.  It wasn't really a goal of mine, since Parsley already addresses
that space.


> - possibility to have transform-map(s) passed as an argument to parse,
> so that a collection of views can be applied in parallel and the tree
> be "traversed" once ?
>

Actually, I've already done something very similar to this.  You can find
it in the "transform" branch of the github page, and you're welcome to try
it out and let me know what you think.  The tutorial has been updated on
that branch to explain how to use that feature, but it basically works the
way you'd expect -- you simply pass the transform map as an argument to
*parser* (the parser-building function, not the parse function) using the
keyword :transform.  When you do this, the transforms are done during parse
time so the tree is traversed only once.  The tradeoff is that parsers with
"baked-in transforms" can't be serialized with print-dup.

I like the feature, but hesitated to include it.  I timed parsers with
baked-in transforms against those where the transforms were applied after
the fact.  On the examples I tried, the time difference was minuscule,
presumably because the version with the baked-in transforms ends up
applying the transforms to various partial parses along the way.  Some of
these partial parses are eventually discarded, so applying transforms to
those unsuccessful parses means you're doing extra work that potentially
cancels out much of the savings from not having to traverse the tree a
second time.

What this means is that if I include this feature, I have to make sure
users clearly understand that it is a tradeoff (possibly better
performance, possibly not, depending on context; affects serialization).  I
like the idea of adding that level of control as to whether the transform
is done at parse time or afterwards but, based on my limited
experimentation, the benefits didn't seem to outweigh the degree to which
it adds to the learning curve.

I decided, for now, to make it available as a branch for people to play
around with it, and see if it offers any compelling advantages that tip the
balance in favor of including it.

Your suggestion to make it a keyword argument to the parse function is also
possible; I mainly included it in the parser-building function because then
the attachment of the transform functions to the parser only needs to be
done once, giving it a (tiny) performance boost versus doing it every time
in the parse function.


> Have you tried some tests to compare performance with e.g. same
> grammars in Antlr ?
>

No, I haven't done back-to-back performance tests.  I'm guessing that Antlr
would be hard to compete with.  Before I began work, I played around with
other Clojure parsers to get a feel for their performance, and I believe
instaparse to be competitive with those.  That statement is based more on
feel than precise benchmarks, though.  I focused my performance tuning on
improving instaparse relative to itself, trying to get parse time to scale
linearly with the size of the input, for as many grammars as possible.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] Instaparse 1.0.0

[Mark Engelberg]

On Tue, Apr 9, 2013 at 7:14 AM, Tassilo Horn  wrote:

> IMHO, it would be cool if a clojure parser library would use a similar
> format (exploiting clojure data structures beyond lists where they make
> sense), at least internally.  Of course, one could still have other
> frontends like for the EBNF you are using which would be translated to
> the internal format.
>

There already are several clojure parser libraries that rely more heavily
on Clojure data structure syntax to define grammars; in fact, that's
probably the norm.  Instaparse was definitely intended as an alternative to
that approach.

That said, instaparse definitely uses Clojure data structures internally to
represent the parser and provides constructor functions to build them.  It
would be pretty easy to build other front-ends that translate to its
internal format, including one that tries to strike a balance between
readability and homoiconicity.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Accessing Java members, from Clojure

[Cedric Greevey]

On Tue, Apr 9, 2013 at 12:41 PM, Timothy Washington wrote:

> Hi all,
>
> I have a polyglot project, comprising of a little Java and mostly Clojure
> code. The Java class is a concrete callback for an external library. There
> will be sub-second firing of that callback, and event map objects will get
> pushed onto a list.
>
> From Clojure, I need to access that list in the callback. The problem is
> that, in Clojure, we have STM (like refs) that can control access to the
> data. If that data member is in Java, how can I control the access? From
> Clojure, I could potentially access and flush the list, while the Java
> callback is writing to it.
>
> Is there a better strategy here? Can Java access a STM ref in Clojure? How
> might that work?
>

If you control the Java code, you may be able to use Clojure's STM from
inside it. You would wrap the state in a ref and call methods on the ref
object from Java. You'd also want to set up a transaction by calling
clojure.lang.LockingTransaction.runInTransaction (func), where func
implements IFn and the zero-argument invoke method is implemented to do the
transaction.

Alternatively, and maybe simpler, the Java callback could just .invoke a
function you've defined in Clojure and whose Var you've previously (during
initialization) accessed on the Java side to get at the function object and
store a reference to it into a static variable. The bulk of the callback
can then be handled inside of the Clojure function, in Clojure code, where
you can just write (dosync (alter foo ... ))

You might consider going still further and using gen-class, proxy, reify,
or deftype to generate the Java class, with method bodies written in
Clojure. You can use proxy, reify, or deftype to implement Java interfaces,
but you'd need gen-class if you needed to extend a concrete class defined
by the external library. Proxy is commonly used to implement Swing
listeners in Clojure code that I've seen, which sounds like a very similar
situation to yours. (User pushes a button, ActionListener is invoked and
uses a transaction to update the model.)

Finally, though it's trickier to do it right, you could give up Clojure's
concurrency constructs and rely on Java's. Have the callback synchronize on
a Java object with the state in it (synchronized (theObject) {
theObject.mutatingMethod(args); }), and use (locking the-object
(.mutatingMethod the-object args)) when you want to mutate it from Clojure,
and (locking the-object (do-something-with (.getFoo the-object))) when you
want to read it without it possibly being mutated at the same time by
another thread.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Accessing Java members, from Clojure

[Gary Verhaegen]

I'm not really sure I understand what you want to do here. If you want
to access a Java class from Clojure, you can access it directly with
the dot notation. If you are concerned about concurrency between your
Java code and your Clojure code, this is no different from any
concurrency in Java : you have to correctly publish your object from
Java and make sure there are never two threads that try to write that
variable at once.

Accessing Clojure from Java is generally much more painful than the
other way around, except when you prepare for it on the Clojure side
(genclass et al).

>From what you're saying, I would advise you to take a look at
java.util.concurrent.atomic.AtomicReference, which is sort of an atom
in Java world. Then, from Clojure, if you have access to that
reference, convert its content to a persistent data structure and
manage it from Clojure from then on.

Other than that, Clojure's Atoms are actually implemented in Java, so
they should be usable, though not especially pleasant, since that was
not their main purpose :
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Atom.java
In particular, if you restrict yourself to the reset and
compareAndSwap methods, you should be able to use a single atom to
communicate effectively between Java and Clojure.

Since I'm still not sure I understand your question, feel free to
explain your problem further should I have missed the mark.

On 9 April 2013 18:41, Timothy Washington  wrote:
> Hi all,
>
> I have a polyglot project, comprising of a little Java and mostly Clojure
> code. The Java class is a concrete callback for an external library. There
> will be sub-second firing of that callback, and event map objects will get
> pushed onto a list.
>
> From Clojure, I need to access that list in the callback. The problem is
> that, in Clojure, we have STM (like refs) that can control access to the
> data. If that data member is in Java, how can I control the access? From
> Clojure, I could potentially access and flush the list, while the Java
> callback is writing to it.
>
> Is there a better strategy here? Can Java access a STM ref in Clojure? How
> might that work?
>
>
> Thanks
> Tim
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Accessing Java members, from Clojure

[Cedric Greevey]

On Tue, Apr 9, 2013 at 12:41 PM, Timothy Washington wrote:

> Hi all,
>
> I have a polyglot project, comprising of a little Java and mostly Clojure
> code. The Java class is a concrete callback for an external library. There
> will be sub-second firing of that callback, and event map objects will get
> pushed onto a list.
>

Now, after the generic advice for sharing state between Java and Clojure,
in your specific case it sounds like you might have only a single piece of
state and it *may* be a queue being produced by the Java callback and
consumed by Clojure.

In the single-piece-of-state-but-not-a-queue case you could use
java.util.concurrent.AtomicReference around a java.util.List from the Java
side, or even a Clojure atom (clojure.lang.Atom class).

In the queue case you can do better:
java.util.concurrent.LinkedBlockingQueue. In the callback class, static
LinkedBlockingQueue queue = new LinkedBlockingQueue(); and, in the callback
method, queue.offer(anotherEventMapObject); in the Clojure code, (.poll
CallbackClass/queue) to fetch an event map in the consumer (it will block,
as the name implies, if the queue is empty until the producer offers
another one, so you might want a dedicated thread to do the consuming,
depending).

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

New CSS library - Garden

[Joel Holdbrooks]

Nobel Clojurians,

I am pleased to announce the alpha version of 
*Garden*, 
a new library for writing CSS in Clojure.

The project weds the best ideas from Hiccup, gaka, and cssgen and aims to 
provide a clean and conventional way to author stylesheets without being 
too simple or too complex.

Currently the list of notable features include:

   - Nestable rules
   - Nestable declarations (this my change)
   - A builtin set of tools for working with CSS unit values
   - Convenient multiple selector syntax (IE. h1, h2, h3 { ... })
   - Output formatting options

What's planned for the near future:

   - The ability to use Clojure meta as a media query
   - A builtin set of tools for working with CSS color values
   - & selector syntax for nested rules 

For those of you who are interested in this sort of thing, please have a 
look at the *project's repository* . 
There is still quite a bit of ground to do cover and any 
help/criticism/contribution would be greatly appreciated.

Please feel free to offer suggestions, ask questions, open issues, or send 
pull requests. I would love nothing more than to see this library succeed 
where other's have not. 


Truly,

Joel Holdbrooks (aka noprompt)

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] java.jdbc 0.3.0-alpha1

[r0man]

Hi Sean & Matching Socks,

first off, I like the new API design. Here are my questions and
suggestions:

1.) Despite the asymmetry I'm also thinking that passing entities
and identifiers functions via the "db" argument is quite
convienient. Otherwise I always have to wrestle with those extra
parameters and pass them through my underlying SQL generation
functions. Which I have to to with the db anyway (maybe one level
less). 

2.) The default naming strategy for columns coming from the
database is at the moment "lower-case". Wouldn't it be more
idiomatic to lower case and replace "_" with "-". That would be
more consistent with the Clojure defaults of naming keywords at
the expense of maybe performance. I use this naming strategy for
example, because I don't want to constantly remember which keys
in my maps use the Clojure and which the database "convention".
Would this be an option for 0.3.0?
   
3.) Would it make sense to define some connection spec, into
which the current specs get translated to? Something like the
Ring SPEC for connections. I'm often interested in the name of
the database, the credentials of the hostname the database is
running on, etc. Something like this?
   
{:product :postgresql
 :server-name "example.com"
 :server-port 5432
 :username "tiger"
 :password "scotch"
 :db "my_db"
}

Othwerwise thanks for your work on clojure.java.jdbc,

Roman.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Accessing Java members, from Clojure

[Timothy Washington]

Hey thanks for all the feedback.

So I got a working solution, bits and pieces of this solution online.
Cedric mentioned it, but basically, I'm having my java code call a clojure
function that (via STM), pushes new event objects to a list in Clojure
(fig.1). And with my Clojure code in place, my Java code looks like the
below (fig.2). And this ensures that the Java callback pushes to an STM
guarded place in memory.


(def event-list (ref ()))

(defn pushEvent [event]
  (dosync (alter event-list conj event) ))

(defn -pushEvent [event]
  (pushEvent event))

fig.1


eventObject = ... ;


//Load the namespace

RT.var("clojure.core","eval").invoke(RT.var("clojure.core","read-string").invoke("(use
'my.namespace)"));

//Find a function in namespace
IFn fn = (IFn)RT.var("my.namespace","my-function");

//Call that function
Object result = *fn.invoke( eventObject );*
System.out.println(result);

fig.2


Now, this works, but I'm always open to a better idea. In clojure-land, 1)
there's a thread constantly checking for new events on the list and 2)
there will be a thread of execution for each eventID. So I'm trying to come
up with the best data and functional pattern to handle all this. I'm not
sure a plain-jane Clojure list does the trick.


Hmm

Tim

No 6: "I'm not a number. I'M A FREE MAN!!!"
No 2: "HA HA HA HA HAAA"

-- The Prisoner


On Tue, Apr 9, 2013 at 3:48 PM, Cedric Greevey  wrote:

> On Tue, Apr 9, 2013 at 12:41 PM, Timothy Washington wrote:
>
>> Hi all,
>>
>> I have a polyglot project, comprising of a little Java and mostly Clojure
>> code. The Java class is a concrete callback for an external library. There
>> will be sub-second firing of that callback, and event map objects will get
>> pushed onto a list.
>>
>
> Now, after the generic advice for sharing state between Java and Clojure,
> in your specific case it sounds like you might have only a single piece of
> state and it *may* be a queue being produced by the Java callback and
> consumed by Clojure.
>
> In the single-piece-of-state-but-not-a-queue case you could use
> java.util.concurrent.AtomicReference around a java.util.List from the Java
> side, or even a Clojure atom (clojure.lang.Atom class).
>
> In the queue case you can do better:
> java.util.concurrent.LinkedBlockingQueue. In the callback class, static
> LinkedBlockingQueue queue = new LinkedBlockingQueue(); and, in the callback
> method, queue.offer(anotherEventMapObject); in the Clojure code, (.poll
> CallbackClass/queue) to fetch an event map in the consumer (it will block,
> as the name implies, if the queue is empty until the producer offers
> another one, so you might want a dedicated thread to do the consuming,
> depending).
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Does the try special form complect the catch and finally clauses?

[Emanuel Rylke]

I've been thinking about exceptions a bit and it occurred to me that the 
catch and finally clauses are orthogonal.
I mean code in a catch clause runs conditional on a exception being thrown 
and code in a finally clause runs unconditional on whether there was an 
exception or not.

So i think using try only through something like the following macros would 
make the intend of ones code more explicit.

(defmacro simple-catch [maythrow & clauses]
  `(try
 ~maythrow
 ~@(map #(cons 'catch %) clauses)))

(defmacro simple-finally [maythrow & body]
  `(try
 ~maythrow
 (finally
  ~@body)))

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSoC 2013] CinC

[Bronsa]

Actually, I would be interested in doing this if still available :)


On Mon, Mar 4, 2013 at 6:53 PM, Aaron Cohen  wrote:

> On Mon, Mar 4, 2013 at 11:26 AM, abp  wrote:
>
>> Is this work related?
>>
>> http://clojurewest.org/sessions#martin
>> https://github.com/kanaka/clojurescript
>>
>
> Nope, completely unrelated, though similar work.
>
> --Aaron
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [ANN] java.jdbc 0.3.0-alpha1

[Sean Corfield]

On Tue, Apr 9, 2013 at 1:49 PM, r0man  wrote:
> first off, I like the new API design.

Thanx.

> 1.) Despite the asymmetry I'm also thinking that passing entities
> and identifiers functions via the "db" argument is quite
> convienient. Otherwise I always have to wrestle with those extra
> parameters and pass them through my underlying SQL generation
> functions. Which I have to to with the db anyway (maybe one level
> less).

Could you elaborate on your use case, in the context of the new API?
I'm trying to imagine what "my underlying SQL generation functions"
look like and how they relate to / have access to the db-spec.

The identifiers and entities macros allow you to wrap a block of code
containing the new API and/or the DSL and have the functions injected
automatically:

(entities (quoted \')
  ...
  (insert! my-db :foo {:name "Bar" :level 123})
  ...
  (identifiers as-is
...
(query my-db (select :name :foo (where {:level 123})

That is equivalent to the (much longer):

  ...
  (insert! my-db :foo {:name "Bar" :level 123} :entities (quoted \'))
  ...
  (query my-db (select :name :foo (where {:level 123} :entities
(quoted \')) :entities (quoted \')) :identifiers as-is)

;; assuming I got my parens right!

Given that SQL generation happens _before_ the db-spec is even
referenced - and happens in a separately evaluated form - I'm not
seeing how having :entities inside the db-spec helps here.

> 2.) The default naming strategy for columns coming from the
> database is at the moment "lower-case". Wouldn't it be more
> idiomatic to lower case and replace "_" with "-".

Yes, but I didn't want to break backward compatibility (with the
default behavior of 0.2.x and earlier) since I expect people to
migrate easily and that seems like a gratuitous change, because it
would ripple thru all of the library's client code. I'm certainly
happy to provide a convenience function in the DSL, along with as-is,
lower-case, and (quoted x) to provide lower-case-and-hyphens in the
entity to Clojure direction (i.e., an identifiers function) and an
as-is-with-underscore in the opposite direction... with better
names... suggestions?

I believe the defaults in java.jdbc have always been (effectively):
* :identifiers lower-case
* :entities as-is

I don't want to make migration from 0.2.x to 0.3.0 difficult for folks
with large code bases (like me, for example!).

> 3.) Would it make sense to define some connection spec, into
> which the current specs get translated to? Something like the
> Ring SPEC for connections. I'm often interested in the name of
> the database, the credentials of the hostname the database is
> running on, etc. Something like this?

An interesting idea...

As it stands, the API functions all accept anything that
get-connection can turn into a database connection, and from a
connection you can get the catalog and quite a bit of metadata (via
.getCatalog and .getMetaData method calls). Some of the things you can
pass to get-connection don't directly contain the information you're
looking for (e.g., pass in a JNDI name / environment or a DataSource
object with username / password - not to be confused with the
user/password property used in some of the other "connectable"
things).

Feel free to add notes or comments here:
http://dev.clojure.org/display/design/java.jdbc
Also request enhancements here:
http://dev.clojure.org/jira/browse/JDBC (although some discussion
about things would be welcome first)

I have created a mailing list specific to clojure.java.jdbc in case
folks want to get into deep discussions and don't want to clog up this
main Clojure mailing list (since I understand the user base for
java.jdbc is relatively small compared to the overall Clojure
community): https://groups.google.com/d/forum/clojure-java-jdbc
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Accessing Java members, from Clojure

[Cedric Greevey]

On Tue, Apr 9, 2013 at 5:00 PM, Timothy Washington wrote:
>
> Now, this works, but I'm always open to a better idea. In clojure-land, 1)
> there's a thread constantly checking for new events on the list and 2)
> there will be a thread of execution for each eventID. So I'm trying to come
> up with the best data and functional pattern to handle all this. I'm not
> sure a plain-jane Clojure list does the trick.
>

If you're polling for new events on the list, then you might want to use
LinkedBlockingQueue. Or perhaps an agent:

(def event-agent (agent initial-agt-contents))

(defn -pushEvent [event]
  (send event-agent event-handler event))

(defn event-handler [agt-contents event]
  ...)

The event handler can keep track of any stateful stuff in agt-contents;
whatever it returns will be agt-contents the next time it's invoked. For
example

(def event-agent (agent 0)

(defn -pushEvent [event]
  (send event-agent event-handler event))

(defn event-handler [event-count event]
  (logger/log! (extract-log-details-from-event event))
  (inc event-count))

will result in @event-agent evaluating to the number of events handled thus
far, increasing over time, while some logger is triggered to log each event
as it arrives.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Confluence (http://dev.clojure.org) maintenance tonight

[Christopher Redinger]

We're going to bring Confluence down for maintenance. This will start
at 9pm Eastern. I anticipate it should only be down for less than 30
minutes.

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: IMPORTANT: For Potential GSoC 2012 mentors, do this now please!

[Mikera]

I'm also stuck on this. I see the "My Dashboard" link, but no list of 
projects. does someone need to accept me as a mentor first perhaps?

On Tuesday, 10 April 2012 00:54:46 UTC+8, David Nolen wrote:
>
> You don't see a My Dashboard link?
>
> On Mon, Apr 9, 2012 at 12:52 PM, Phil Hagelberg 
> > wrote:
>
>> On Mon, Apr 9, 2012 at 7:17 AM, David Nolen 
>> > 
>> wrote:
>> > Yes apply to be a mentor - sorry it wasn't more clear - this could have 
>> been
>> > done at anytime.
>> >
>> > Also important DO NOT associate yourself with a proposal in Confluence 
>> - you
>> > MUST do this in Melange.
>>
>> Feeling a bit slow... I don't see any proposals listed for Clojure in
>> Melange even though I've been accepted as a mentor:
>>
>> http://www.google-melange.com/gsoc/org/google/gsoc2012/clojure
>>
>> How does one associate themselves with a proposal?
>>
>> -Phil
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=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
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: IMPORTANT: For Potential GSoC 2012 mentors, do this now please!

[Daniel Solano Gómez]

Hello, Mike,

On Tue Apr  9 17:31 2013, Mikera wrote:
> I'm also stuck on this. I see the "My Dashboard" link, but no list of 
> projects. does someone need to accept me as a mentor first perhaps?

I got your mentorship application and you should be approved now as a
mentor.  I plan on writing some more detailed instructions for students
and mentors in the next few days.  I haven't yet had the chance to look
around and figure out the Melange app.

Sincerely,

Daniel



> 
> On Tuesday, 10 April 2012 00:54:46 UTC+8, David Nolen wrote:
> >
> > You don't see a My Dashboard link?
> >
> > On Mon, Apr 9, 2012 at 12:52 PM, Phil Hagelberg 
> > 
> > > wrote:
> >
> >> On Mon, Apr 9, 2012 at 7:17 AM, David Nolen 
> >> > 
> >> wrote:
> >> > Yes apply to be a mentor - sorry it wasn't more clear - this could have 
> >> been
> >> > done at anytime.
> >> >
> >> > Also important DO NOT associate yourself with a proposal in Confluence 
> >> - you
> >> > MUST do this in Melange.
> >>
> >> Feeling a bit slow... I don't see any proposals listed for Clojure in
> >> Melange even though I've been accepted as a mentor:
> >>
> >> http://www.google-melange.com/gsoc/org/google/gsoc2012/clojure
> >>
> >> How does one associate themselves with a proposal?
> >>
> >> -Phil
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "Clojure" group.
> >> To post to this group, send email to clo...@googlegroups.com
> >> Note that posts from new members are moderated - please be patient with 
> >> your first post.
> >> To unsubscribe from this group, send email to
> >> clojure+u...@googlegroups.com 
> >> For more options, visit this group at
> >> http://groups.google.com/group/clojure?hl=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
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 


signature.asc
Description: Digital signature

Re: [GSoC 2013] CinC

[Daniel Solano Gómez]

Hello,

On Wed Apr 10 00:04 2013, Bronsa wrote:
> Actually, I would be interested in doing this if still available :)

Well, now that we have been accepted as a mentoring organization, now is
the time to start getting in touch with potential mentors and develop a
proposal.  The student application period won't open until April 22, but
there is no reason to wait until then.

Sincerely,

Daniel



> On Mon, Mar 4, 2013 at 6:53 PM, Aaron Cohen  wrote:
> 
> > On Mon, Mar 4, 2013 at 11:26 AM, abp  wrote:
> >
> >> Is this work related?
> >>
> >> http://clojurewest.org/sessions#martin
> >> https://github.com/kanaka/clojurescript
> >>
> >
> > Nope, completely unrelated, though similar work.
> >
> > --Aaron
> >
> > --
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to clojure+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/groups/opt_out.
> >
> >
> >
> 
> -- 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with your 
> first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 


signature.asc
Description: Digital signature

Re: Confluence (http://dev.clojure.org) maintenance tonight

[Christopher Redinger]

This maintenance has finished.


On Tue, Apr 9, 2013 at 7:49 PM, Christopher Redinger wrote:

> We're going to bring Confluence down for maintenance. This will start
> at 9pm Eastern. I anticipate it should only be down for less than 30
> minutes.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Clojure Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to clojure-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clojure-dev?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[gsoc2013]ClojureScript Optimization

[Bill Liao]

Hi, all,
 I'm very interested in optimizing clojurescript as I'm using it myself
as frontend script language.I tried to get contact with David Nolen for
this idea but couldn't find his email or github account.
regards

wliao 

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[GSOC 2013] core.match refactoring

[crawfordpm]

Hello all,

Can anyone point me in the right direction to contacting David Nolen about 
refactoring/documenting core.match?

I've done a bit of tinkering around with Erlang and it's gotten me 
intrigued with the implementation of pattern matching. I'm also looking 
over the papers mentioned in the repo, which is getting me even more 
psyched.

Are there any projects that use pattern matching extensively in Clojure (or 
other Lisps) that I should check out? Or perhaps some repos of similar 
Clojure code that would be instructive?

-Patrick Crawford

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [GSOC 2013] core.match refactoring

[Ambrose Bonnaire-Sergeant]

Hi Patrick,

I'm sure David will respond on the list.

Racket's pattern matching facilities are very impressive:
http://docs.racket-lang.org/reference/match.html

FWIW the Typed Racket implementation has lots of cool examples using
pattern matching. I can be more specific if you want.

Thanks,
Ambrose


On Wed, Apr 10, 2013 at 2:07 PM,  wrote:

> Hello all,
>
> Can anyone point me in the right direction to contacting David Nolen about
> refactoring/documenting core.match?
>
> I've done a bit of tinkering around with Erlang and it's gotten me
> intrigued with the implementation of pattern matching. I'm also looking
> over the papers mentioned in the repo, which is getting me even more
> psyched.
>
> Are there any projects that use pattern matching extensively in Clojure
> (or other Lisps) that I should check out? Or perhaps some repos of similar
> Clojure code that would be instructive?
>
> -Patrick Crawford
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.