Re: Clojure list syntax sugar: f(x) notation
On 12/26/2011 07:09 PM, Louis Yu Lu wrote: With some experiments, I found the code is more readable for me to use f(x) notation for function call, and (op x) for operator. Operator? It's all function calls! -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Interested in a port of Ruby's String#unpack
This looks great, take-ubyte is basically exactly what I needed. I'll let you know if it works when I try it out this afternoon -- not sure what kind of work needs to be done to bring it up to date. On Dec 27, 1:03 am, Geoff Salmon wrote: > Hi, does the unpack function in this library do what you're looking > for?https://github.com/geoffsalmon/bytebuffer > It unpacks values from Java's ByteBuffer objects instead of strings, > which seemed more appropriate in Java-land. > > I haven't touched the code since Clojure 1.2, but if it looks useful I > can try to bring it up to date. > > - Geoff > > On Dec 26, 10:03 pm, mrb_bk wrote: > > > > > > > > > I also thought I would mention that I've been hanging out in #clojure > > as mrb_bk - please hit me up if you would like to chat about this. > > > On Dec 26, 10:08 am, mrb_bk wrote: > > > > Hey Everyone: > > > > I'm working on a project in Clojure that involves parsing binary data > > > files. Specifically, I'm building a tool for analyzing Redis (http:// > > > redis.io) dump files (.rdb format). The very beginnings of this > > > nascent project are here:http://github.com/mrb/pianist. I am a > > > beginner to Clojure and Lisp in general, but I'm a long time Ruby > > > programmer with experience in C, Java, etc. During the course of > > > working through some Clojure learning materials and general poking > > > around the web and #clojure in IRC, I've noticed that one of my > > > favorite tools for working with binary data from Ruby is missing in > > > the Java/Clojure world. This is String#unpack: > > > >http://www.ruby-doc.org/core-1.9.3/String.html#method-i-unpack > > > > After a brief Twitter conversation with @abedra, and while I get the > > > chance to submit my contributors agreement in order to access Clojure- > > > dev, I thought I'd bring this topic up here. > > > > For what it's worth, I've checked out Gloss, which is interesting but > > > a bit too opinionated for me. Plus I believe that something to this > > > effect should be part of clojure core - it seems that easy interface > > > for lazily handling binary data as seqs doesn't exist as such right > > > now. > > > > If anyone has comments on the beginnings of my codebase (be gentle), > > > or thoughts about implementing something similar to String#unpack, or > > > a suggestion of an alternative set of tools I could use, that would be > > > great. Thanks! > > > > Mike > > > twitter.com/mrb_bk > > > github.com/mrb -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Codox: an API doc generator for Clojure
Hi All, This makes me feel quite embarrassed that autodoc hasn't seen a release for non-core/contrib projects in so long. I apologize for that. (Insert all the usual "life has been crazy... " caveats here.) I hate seeing smart people having to recreate stuff just cause it's taking me a long time to get around to it. I had already put Autodoc on my "Christmas lull to-do list" and am closing in on a new release. Depending how things go on disentagling the recursive loop I've set up with Leiningen, I should have a 0.9.0 out this week. Nicely, I think that Codox and Autodoc should coexist pretty happily and Codox's life is somewhat simplified by not having to deal with the core/contrib craziness (and not, I think, having to deal with documenting multiple versions in the same package). Tom On Dec 26, 9:29 am, James Reeves wrote: > Hi folks, > > In order to generate the documentation for Ring and Compojure, I > created Codox after being unable to get Autodoc working. > > Codox is pretty simple, but should work out of the box, and hopefully > looks quite nice. Here are a couple of examples: > > http://mmcgrana.github.com/ring/http://weavejester.github.com/compojure/ > > Options are limited so far, but patches to add options or improve the > formatting are welcome. > > The project page is here: > > https://github.com/weavejester/codox > > - James -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Codox: an API doc generator for Clojure
Hi, On Tuesday, December 27, 2011 1:18:52 PM UTC+1, James Reeves wrote: > > It might be an idea to figure out some standard syntax we could use, > like Markdown, that could be used for formatting docstrings. > IMHO the missing homoiconicity of docstrings in all flavors of Lisp that I worked with always was a tiny itch. It would be very nice, if docstrings were a 'real' datastructure. Kind regards, Stefan -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Codox: an API doc generator for Clojure
On 26 December 2011 21:23, Gert Verhoog wrote: > Question: One of my ns docstrings is a fair amount of text which is rendered > as a really long line (because codox puts it inside a ... > element). How would you deal with longer documentation strings? Would I need > to insert manual line breaks or is there a better way? Because docstrings can be read at a REPL with the `doc` macro, it's common practise to break up docstrings onto multiple lines. It might be an idea to figure out some standard syntax we could use, like Markdown, that could be used for formatting docstrings. - James -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Codox: an API doc generator for Clojure
Hello, Is it in your roadmap to provide links to source code of the functions ? I know this is a border line feature between codox/autodoc and marginalia, but it could be proven useful, even for API documentation (no API is perfectly documented) 2011/12/26 James Reeves > Hi folks, > > In order to generate the documentation for Ring and Compojure, I > created Codox after being unable to get Autodoc working. > > Codox is pretty simple, but should work out of the box, and hopefully > looks quite nice. Here are a couple of examples: > > http://mmcgrana.github.com/ring/ > http://weavejester.github.com/compojure/ > > Options are limited so far, but patches to add options or improve the > formatting are welcome. > > The project page is here: > > https://github.com/weavejester/codox > > - James > > -- > 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 post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
The proposed syntax sugar does not break the existing code, it make it
easier to read and more fun for programmer from other language on the
ramping up stage. Even with mixed notation, I don’t see issue of
usability; the modified reader will handle it.
I sense the objection is that the f(x) notation make Clojure looks
more different than Lisp on the surface. I think the 3 main usages of
S-expression or Lisp form can accommodate f(x) notation:
1) Function call, f(x) notation put visual emphasis on the function
name, sin(x) look more familiar than (sin x);
2) Describe data structure, in comparison with XML, the leading item
is the element while the rest are the sub elements or attribute, then
the expression student(name, address) make the levels of structure
clearer than (student name address);
3) Metaprogramming with macro, the following works with mixed syntax:
defmacro(my-func [fname arg]
`(~fname ~arg))
my-func(Math/sin 1.2)
Clojure has departure from Lisp’s uniform syntax by introducing
different syntax sugars for different intentions and make the code
more succinct and more readable, for example, the vector [], map {}
and reader macros (^, @, #), so just consider the f(x) notation as an
extension of reader macro.
Clojure is flexible language, why not provide a little flexibility and
freedom for the main stream programmers with a little familiarity. And
don’t scare them with a lot of leading parentheses (the trailing
parentheses are OK as the C family languages have a lot of trailing
braces) or just tell them stay away from Clojure.
Louis
On Dec 26, 7:22 pm, Softaddicts wrote:
> Hi,
>
> I have more than 30 years of dev under my belt dated back to Fortran,
> Cobol,... never had a problem with Lisp syntax
>
> Far more bothering to me were immutability and laziness, it took me three
> months to get used to it,
> not in a home project but laying out production code.
>
> Clojure is a Lisp and prefix notation is part of it. It brings uniformity to
> the syntax,
> on the contrary, your alternate syntax breaks it.
>
> You forget to consider a Lisp form as data structures into which your code
> can crawl
> and alter it to generate different forms. The prefix notation and the list
> shape of forms allows that to be done easily.
>
> Even if it was done, I see a huge usability problem with your approach because
> code generation in macros and elsewhere would be impacted badly or at least
> the
> two syntax would have problems coexisting in the same code base.
>
> Look at forms as data structures and it should ease the transition.
>
> Luc P.
>
>
>
>
>
> > Recently, I found freedom of coding playing with Clojure with over 20
> > years’ experience on other program languages, Previously, I had
> > several trials of learning Lisp, but never got traction.
> > > However there are two syntax notations always bother me, it feels
> > unnatural with my experience on other programming languages and math:
> > > 1) Prefix operator for math formula. Jeffrey Bester’s math library
> >https://github.com/jbester/cljext/blob/master/cljext/math.cljhas
> > brought in the infix notation and solved the problem;
> > 2) The leading item of a list follows the parenthesis when it serves
> > as a function name, (f x) instead of f(x). I am fully aware of many
> > discussions on alternative syntax for Clojure and Lisp in the past,
> > one stream is
> > herehttp://groups.google.com/group/clojure/browse_thread/thread/319a1c77e...
> > My proposition is enhance Clojure to accept both (f x) and f(x), the
> > leading item can appear either after ‘(‘ as usual with classic Lisp
> > notion:
> > (println "Hello," "world!")
> > or with conventional function call notation:
> > println("Hello," "world!")
> > The f(x) notation is just a syntax sugar, the only restriction is no
> > space between the leading item and '('. If one or more spaces in
> > between, the item will be treated as a separate symbol. Either notion
> > or a mix of them can be used in the same program. Here are some
> > examples:
> > > ; classic Lisp syntax notation
> > (defn pig-latin [word]
> > (let [first-letter (first word)]
> > (if (.contains "aeiou" (str first-letter))
> > (str word "ay")
> > (str (subs word 1) first-letter "ay"
> > (println (pig-latin "red"))
> > (println (pig-latin "orange"))
> > > ; f(x) syntax notation
> > defn(pig-latin [word]
> > let( [first-letter first(word)]
> > if(.contains("aeiou", str(first-letter))
> > str(word, "ay")
> > str(subs(word, 1), first-letter, "ay"
> > println(pig-latin("red"))
> > println(pig-latin("orange"))
> > > ; classic Lisp syntax notation
> > (defn fib [n]
> > (if (< n 2)
> > 1
> > (+ (fib (dec n) ) (fib (- n 2)
> > (fib 36)
> > > ; mix of two notations
> > defn(fib [n]
> > if((< n 2)
> > 1
> > (+ fib(dec(n)) fib((- n 2)))
> > )
> > )
> > fib(36)
> > > I have made minor changes (dozen lines) in one file (LispReader.java
Re: Interested in a port of Ruby's String#unpack
I've pushed some updates to get it running with 1.3. take-ulong is still broken because clojure.lang.BigInt doesn't seem to support bit- and, but if you don't need that, give it a shot. On Dec 27, 9:11 am, mrb_bk wrote: > This looks great, take-ubyte is basically exactly what I needed. I'll > let you know if it works when I try it out this afternoon -- not sure > what kind of work needs to be done to bring it up to date. > > On Dec 27, 1:03 am, Geoff Salmon wrote: > > > > > > > > > Hi, does the unpack function in this library do what you're looking > > for?https://github.com/geoffsalmon/bytebuffer > > It unpacks values from Java's ByteBuffer objects instead of strings, > > which seemed more appropriate in Java-land. > > > I haven't touched the code since Clojure 1.2, but if it looks useful I > > can try to bring it up to date. > > > - Geoff > > > On Dec 26, 10:03 pm, mrb_bk wrote: > > > > I also thought I would mention that I've been hanging out in #clojure > > > as mrb_bk - please hit me up if you would like to chat about this. > > > > On Dec 26, 10:08 am, mrb_bk wrote: > > > > > Hey Everyone: > > > > > I'm working on a project in Clojure that involves parsing binary data > > > > files. Specifically, I'm building a tool for analyzing Redis (http:// > > > > redis.io) dump files (.rdb format). The very beginnings of this > > > > nascent project are here:http://github.com/mrb/pianist. I am a > > > > beginner to Clojure and Lisp in general, but I'm a long time Ruby > > > > programmer with experience in C, Java, etc. During the course of > > > > working through some Clojure learning materials and general poking > > > > around the web and #clojure in IRC, I've noticed that one of my > > > > favorite tools for working with binary data from Ruby is missing in > > > > the Java/Clojure world. This is String#unpack: > > > > >http://www.ruby-doc.org/core-1.9.3/String.html#method-i-unpack > > > > > After a brief Twitter conversation with @abedra, and while I get the > > > > chance to submit my contributors agreement in order to access Clojure- > > > > dev, I thought I'd bring this topic up here. > > > > > For what it's worth, I've checked out Gloss, which is interesting but > > > > a bit too opinionated for me. Plus I believe that something to this > > > > effect should be part of clojure core - it seems that easy interface > > > > for lazily handling binary data as seqs doesn't exist as such right > > > > now. > > > > > If anyone has comments on the beginnings of my codebase (be gentle), > > > > or thoughts about implementing something similar to String#unpack, or > > > > a suggestion of an alternative set of tools I could use, that would be > > > > great. Thanks! > > > > > Mike > > > > twitter.com/mrb_bk > > > > github.com/mrb -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
On Wed, Dec 28, 2011 at 1:46 AM, Louis Yu Lu wrote: > The proposed syntax sugar does not break the existing code clojure.core=> map(first [[1] [2]]) # [1] Ambrose -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
Louis, obviously there's a problem here, the REPL should return user=> (map first [[1] [2]]) (1 2) As for my point about macros, it's not about the calls, it's about macro processing before spitting out the code that will be compiled, what would this return ? user=> (defmacro mymac [func] (let [args (rest func)] `(- ~@args))) #'user/mymac Presently: user=> (mymac (+ 1 2 3)) -4 What about (mymac + (1 2 3)) ? Would + (1 2 3) be considered as one argument ? Why ? How the compiler achieve this grouping ? If the macro argument involves a list ([&body] being a common example) how do you decide what is a real list versus a call using your new syntax in the variable list of arguments ? If you cannot deal with this and have to force (mymac (+ 1 2 3)) when a macro is involved then what's the use of this new syntax ? What about embedded calls involving a mix of fns and macros ? I cannot see people having to dig to find out if some of these calls are macros versus fns and change the shape according to what is being called. You missed the point that I made about the fact that code is data and can be modified accordingly either through macros or runtime evaluations. Luc On Wed, 28 Dec 2011 01:59:12 +0800 Ambrose Bonnaire-Sergeant wrote: > On Wed, Dec 28, 2011 at 1:46 AM, Louis Yu Lu > wrote: > > > The proposed syntax sugar does not break the existing code > > > clojure.core=> map(first [[1] [2]]) > # > [1] > > > Ambrose > -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
I don't see the point of your proposed syntactic change, and I just can't imagine it gaining traction. In my view, there are more pressing and important issues than trying to cater to the needs of people that are scared by (f x) as opposed to f(x). Since programming languages are artificial constructs, a programmer's sense of what is aesthetic usually seems dominated by the languages and tools with which they are familiar. I understand the desire to make clojure into what they already know, but I suspect those people would find greater benefit in approaching something new with open eyes and trying to understand it on its own terms. However, if it has such great value for you, you can always write your own reader which behaves as you like. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
On Mon, 2011-12-26 at 10:09 -0800, Louis Yu Lu wrote:
> Recently, I found freedom of coding playing with Clojure with over 20
> years’ experience on other program languages, Previously, I had
> several trials of learning Lisp, but never got traction.
>
> However there are two syntax notations always bother me, it feels
> unnatural with my experience on other programming languages and math:
>
> 1)Prefix operator for math formula. Jeffrey Bester’s math library
> https://github.com/jbester/cljext/blob/master/cljext/math.clj has
> brought in the infix notation and solved the problem;
> 2)The leading item of a list follows the parenthesis when it serves
> as a function name, (f x) instead of f(x). I am fully aware of many
> discussions on alternative syntax for Clojure and Lisp in the past,
> one stream is here
> http://groups.google.com/group/clojure/browse_thread/thread/319a1c77ed718ba/3e4be7484b7cbe38
> My proposition is enhance Clojure to accept both (f x) and f(x), the
> leading item can appear either after ‘(‘ as usual with classic Lisp
> notion:
> (println "Hello," "world!")
> or with conventional function call notation:
> println("Hello," "world!")
> The f(x) notation is just a syntax sugar, the only restriction is no
> space between the leading item and '('. If one or more spaces in
> between, the item will be treated as a separate symbol. Either notion
> or a mix of them can be used in the same program. Here are some
> examples:
>
> ; classic Lisp syntax notation
> (defn pig-latin [word]
> (let [first-letter (first word)]
> (if (.contains "aeiou" (str first-letter))
> (str word "ay")
> (str (subs word 1) first-letter "ay"
> (println (pig-latin "red"))
> (println (pig-latin "orange"))
>
> ; f(x) syntax notation
> defn(pig-latin [word]
> let( [first-letter first(word)]
> if(.contains("aeiou", str(first-letter))
> str(word, "ay")
> str(subs(word, 1), first-letter, "ay"
> println(pig-latin("red"))
> println(pig-latin("orange"))
>
> ; classic Lisp syntax notation
> (defn fib [n]
>(if (< n 2)
>1
> (+ (fib (dec n) ) (fib (- n 2)
> (fib 36)
>
> ; mix of two notations
> defn(fib [n]
>if((< n 2)
>1
>(+ fib(dec(n)) fib((- n 2)))
>)
> )
> fib(36)
>
> I have made minor changes (dozen lines) in one file (LispReader.java)
> from Clojure source repository to implement this syntax sugar(code
> posted at https://github.com/louisyulu/clojure-fx). It works with well-
> formed classic Clojure code and the proposed notation.
> Running the test suite from Clojure distribution results two error:
> One in the file compilation.clj line 90:
> (recur y ^Long(rem x y)]
> The problem is ^Long(… becomes function call, the fix is adding a
> space in between
> (recur y ^Long (rem x y)]
>
> The second is in the file sequences.clj line 1131:
> (is (=(partition-by #{\a \e \i \o \u} "abcdefghijklm")
> The problem is (=(… , ‘=’ is associated with following ‘(‘, the
> intention was the previous ‘(‘, the fix is also adding a space in
> between
> (is (= (partition-by #{\a \e \i \o \u} "abcdefghijklm")
>
> These two cases are caused by the not well-formed Clojure code
> (strictly speaking, each item in the list should be separated by a
> space).
>
> The proposed syntax sugar apparently pleases my eyes and fingers from
> conventional languages. With some experiments, I found the code is
> more readable for me to use f(x) notation for function call, and (op
> x) for operator.
>
> I like to hear from the community what kind of dark corner the
> proposed syntax sugar may run into.
>
> Thanks,
> Louis
>
This is an idea that happens quite frequently. Axiom, a lisp-based
computer algebra system, originally had a "syntactic sugar" almost
exactly like the one proposed. I uploaded an ancient design
document for this kind of language syntax, called "boot". See
http://daly.axiom-developer.org/boot.tgz
This turned into a huge point of discussion. The Axiom decision
to remove this "boot" language eventually resulted in a fork of
the Axiom project.
Based on long experience I would strongly recommend NOT going
down this path.
Tim Daly
--
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
Uniform exceptions – Clojure and ClojureScript?
Hi, Given that Java and JavaScript have different exception semantics (Java requiring AOT compiled class derived from java.lang.Exception/ java.lang.Throwable and such) I would like to ask the community if anybody has come up with an approach to raise and catch exceptions that work uniformly across Clojure and ClojureScript. Even a way to get the lowest-common-denominator should be OK. Any pointers would be appreciated. Regards, Shantanu -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
I don't see a reason for f(x) sugar, but if I had to do some complex
formulas I'd consider looking into a macro to enable infix math.
On Dec 27, 2011 2:44 PM, "daly" wrote:
> On Mon, 2011-12-26 at 10:09 -0800, Louis Yu Lu wrote:
> > Recently, I found freedom of coding playing with Clojure with over 20
> > years’ experience on other program languages, Previously, I had
> > several trials of learning Lisp, but never got traction.
> >
> > However there are two syntax notations always bother me, it feels
> > unnatural with my experience on other programming languages and math:
> >
> > 1)Prefix operator for math formula. Jeffrey Bester’s math library
> > https://github.com/jbester/cljext/blob/master/cljext/math.clj has
> > brought in the infix notation and solved the problem;
> > 2)The leading item of a list follows the parenthesis when it serves
> > as a function name, (f x) instead of f(x). I am fully aware of many
> > discussions on alternative syntax for Clojure and Lisp in the past,
> > one stream is here
> http://groups.google.com/group/clojure/browse_thread/thread/319a1c77ed718ba/3e4be7484b7cbe38
> > My proposition is enhance Clojure to accept both (f x) and f(x), the
> > leading item can appear either after ‘(‘ as usual with classic Lisp
> > notion:
> > (println "Hello," "world!")
> > or with conventional function call notation:
> > println("Hello," "world!")
> > The f(x) notation is just a syntax sugar, the only restriction is no
> > space between the leading item and '('. If one or more spaces in
> > between, the item will be treated as a separate symbol. Either notion
> > or a mix of them can be used in the same program. Here are some
> > examples:
> >
> > ; classic Lisp syntax notation
> > (defn pig-latin [word]
> > (let [first-letter (first word)]
> > (if (.contains "aeiou" (str first-letter))
> > (str word "ay")
> > (str (subs word 1) first-letter "ay"
> > (println (pig-latin "red"))
> > (println (pig-latin "orange"))
> >
> > ; f(x) syntax notation
> > defn(pig-latin [word]
> > let( [first-letter first(word)]
> > if(.contains("aeiou", str(first-letter))
> > str(word, "ay")
> > str(subs(word, 1), first-letter, "ay"
> > println(pig-latin("red"))
> > println(pig-latin("orange"))
> >
> > ; classic Lisp syntax notation
> > (defn fib [n]
> >(if (< n 2)
> >1
> > (+ (fib (dec n) ) (fib (- n 2)
> > (fib 36)
> >
> > ; mix of two notations
> > defn(fib [n]
> >if((< n 2)
> >1
> >(+ fib(dec(n)) fib((- n 2)))
> >)
> > )
> > fib(36)
> >
> > I have made minor changes (dozen lines) in one file (LispReader.java)
> > from Clojure source repository to implement this syntax sugar(code
> > posted at https://github.com/louisyulu/clojure-fx). It works with well-
> > formed classic Clojure code and the proposed notation.
> > Running the test suite from Clojure distribution results two error:
> > One in the file compilation.clj line 90:
> > (recur y ^Long(rem x y)]
> > The problem is ^Long(… becomes function call, the fix is adding a
> > space in between
> > (recur y ^Long (rem x y)]
> >
> > The second is in the file sequences.clj line 1131:
> > (is (=(partition-by #{\a \e \i \o \u} "abcdefghijklm")
> > The problem is (=(… , ‘=’ is associated with following ‘(‘, the
> > intention was the previous ‘(‘, the fix is also adding a space in
> > between
> > (is (= (partition-by #{\a \e \i \o \u} "abcdefghijklm")
> >
> > These two cases are caused by the not well-formed Clojure code
> > (strictly speaking, each item in the list should be separated by a
> > space).
> >
> > The proposed syntax sugar apparently pleases my eyes and fingers from
> > conventional languages. With some experiments, I found the code is
> > more readable for me to use f(x) notation for function call, and (op
> > x) for operator.
> >
> > I like to hear from the community what kind of dark corner the
> > proposed syntax sugar may run into.
> >
> > Thanks,
> > Louis
> >
>
> This is an idea that happens quite frequently. Axiom, a lisp-based
> computer algebra system, originally had a "syntactic sugar" almost
> exactly like the one proposed. I uploaded an ancient design
> document for this kind of language syntax, called "boot". See
> http://daly.axiom-developer.org/boot.tgz
>
> This turned into a huge point of discussion. The Axiom decision
> to remove this "boot" language eventually resulted in a fork of
> the Axiom project.
>
> Based on long experience I would strongly recommend NOT going
> down this path.
>
> Tim Daly
>
>
> --
> 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/gr
clojure.math.combinatorics jar
Do we have this jar in clojars? Searched for it under "math" but could not find it. Found version 0.0.2 in mvnrepository.com but it is not the the version 0.0.3-SNAPSHOT mentioned in https://github.com/clojure/math.combinatorics/blob/master/pom.xml -- 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
clojure.math.combinatorics jar
Do we have this jar in clojars? Searched for it under "math" but could not find it. Found version 0.0.2 in mvnrepository.com but it is not the the version 0.0.3-SNAPSHOT mentioned in https://github.com/clojure/math.combinatorics/blob/master/pom.xml -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
Luc, I see you and other people put great points on this subject, that is exactly what I wanted to know about the 'dark corner' in my initial post. Just for your info, I have tried on the modified reader, the following alternatives all works: Clojure 1.4.0-master-SNAPSHOT user=> (map first [[1] [2]]) (1 2) user=> map(first [[1] [2]]) (1 2) user=> (defmacro mymac [func] (let [args (rest func)] `(- ~@args))) #'user/mymac user=> (mymac (+ 1 2 3)) -4 user=> mymac((+ 1 2 3)) -4 user=> mymac(+(1 2 3)) -4 Thanks, Louis On Dec 27, 1:40 pm, Luc Prefontaine wrote: > Louis, obviously there's a problem here, the REPL should return > > user=> (map first [[1] [2]]) > (1 2) > > As for my point about macros, it's not about the calls, it's about macro > processing before > spitting out the code that will be compiled, what would this return ? > > user=> (defmacro mymac [func] > (let [args (rest func)] > `(- ~@args))) > #'user/mymac > > Presently: > > user=> (mymac (+ 1 2 3)) > -4 > > What about (mymac + (1 2 3)) ? Would + (1 2 3) be considered as one argument > ? Why ? How the compiler achieve this grouping ? > If the macro argument involves a list ([&body] being a common example) how do > you decide what is a real > list versus a call using your new syntax in the variable list of arguments ? > > If you cannot deal with this and have to force (mymac (+ 1 2 3)) when a macro > is involved then what's the use > of this new syntax ? > > What about embedded calls involving a mix of fns and macros ? > I cannot see people having to dig to find out if some of these calls are > macros versus fns and change the shape according to > what is being called. > > You missed the point that I made about the fact that code is data and can be > modified accordingly either through macros > or runtime evaluations. > > Luc > > On Wed, 28 Dec 2011 01:59:12 +0800 > > Ambrose Bonnaire-Sergeant wrote: > > On Wed, Dec 28, 2011 at 1:46 AM, Louis Yu Lu > > wrote: > > > > The proposed syntax sugar does not break the existing code > > > clojure.core=> map(first [[1] [2]]) > > # > > [1] > > > Ambrose > > -- > Luc P. > > > The rabid Muppet -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
So if I understand correctly, your proposal makes the absence/presence of space pivotal in making the decision about parsing infix/postfix notation ? Luc > Luc, > I see you and other people put great points on this subject, that is > exactly what I wanted to know about the 'dark corner' in my initial > post. > Just for your info, I have tried on the modified reader, the following > alternatives all works: > > Clojure 1.4.0-master-SNAPSHOT > user=> (map first [[1] [2]]) > (1 2) > user=> map(first [[1] [2]]) > (1 2) > user=> (defmacro mymac [func] >(let [args (rest func)] > `(- ~@args))) > #'user/mymac > user=> (mymac (+ 1 2 3)) > -4 > user=> mymac((+ 1 2 3)) > -4 > user=> mymac(+(1 2 3)) > -4 > > Thanks, > Louis > > > On Dec 27, 1:40 pm, Luc Prefontaine > wrote: > > Louis, obviously there's a problem here, the REPL should return > > > > user=> (map first [[1] [2]]) > > (1 2) > > > > As for my point about macros, it's not about the calls, it's about macro > > processing before > > spitting out the code that will be compiled, what would this return ? > > > > user=> (defmacro mymac [func] > > (let [args (rest func)] > > `(- ~@args))) > > #'user/mymac > > > > Presently: > > > > user=> (mymac (+ 1 2 3)) > > -4 > > > > What about (mymac + (1 2 3)) ? Would + (1 2 3) be considered as one > > argument ? Why ? How the compiler achieve this grouping ? > > If the macro argument involves a list ([&body] being a common example) how > > do you decide what is a real > > list versus a call using your new syntax in the variable list of arguments ? > > > > If you cannot deal with this and have to force (mymac (+ 1 2 3)) when a > > macro is involved then what's the use > > of this new syntax ? > > > > What about embedded calls involving a mix of fns and macros ? > > I cannot see people having to dig to find out if some of these calls are > > macros versus fns and change the shape according to > > what is being called. > > > > You missed the point that I made about the fact that code is data and can > > be modified accordingly either through macros > > or runtime evaluations. > > > > Luc > > > > On Wed, 28 Dec 2011 01:59:12 +0800 > > > > Ambrose Bonnaire-Sergeant wrote: > > > On Wed, Dec 28, 2011 at 1:46 AM, Louis Yu Lu > > > wrote: > > > > > > The proposed syntax sugar does not break the existing code > > > > > clojure.core=> map(first [[1] [2]]) > > > # > > > [1] > > > > > Ambrose > > > > -- > > Luc P. > > > > > > The rabid Muppet > > -- > 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 > -- Softaddicts sent by ibisMail! -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
Yes, to be exactly, the simple change in the reader is after parsing a
symbol, if the following char separating the symbol is '(', the symbol
become the leading item of the following list, otherwise it is a
regular item in the current list context.
Louis
On Dec 27, 4:16 pm, Softaddicts wrote:
> So if I understand correctly, your proposal makes the absence/presence of
> space pivotal
> in making the decision about parsing infix/postfix notation ?
>
> Luc
>
>
>
>
>
>
>
>
>
> > Luc,
> > I see you and other people put great points on this subject, that is
> > exactly what I wanted to know about the 'dark corner' in my initial
> > post.
> > Just for your info, I have tried on the modified reader, the following
> > alternatives all works:
>
> > Clojure 1.4.0-master-SNAPSHOT
> > user=> (map first [[1] [2]])
> > (1 2)
> > user=> map(first [[1] [2]])
> > (1 2)
> > user=> (defmacro mymac [func]
> > (let [args (rest func)]
> > `(- ~@args)))
> > #'user/mymac
> > user=> (mymac (+ 1 2 3))
> > -4
> > user=> mymac((+ 1 2 3))
> > -4
> > user=> mymac(+(1 2 3))
> > -4
>
> > Thanks,
> > Louis
>
> > On Dec 27, 1:40 pm, Luc Prefontaine
> > wrote:
> > > Louis, obviously there's a problem here, the REPL should return
>
> > > user=> (map first [[1] [2]])
> > > (1 2)
>
> > > As for my point about macros, it's not about the calls, it's about macro
> > > processing before
> > > spitting out the code that will be compiled, what would this return ?
>
> > > user=> (defmacro mymac [func]
> > > (let [args (rest func)]
> > > `(- ~@args)))
> > > #'user/mymac
>
> > > Presently:
>
> > > user=> (mymac (+ 1 2 3))
> > > -4
>
> > > What about (mymac + (1 2 3)) ? Would + (1 2 3) be considered as one
> > > argument ? Why ? How the compiler achieve this grouping ?
> > > If the macro argument involves a list ([&body] being a common example)
> > > how do you decide what is a real
> > > list versus a call using your new syntax in the variable list of
> > > arguments ?
>
> > > If you cannot deal with this and have to force (mymac (+ 1 2 3)) when a
> > > macro is involved then what's the use
> > > of this new syntax ?
>
> > > What about embedded calls involving a mix of fns and macros ?
> > > I cannot see people having to dig to find out if some of these calls are
> > > macros versus fns and change the shape according to
> > > what is being called.
>
> > > You missed the point that I made about the fact that code is data and can
> > > be modified accordingly either through macros
> > > or runtime evaluations.
>
> > > Luc
>
> > > On Wed, 28 Dec 2011 01:59:12 +0800
>
> > > Ambrose Bonnaire-Sergeant wrote:
> > > > On Wed, Dec 28, 2011 at 1:46 AM, Louis Yu Lu
> > > > wrote:
>
> > > > > The proposed syntax sugar does not break the existing code
>
> > > > clojure.core=> map(first [[1] [2]])
> > > > #
> > > > [1]
>
> > > > Ambrose
>
> > > --
> > > Luc P.
>
> > >
> > > The rabid Muppet
>
> > --
> > 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
>
> --
> Softaddicts sent by ibisMail!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
Do you support this?
classic: ((foo bar) baz)
your syntax: foo(bar)(baz)
Scott
On Mon, Dec 26, 2011 at 1:09 PM, Louis Yu Lu wrote:
> Recently, I found freedom of coding playing with Clojure with over 20
> years’ experience on other program languages, Previously, I had
> several trials of learning Lisp, but never got traction.
>
> However there are two syntax notations always bother me, it feels
> unnatural with my experience on other programming languages and math:
>
> 1) Prefix operator for math formula. Jeffrey Bester’s math library
> https://github.com/jbester/cljext/blob/master/cljext/math.clj has
> brought in the infix notation and solved the problem;
> 2) The leading item of a list follows the parenthesis when it serves
> as a function name, (f x) instead of f(x). I am fully aware of many
> discussions on alternative syntax for Clojure and Lisp in the past,
> one stream is here
> http://groups.google.com/group/clojure/browse_thread/thread/319a1c77ed718ba/3e4be7484b7cbe38
> My proposition is enhance Clojure to accept both (f x) and f(x), the
> leading item can appear either after ‘(‘ as usual with classic Lisp
> notion:
> (println "Hello," "world!")
> or with conventional function call notation:
>println("Hello," "world!")
> The f(x) notation is just a syntax sugar, the only restriction is no
> space between the leading item and '('. If one or more spaces in
> between, the item will be treated as a separate symbol. Either notion
> or a mix of them can be used in the same program. Here are some
> examples:
>
> ; classic Lisp syntax notation
> (defn pig-latin [word]
> (let [first-letter (first word)]
>(if (.contains "aeiou" (str first-letter))
> (str word "ay")
> (str (subs word 1) first-letter "ay"
> (println (pig-latin "red"))
> (println (pig-latin "orange"))
>
> ; f(x) syntax notation
> defn(pig-latin [word]
> let( [first-letter first(word)]
>if(.contains("aeiou", str(first-letter))
> str(word, "ay")
> str(subs(word, 1), first-letter, "ay"
> println(pig-latin("red"))
> println(pig-latin("orange"))
>
> ; classic Lisp syntax notation
> (defn fib [n]
> (if (< n 2)
> 1
> (+ (fib (dec n) ) (fib (- n 2)
> (fib 36)
>
> ; mix of two notations
> defn(fib [n]
> if((< n 2)
> 1
> (+ fib(dec(n)) fib((- n 2)))
> )
> )
> fib(36)
>
> I have made minor changes (dozen lines) in one file (LispReader.java)
> from Clojure source repository to implement this syntax sugar(code
> posted at https://github.com/louisyulu/clojure-fx). It works with well-
> formed classic Clojure code and the proposed notation.
> Running the test suite from Clojure distribution results two error:
> One in the file compilation.clj line 90:
> (recur y ^Long(rem x y)]
> The problem is ^Long(… becomes function call, the fix is adding a
> space in between
> (recur y ^Long (rem x y)]
>
> The second is in the file sequences.clj line 1131:
>(is (=(partition-by #{\a \e \i \o \u} "abcdefghijklm")
> The problem is (=(… , ‘=’ is associated with following ‘(‘, the
> intention was the previous ‘(‘, the fix is also adding a space in
> between
>(is (= (partition-by #{\a \e \i \o \u} "abcdefghijklm")
>
> These two cases are caused by the not well-formed Clojure code
> (strictly speaking, each item in the list should be separated by a
> space).
>
> The proposed syntax sugar apparently pleases my eyes and fingers from
> conventional languages. With some experiments, I found the code is
> more readable for me to use f(x) notation for function call, and (op
> x) for operator.
>
> I like to hear from the community what kind of dark corner the
> proposed syntax sugar may run into.
>
> Thanks,
> Louis
>
>
>
>
>
>
>
>
>
> --
> 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
Using the absence/presence of a space to influence parsing bugs me a lot...
No idea about using an explicit delimiter ?
My main concern is how can the reader report a decent error message
if there's an input mistake in this context ? I feel that a mistake
can have far reaching side effects because it will change evaluation
of the forms and some odd behaviors could result from such a mistake
Luc
> Yes, to be exactly, the simple change in the reader is after parsing a
> symbol, if the following char separating the symbol is '(', the symbol
> become the leading item of the following list, otherwise it is a
> regular item in the current list context.
>
> Louis
>
> On Dec 27, 4:16 pm, Softaddicts wrote:
> > So if I understand correctly, your proposal makes the absence/presence of
> > space pivotal
> > in making the decision about parsing infix/postfix notation ?
> >
> > Luc
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > Luc,
> > > I see you and other people put great points on this subject, that is
> > > exactly what I wanted to know about the 'dark corner' in my initial
> > > post.
> > > Just for your info, I have tried on the modified reader, the following
> > > alternatives all works:
> >
> > > Clojure 1.4.0-master-SNAPSHOT
> > > user=> (map first [[1] [2]])
> > > (1 2)
> > > user=> map(first [[1] [2]])
> > > (1 2)
> > > user=> (defmacro mymac [func]
> > >(let [args (rest func)]
> > > `(- ~@args)))
> > > #'user/mymac
> > > user=> (mymac (+ 1 2 3))
> > > -4
> > > user=> mymac((+ 1 2 3))
> > > -4
> > > user=> mymac(+(1 2 3))
> > > -4
> >
> > > Thanks,
> > > Louis
> >
> > > On Dec 27, 1:40 pm, Luc Prefontaine
> > > wrote:
> > > > Louis, obviously there's a problem here, the REPL should return
> >
> > > > user=> (map first [[1] [2]])
> > > > (1 2)
> >
> > > > As for my point about macros, it's not about the calls, it's about
> > > > macro processing before
> > > > spitting out the code that will be compiled, what would this return ?
> >
> > > > user=> (defmacro mymac [func]
> > > > (let [args (rest func)]
> > > > `(- ~@args)))
> > > > #'user/mymac
> >
> > > > Presently:
> >
> > > > user=> (mymac (+ 1 2 3))
> > > > -4
> >
> > > > What about (mymac + (1 2 3)) ? Would + (1 2 3) be considered as one
> > > > argument ? Why ? How the compiler achieve this grouping ?
> > > > If the macro argument involves a list ([&body] being a common example)
> > > > how do you decide what is a real
> > > > list versus a call using your new syntax in the variable list of
> > > > arguments ?
> >
> > > > If you cannot deal with this and have to force (mymac (+ 1 2 3)) when a
> > > > macro is involved then what's the use
> > > > of this new syntax ?
> >
> > > > What about embedded calls involving a mix of fns and macros ?
> > > > I cannot see people having to dig to find out if some of these calls
> > > > are macros versus fns and change the shape according to
> > > > what is being called.
> >
> > > > You missed the point that I made about the fact that code is data and
> > > > can be modified accordingly either through macros
> > > > or runtime evaluations.
> >
> > > > Luc
> >
> > > > On Wed, 28 Dec 2011 01:59:12 +0800
> >
> > > > Ambrose Bonnaire-Sergeant wrote:
> > > > > On Wed, Dec 28, 2011 at 1:46 AM, Louis Yu Lu
> > > > > wrote:
> >
> > > > > > The proposed syntax sugar does not break the existing code
> >
> > > > > clojure.core=> map(first [[1] [2]])
> > > > > #
> > > > > [1]
> >
> > > > > Ambrose
> >
> > > > --
> > > > Luc P.
> >
> > > >
> > > > The rabid Muppet
> >
> > > --
> > > 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
> >
> > --
> > Softaddicts sent by ibisMail!
>
> --
> 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
>
--
Softaddicts sent by ibisMail!
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Uniform exceptions – Clojure and ClojureScript?
I believe the capability to have a portable solution in specific cases is in the pipeline https://github.com/clojure/clojurescript/wiki/Exception-Handling -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
I am not suggesting switching the whole Lisp syntax, just provide a
'sugar'
((foo bar) baz) can written as (foo(bar) baz)
On Dec 27, 4:35 pm, Scott Jaderholm wrote:
> Do you support this?
>
> classic: ((foo bar) baz)
> your syntax: foo(bar)(baz)
>
> Scott
>
> On Mon, Dec 26, 2011 at 1:09 PM, Louis Yu Lu wrote:
>
>
>
>
>
>
>
> > Recently, I found freedom of coding playing with Clojure with over 20
> > years’ experience on other program languages, Previously, I had
> > several trials of learning Lisp, but never got traction.
>
> > However there are two syntax notations always bother me, it feels
> > unnatural with my experience on other programming languages and math:
>
> > 1) Prefix operator for math formula. Jeffrey Bester’s math library
> >https://github.com/jbester/cljext/blob/master/cljext/math.cljhas
> > brought in the infix notation and solved the problem;
> > 2) The leading item of a list follows the parenthesis when it serves
> > as a function name, (f x) instead of f(x). I am fully aware of many
> > discussions on alternative syntax for Clojure and Lisp in the past,
> > one stream is here
> >http://groups.google.com/group/clojure/browse_thread/thread/319a1c77e...
> > My proposition is enhance Clojure to accept both (f x) and f(x), the
> > leading item can appear either after ‘(‘ as usual with classic Lisp
> > notion:
> > (println "Hello," "world!")
> > or with conventional function call notation:
> > println("Hello," "world!")
> > The f(x) notation is just a syntax sugar, the only restriction is no
> > space between the leading item and '('. If one or more spaces in
> > between, the item will be treated as a separate symbol. Either notion
> > or a mix of them can be used in the same program. Here are some
> > examples:
>
> > ; classic Lisp syntax notation
> > (defn pig-latin [word]
> > (let [first-letter (first word)]
> > (if (.contains "aeiou" (str first-letter))
> > (str word "ay")
> > (str (subs word 1) first-letter "ay"
> > (println (pig-latin "red"))
> > (println (pig-latin "orange"))
>
> > ; f(x) syntax notation
> > defn(pig-latin [word]
> > let( [first-letter first(word)]
> > if(.contains("aeiou", str(first-letter))
> > str(word, "ay")
> > str(subs(word, 1), first-letter, "ay"
> > println(pig-latin("red"))
> > println(pig-latin("orange"))
>
> > ; classic Lisp syntax notation
> > (defn fib [n]
> > (if (< n 2)
> > 1
> > (+ (fib (dec n) ) (fib (- n 2)
> > (fib 36)
>
> > ; mix of two notations
> > defn(fib [n]
> > if((< n 2)
> > 1
> > (+ fib(dec(n)) fib((- n 2)))
> > )
> > )
> > fib(36)
>
> > I have made minor changes (dozen lines) in one file (LispReader.java)
> > from Clojure source repository to implement this syntax sugar(code
> > posted athttps://github.com/louisyulu/clojure-fx). It works with well-
> > formed classic Clojure code and the proposed notation.
> > Running the test suite from Clojure distribution results two error:
> > One in the file compilation.clj line 90:
> > (recur y ^Long(rem x y)]
> > The problem is ^Long(… becomes function call, the fix is adding a
> > space in between
> > (recur y ^Long (rem x y)]
>
> > The second is in the file sequences.clj line 1131:
> > (is (=(partition-by #{\a \e \i \o \u} "abcdefghijklm")
> > The problem is (=(… , ‘=’ is associated with following ‘(‘, the
> > intention was the previous ‘(‘, the fix is also adding a space in
> > between
> > (is (= (partition-by #{\a \e \i \o \u} "abcdefghijklm")
>
> > These two cases are caused by the not well-formed Clojure code
> > (strictly speaking, each item in the list should be separated by a
> > space).
>
> > The proposed syntax sugar apparently pleases my eyes and fingers from
> > conventional languages. With some experiments, I found the code is
> > more readable for me to use f(x) notation for function call, and (op
> > x) for operator.
>
> > I like to hear from the community what kind of dark corner the
> > proposed syntax sugar may run into.
>
> > Thanks,
> > Louis
>
> > --
> > 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 post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
The modified reader will report no more, no less parsing error than
the current Clojure reader.
On Dec 27, 4:40 pm, Softaddicts wrote:
> Using the absence/presence of a space to influence parsing bugs me a lot...
>
> No idea about using an explicit delimiter ?
> My main concern is how can the reader report a decent error message
> if there's an input mistake in this context ? I feel that a mistake
> can have far reaching side effects because it will change evaluation
> of the forms and some odd behaviors could result from such a mistake
>
> Luc
>
>
>
>
>
>
>
>
>
> > Yes, to be exactly, the simple change in the reader is after parsing a
> > symbol, if the following char separating the symbol is '(', the symbol
> > become the leading item of the following list, otherwise it is a
> > regular item in the current list context.
>
> > Louis
>
--
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
Clojurescript field access syntax
I'm not sure if this is the right place to discuss it but I've found that on Confluence: http://dev.clojure.org/display/design/Unified+ClojureScript+and+Clojure+field+access+syntax discussing the non-uniform Clojure/Clojurescript field access semantics. Just to add my 2 cents... to me it would be obvious to implement "memfn" for accessing member functions in Clojurescript. This would IMHO most closely resemble Clojure semantics. cheers, Tom -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
I don't usually reply to this sort of thread, but I'll toss in two
cents worth anyway. Speaking as a PHP programmer wading his way
through the beginning-to-intermediate stages of Clojure, I have to say
that I do not like the proposed "sugar." If I wanted to write PHP in
Clojure, I'd just write PHP, because I already know that. What Clojure
has that PHP lacks is an elegant simplicity to its syntax, which is a
direct result of its consistent treatment of parentheses. To introduce
new forms would unnecessarily complicate things and obscure this
fundamental consistency. If I see
(foo "thing")
bar("other thing")
it looks to me like there should be some significant difference
between foo and bar, and how they are used. Syntactic sugar ought to
simplify difficult things, not complicate things that are already
simple. If we did have such sugar, I would think we ought to hide it
from beginners, so as to avoid confusing them unnecessarily. But then
what would be the point of having it?
Parens just aren't a big deal. Would HTML be easier to learn if we
wrote "div<>" instead of ""? My kids can learn to write web
pages; I can't imagine an experienced programmer would really be all
that put off by the order of the first two symbols. If anything, it's
the nesting that's the real problem, and that's not really solved by
swapping the first "(" and "foo".
Sorry for being so negative--I do appreciate your good intentions, and
you do have a worthwhile goal. Also, it's just my personal opinion,
which doesn't count for much, so just take it for what it's worth.
m
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
On 26/12/2011, at 6:23 PM, Louis Yu Lu wrote: > My proposition is enhance Clojure to accept both (f x) and f(x) Fortunately, I don't see that happening, for several reasons (many of which have been mentioned). It adds complexity, causes confusion and inconsistent coding styles and it will break everything that parses s-expressions (data = code after all). Imagine trying to read lisp code that is a mix-n-match of the following: ;; the following would be equivalent: (g (f a b)) (g f(a b)) g((f a b)) g(f(a b)) ;; the following would be equivalent: ((f a) b) (f(a) b) (f a)(b) f(a)(b) FOUR different ways of expressing ((f a) b). How is that helping those trying to learn Clojure? Also, note that (g f(a b)) and (g f (a b)) have very different semantics, even though the only difference is the added whitespace between two tokens. If you stick with the elegant simplicity of s-expressions for a few more weeks, I promise that you won't even notice it anymore and you'll find that it's perfectly readable. cheers, gert -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
On 26 December 2011 18:09, Louis Yu Lu wrote:
> My proposition is enhance Clojure to accept both (f x) and f(x), the
> leading item can appear either after ‘(‘ as usual with classic Lisp
> notion:
> (println "Hello," "world!")
> or with conventional function call notation:
> println("Hello," "world!")
> The f(x) notation is just a syntax sugar, the only restriction is no
> space between the leading item and '('. If one or more spaces in
> between, the item will be treated as a separate symbol.
This seems a -really- bad idea. I doubt there's any chance whatsoever
of this being adopted in Clojure.
Here's some reasons why not:
1. Using a single space to differentiate two completely different data
structures seems prone to error. e.g. (f (g x)) != (f(g x)).
2. The syntax is inconsistent with other data structures, unless you
make f[x] = [f x] and f{x} = {f x}
3. It obscures the fact we're dealing with lists. When I see f(x), it
doesn't intuitively look like a list of two elements, whilst (f x)
does.
4. Two syntaxes for defining lists would make maintaining Clojure
programs -really- annoying.
5. It's incompatible with Lisp-aware editors like Emacs/Paredit.
I'm sure there are more reasons, but those should be enough
considering the only advantage is to make Clojure slightly more
approachable. And really, having a different syntax is good, because
it helps enforce the idea that (f x) is a data structure, not just a
function call.
- James
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: Clojure list syntax sugar: f(x) notation
Overall, it's a lot of effort (not the patch but the tests) and there's a significant potential to cripple future additions more in line with the current syntax. Infix notation to be safe implies the use of a lot more delimiters to avoid ambiguities. Clojure is not going at all in this direction. It feels like these pre-school games were you need to fit pieces of different shapes in holes. More or less trying to make a circle fit into a triangle shaped hole... Looks a lot simpler to work on the mental restriction.. I have no idea why this postfix thing has such a huge impact on people. It looks to me more like some form of conservatism than anything else. Brains are flexible and can remodel themselves even in elderly people :) Luc > On 26/12/2011, at 6:23 PM, Louis Yu Lu wrote: > > > My proposition is enhance Clojure to accept both (f x) and f(x) > > Fortunately, I don't see that happening, for several reasons (many of which > have been mentioned). It adds complexity, causes confusion and inconsistent > coding styles and it will break everything that parses s-expressions (data = > code after all). Imagine trying to read lisp code that is a mix-n-match of > the following: > > ;; the following would be equivalent: > (g (f a b)) > (g f(a b)) > g((f a b)) > g(f(a b)) > > ;; the following would be equivalent: > ((f a) b) > (f(a) b) > (f a)(b) > f(a)(b) > > FOUR different ways of expressing ((f a) b). How is that helping those trying > to learn Clojure? > > Also, note that (g f(a b)) and (g f (a b)) have very different semantics, > even though the only difference is the added whitespace between two tokens. > > If you stick with the elegant simplicity of s-expressions for a few more > weeks, I promise that you won't even notice it anymore and you'll find that > it's perfectly readable. > > cheers, > gert > > -- > 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 > -- Softaddicts sent by ibisMail! -- 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
How to start using clojureCLR?
Hi group, I just joined the group and I'm really hypnotized with the Clojure language. Most of the time in my day job I do .Net development but outside of the job I'm always trying to learn and apply other languages and technologies. The curse of the mainstream. I've just finished Stuart's book "Programming Clojure" and I would like to start introducing some fun in my day to day programming, and when I saw ClojureCLR I was really happy. The point is that I don't know where to start, I haven't found anything that explain how to start working with it. Any blog on how to prepare the environment and start using introducing clojure on my .Net projects ? I'm also curious about ClojureScript, I've been looking CoffeeScript and there are some tools that even integrate with Visual Studio allowing to generate the JavaScript file associate with the CoffeeScript, is there anything like that for ClojureScript? Is it recommended to use ClojureScript in the same scenarios as CoffeeScript or they should serve different purposes? I probably should have two questions, but I see so many opportunities to use Clojure right now that I don't want to miss anything. Thanks in advance and let me know where can I find some information, even if you feel is irrelevant maybe for me is a gold mine. Erlis -- 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
extracting the execution time of a function ...
Hi, I am new to learning clojure, and I am hoping there is a solution to something that is not obvious to me ... I have a function that I want to run multiple times, measure the time it takes to execute each function, and put those numbers in a vector. I would like to process that vector further by doing things like max, min and average, and I think I can do that fairly "easily", but I'm having trouble generating such a vector in the first place. For instance when I do this: => (dorun (repeatedly 3 myfunc)) I get "Elapsed time: 1253.764 msecs" "Elapsed time: 20003.997 msecs" "Elapsed time: 653.919 msecs" nil I would like to get something like [1253.764 23.997 653.919], which I can post-process. I tried a => (conj [] (dorun (repeatedly 3 myfunc))) but that just gives me a [nil]. Can anyone help? Thanks ... -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: extracting the execution time of a function ...
On Tue, Dec 27, 2011 at 2:03 PM, endbegin wrote: > Hi, > > I am new to learning clojure, and I am hoping there is a solution to > something that is not obvious to me ... I have a function that I want > to run multiple times, measure the time it takes to execute each > function, and put those numbers in a vector. I would like to process > that vector further by doing things like max, min and average, and I > think I can do that fairly "easily", but I'm having trouble generating > such a vector in the first place. > > For instance when I do this: > > => (dorun (repeatedly 3 myfunc)) > > I get > > "Elapsed time: 1253.764 msecs" > "Elapsed time: 20003.997 msecs" > "Elapsed time: 653.919 msecs" > nil > > I would like to get something like > [1253.764 23.997 653.919], which I can post-process. > > I tried a > > => (conj [] (dorun (repeatedly 3 myfunc))) > > but that just gives me a [nil]. > > Can anyone help? > > Thanks ... The time macro *prints* the time rather than *returning* it. It returns whatever the timed thing returned. For some purposes, such as yours, that is unfortunate. You may want to use something like this: (defmacro bench "Times the execution of forms, discarding their output and returning a long in nanoseconds." ([& forms] `(let [start# (System/nanoTime)] ~@forms (- (System/nanoTime) start# (untested) where you'd be able to gather results in a seq by methods like this: user=> (repeatedly 3 #(bench (foo) (bar))) (483458232 483458419 483457443) HTH. -- 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
[ANN] swank-clojure 1.3.4 released
I just pushed out version 1.3.4 of Swank Clojure. The main feature in this release is Derek Mansen's work integrating clj-stacktrace into the debugger frames, so now you can get stack traces with alignment and colorization. I'm very excited about this release since it's a significant usability improvement: http://imgur.com/fD3rA I should note that this is on a separate branch from the CDT debugger, but the next step now that 1.3.4 is out is to merge it back into the CDT-aware master branch, which should see a release soon after the underlying CDT library is released. -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com 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
[ANN] hexdump 0.1.0 released
Hello Clojure community! I'd like to announce the release of a small and simple hexdump utility. As is usually the case, this project was born out of a need I had in my own work which often requires looking at raw data dumps. This is my first time releasing any Clojure code so any feedback is very much welcome. github: https://github.com/tmciver/hexdump clojars: https://clojars.org/hexdump 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
Re: extracting the execution time of a function ...
Thanks Cedric. I did something along the lines of what you suggested (created a function instead of a macro). Here's what I did to get time in seconds: (defn run-myfunc [] (let [starttime (System/nanoTime)] (myfunc) (/ (- (System/nanoTime) starttime) 1e9))) and then to produce timings across 10 runs, (vec (repeatedly 10 run-myfunc)) produces the desired vector. -- 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
ANN: Boing update release
Hi everyone, Boing is now compatible with Clojure 1.3. Details can be found at https://github.com/lprefontaine/Boing/wiki/Using-Boing. It now depends solely on Clojure. No need for contrib anymore. Next release is planned in late January, details can be found at https://github.com/lprefontaine/Boing/wiki/Road-map. The jar files have been pushed to Clojars. Note that they are AOT compiled with no source code. This will likely change in 2012. The source code is properly tagged on Github so it's always possible to get at the source code if needed. Happy New Year... -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (:require [clojure.contrib.sql :as sql]))
I have tried the example you provided and it works except I don't see any file printout of the records when I run not as test but without test. Is test going to show any data? Can I ask for a record count? why doesn't the sql jar show for every example that is in the internet? Thanks On Dec 24, 6:59 pm, Sean Corfield wrote: > You're still not answering the question of how exactly you are > _running_ your Clojure code. > > No one is going to be able to help you if you don't provide enough > details about what _exactly_ you are doing and what error / stack > trace you are getting. > > Please also try the command sequence I showed you and see if that works. > > > > > > > > On Sat, Dec 24, 2011 at 5:27 PM, wrote: > > C:\>set classpath > > CLASSPATH=c:/opt/jars/*;c:/projects/clarity4/src > > > C:\> > > > - Original Message - From: "Sean Corfield" > > To: > > Sent: Saturday, December 24, 2011 4:30 PM > > Subject: Re: (:require [clojure.contrib.sql :as sql])) > > > On Sat, Dec 24, 2011 at 1:49 PM, wrote: > > >> I am trying to run clojure file as: > >> > >> (ns mysql > > >> (:require [clojure.contrib.sql :as sql])) > > > Looks like you're missing a line here before :subprotocol...? > > >> :subprotocol "mysql" > >> :subname "//localhost:3306/dummy" > >> :user "root" > >> :password "pass"}) > >> (defn create-users [] > >> (sql/create-table > >> :users > >> [:id :integer "PRIMARY KEY" "AUTO_INCREMENT"] > >> [:fname "varchar(25)"] > >> [:lname "varchar(25)"])) > > >> (defn drop-users [] > >> (sql/drop-table :users)) > >> (sql/with-connection db > >> (create-users)) > >> (defn insert-user [fname lname] > >> (sql/insert-values :users [:fname :lname] [fname lname])) > > >> (sql/with-connection db > >> (insert-user "Sandy" "Brown")) > >> (sql/with-connection db > >> (sql/with-query-results rs ["select * from users"] > >> (dorun (map #(println %) rs > > >> === > >> Do I include this statement to get sql and what is the proper way?? > > >> (:require [clojure.contrib.sql :as sql])) > > > You haven't answered the questions about how you are running your > > Clojure code (what's on your classpath etc). > > > Did you try the process I outlined? > > >> - Original Message - From: "Sean Corfield" > >> > >> The monolithic contrib (1.2.0) has been deprecated. Updated versions > >> of many of the modules are available individually: > > >>http://dev.clojure.org/display/design/Where+Did+Clojure.Contrib+Go > > >> However, if you have the JAR on your classpath, that namespace should > >> be available. > > >> It would help people help you if you provided more detail: > >> * How are you running your Clojure code? > >> * What _exact_ error message (and partial stack trace) are you seeing? > > >> Here's an example workflow that shows you can access > >> clojure.contrib.sql just fine: > > >> sean@sean-netbook:~/clojure$ lein new jay > >> cd Created new project in: /home/sean/clojure/jay > >> Look over project.clj and start coding in jay/core.clj > >> sean@sean-netbook:~/clojure$ cd jay/ > >> sean@sean-netbook:~/clojure/jay$ vi project.clj > >> sean@sean-netbook:~/clojure/jay$ cat project.clj > >> (defproject jay "1.0.0-SNAPSHOT" > >> :description "FIXME: write description" > >> :dependencies [[org.clojure/clojure "1.2.1"] > >> [org.clojure/clojure-contrib "1.2.0"]]) > >> sean@sean-netbook:~/clojure/jay$ lein deps > >> Copying 2 files to /home/sean/clojure/jay/lib > >> sean@sean-netbook:~/clojure/jay$ lein repl > >> REPL started; server listening on localhost port 13024 > >> user=> (ns jay.test (:require [clojure.contrib.sql :as sql])) > >> nil > >> jay.test=> ^D > > >> Sean -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Bug in extend-protocol macro? (Clojure 1.3.0)
Hi Alan, Thanks- that explains it: dropping to extend works as expected. -- Peter Taoussanis -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (:require [clojure.contrib.sql :as sql]))
Sorry, I have no idea what you mean... On Tue, Dec 27, 2011 at 9:56 PM, jayvandal wrote: > I have tried the example you provided and it works except I don't see > any file printout of the records when I run not as test but without > test. Is test going to show any data? Can I ask for a record count? > why doesn't the sql jar show for every example that is in the > internet? -- 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
