Re: Eager map?

[mb]

Hi,

On 18 Nov., 03:01, Adam Jones <[EMAIL PROTECTED]> wrote:
> I'm in the middle of writing some code to extract sql results, which
> means I'm doing a *lot* of forcing right now. It's almost enough for
> me to wish there was a convention (and provided definitions) for
> denoting lazy/strict versions of functions. (e.g. (map f ...) is a
> lazy seq, (map! f ...) is strict)

For what it's worth: I use the following convention.

- For code which is purely done for side-effects, I use doseq. eg.
(doseq [x some-seq] (println x))

- In case I want to have the seq in memory, or there are side-effects
  and I need the actual results, I use doall.
(doall (map some-f some-seq))

On the other hand: you can simply create your own map!.
  (def map! (comp doall map))

Just my 0.02€.

Sincerely
Meikel


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: offtopic - where are you come from? (poll)

[Rastislav Kassak]

You forgot about Kia / Hyundai and Daewoo (now Chevrolet). :)

On 11/16/08, Chanwoo Yoo <[EMAIL PROTECTED]> wrote:
>
>  Seoul, South Korea, which LG and Samsung are belongs to (I know there
>  is few who knows where South Korea is. ^_^; It is placed between China
>  and Japan.)
>
>
>  On 10월22일, 오후10시07분, perdalum <[EMAIL PROTECTED]> wrote:
>  > Aarhus, Denmark
>  >
>  > On 17 Okt., 11:27, "Rastislav Kassak" <[EMAIL PROTECTED]> wrote:
>  >
>  > > Hello Clojurians,
>  >
>  > > I think after 1st year of Clojure life it's good to check how far has
>  > > Clojure spread all over the world.
>  >
>  > > So wherever are you come from, be proud and say it.
>  >
>  > > I'm from Slovakia. :)
>  >
>  > > RK
>  >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: offtopic - where are you come from? (poll)

[Geoffrey Teale]

I'm from the UK, but I live in Munich,  Germany.

2008/11/17 [EMAIL PROTECTED] <[EMAIL PROTECTED]>

>
> +1 for Baltimore.
>
> On Oct 17, 8:12 am, Paul Barry <[EMAIL PROTECTED]> wrote:
> > Baltimore, Maryland, US
> >
> > On Oct 17, 5:27 am, "Rastislav Kassak" <[EMAIL PROTECTED]> wrote:
> >
> > > Hello Clojurians,
> >
> > > I think after 1st year of Clojure life it's good to check how far has
> > > Clojure spread all over the world.
> >
> > > So wherever are you come from, be proud and say it.
> >
> > > I'm from Slovakia. :)
> >
> > > RK
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Working combination of .emacs, Aquamacs, swank-clojure, clojure-mode?

[Cosmin Stejerean]

On Tue, Nov 18, 2008 at 12:17 AM, Raffael Cavallaro <
[EMAIL PROTECTED]> wrote:

>
>
>
> On Nov 17, 11:55 pm, "Cosmin Stejerean" <[EMAIL PROTECTED]> wrote:
>
> > Most of these projects change on a daily basis and so far I've never run
> > into any issues using the latest version of each. During initial
> > installation the chances of issues being due to user error are far
> greater
> > than problems due to incompatible versions, and since getting in the
> habit
> > of using the latest version (and updating regularly) is a good thing, I
> > would recommend using the latest version to any newcomer and posting
> > questions here including detailed explanation of what was tried and what
> > happened.
>
>
> Allow me to repeat that I was using the latest git cloned and cvs co'd
> versions of all these components , a *completely blank* .emacs, and a
> freshly installed Aquamacs. IOW, a pristine, completely up to date
> install. Just because it worked on the day you did your setup most
> definitely does *not* mean this is a reliable procedure.
>

If you had provided the specific versions you checked out and your resulting
.emacs file we could have a conversation about whether or not the problem
was due to versions constantly changing or some misconfiguration on your
part.

Building from latest head is not 100% reliable, but I'm not yet convinced
it's worth optimizing for the rare chance that there is an incompatibility.
Even if you were to provide a link to some known good version of each
project, how do you define "good"? What kind of bugs are acceptable for the
purpose of a known good combination? Is slime starting up sufficient?

Assuming some automated tests can be created to define the characteristics
of a known good combination I'll volunteer to create a continuous
integration server to report the status of trying to use the latest version
of each project so interested users can quickly see if the most recent
combination works, and if not look, at the history to find the most recent
one that does. Is providing automated tests something you'd like to help
with?

-- 
Cosmin Stejerean
http://www.offbytwo.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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Working combination of .emacs, Aquamacs, swank-clojure, clojure-mode?

[Raffael Cavallaro]

On Nov 17, 11:55 pm, "Cosmin Stejerean" <[EMAIL PROTECTED]> wrote:

> Most of these projects change on a daily basis and so far I've never run
> into any issues using the latest version of each. During initial
> installation the chances of issues being due to user error are far greater
> than problems due to incompatible versions, and since getting in the habit
> of using the latest version (and updating regularly) is a good thing, I
> would recommend using the latest version to any newcomer and posting
> questions here including detailed explanation of what was tried and what
> happened.


Allow me to repeat that I was using the latest git cloned and cvs co'd
versions of all these components , a *completely blank* .emacs, and a
freshly installed Aquamacs. IOW, a pristine, completely up to date
install. Just because it worked on the day you did your setup most
definitely does *not* mean this is a reliable procedure.

Project dependencies which "change on a daily basis" are a bug, not a
feature. For any given project, in this case clojure, there is no
virtue whatsoever to the fact that some other project such as slime
changes daily. Just pick a recent working version and say "we know
that all recent svn updates of clojure work with this version of slime/
swank-clojure/clojure-mode."

>Are you volunteering to maintain a relatively up to date cache of known good
> versions of these projects?

Remember the context: "Getting Started." The context is NOT bleeding
edge developers who want the very latest build of everything. If you
want the very latest slime, etc., you should be on your own.

regards,

Ralph




Raffael Cavallaro, Ph.D.
[EMAIL PROTECTED]


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Patch: standalone compiler (almost)

[Stephen C. Gilardi]

On Nov 17, 2008, at 11:42 PM, Stephen C. Gilardi wrote:

> It seems there's something not quite right, though. I did a fresh  
> checkout of 1108 and built with "ant" and ran with "java -jar  
> clojure.jar" and got an exception:

Making pushNS public on line 4461 of src/jvm/clojure/lang/ 
Compiler.java fixes the exception.

--Steve


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[cwyang]

What a great name 'conj' is, for project hosting site name!
(no shame for self-complement :-) )

user=> (def repository '(proj-foo proj-bar))
#=(var user/repository)
user=> (conj repository 'proj-yours)
(proj-yours proj-foo proj-bar)

However, conj.net is already occupied. ;-(
conj.us is avaliable, meaning (conjoin to us)

user=> (def us '(foo bar))
#=(var user/us)
user=> (conj us 'new-proj)
(new-proj foo bar)


On 11월18일, 오후2시29분, cwyang <[EMAIL PROTECTED]> wrote:
> How about 'conj'?
>
> conj is (1) for 'conj' in Clojure, and (2) for abbrev of 'conjure',
> meaning (Conjuring Clojure).
>
> 'cons' for lisp, and 'conj' for clojure. :-)
> --
> Chul-Woong Yang
>
> On Nov 18, 4:52 am, Drew Crampsie <[EMAIL PROTECTED]> wrote:
>
> > Hey All,
>
> > I've finally found some time to start getting the project hosting site
> > together, and i need a name.. so lets put it to a vote.
>
> > Here are some suggestions so far, but please feel free to chime in
> > with your own as well.
>
> >  - projecture
> >  - clojr
> >  - proj4cloj
> >  - clojforge, cloforj,
> >  - forj
> > - clojects
> > - clojury
> > - openjure
>
> > Thanks for the help Clojurians!
>
> > Cheers,
>
> > drewc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[cwyang]

How about 'conj'?

conj is (1) for 'conj' in Clojure, and (2) for abbrev of 'conjure',
meaning (Conjuring Clojure).

'cons' for lisp, and 'conj' for clojure. :-)
--
Chul-Woong Yang


On Nov 18, 4:52 am, Drew Crampsie <[EMAIL PROTECTED]> wrote:
> Hey All,
>
> I've finally found some time to start getting the project hosting site
> together, and i need a name.. so lets put it to a vote.
>
> Here are some suggestions so far, but please feel free to chime in
> with your own as well.
>
>  - projecture
>  - clojr
>  - proj4cloj
>  - clojforge, cloforj,
>  - forj
> - clojects
> - clojury
> - openjure
>
> Thanks for the help Clojurians!
>
> Cheers,
>
> drewc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Working combination of .emacs, Aquamacs, swank-clojure, clojure-mode?

[Cosmin Stejerean]

On Mon, Nov 17, 2008 at 9:25 PM, Raffael Cavallaro <
[EMAIL PROTECTED]> wrote:

>
>
>
> On Nov 17, 8:43 pm, "Bill Clementson" <[EMAIL PROTECTED]> wrote:
> >
> > Rather than ask someone to assemble a package and post it for you, it
> > is usually nicer (and a better learning experience) if you list
> > exactly what you did, and post the minimal config scripts that you the
> > tried out and which illustrate what didn't work for you.
>
> I think you miss the point here. I'm suggesting that all new users
> would be much better served if clojure.org site cached a combination
> of the necessary elements of a working slime install, not that someone
> post something for me alone.
>

Are you volunteering to maintain a relatively up to date cache of known good
versions of these projects?

Most of these projects change on a daily basis and so far I've never run
into any issues using the latest version of each. During initial
installation the chances of issues being due to user error are far greater
than problems due to incompatible versions, and since getting in the habit
of using the latest version (and updating regularly) is a good thing, I
would recommend using the latest version to any newcomer and posting
questions here including detailed explanation of what was tried and what
happened.

-- 
Cosmin Stejerean
http://www.offbytwo.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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Patch: standalone compiler (almost)

[Stephen C. Gilardi]

On Nov 17, 2008, at 10:33 PM, Rich Hickey wrote:

> Fixed (SVN 1108) - thanks for the report.

Cool, thanks. I especially like "loadClassForName".

It seems there's something not quite right, though. I did a fresh  
checkout of 1108 and built with "ant" and ran with "java -jar  
clojure.jar" and got an exception:

% java -jar clojure.jar
Exception in thread "main" java.lang.IllegalAccessError: tried to  
access method clojure.lang.Compiler.pushNS()V from class clojure.core
at clojure.core.(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at clojure.lang.RT.loadClassForName(RT.java:1620)
at clojure.lang.RT.load(RT.java:442)
at clojure.lang.RT.load(RT.java:424)
at clojure.lang.RT.doInit(RT.java:461)
at clojure.lang.RT.(RT.java:328)
at clojure.lang.Repl.(Repl.java:23)
Could not find the main class: clojure.lang.Repl. Program will exit.

--Steve


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Patch: standalone compiler (almost)

[Rich Hickey]

On Nov 17, 8:50 am, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote:
> On Nov 16, 2008, at 10:34 PM, Rich Hickey wrote:
>
> > Since it only requires main, might I suggest you write this in
> > Clojure instead?
>
> I gave that a try.
>
> Here's a simple version of a driver for the compiler, stored in src/
> clj/clojure/compile.clj:
>
> (ns clojure.compile)
>
> (defn main
>   "Compiles libs into class files stored at compile-path.
>   All args are strings"
>   [compile-path & libs]
>   (printf "Compiling %d libs to %s\n" (count libs) compile-path)
>   (flush)
>   (binding [*compile-path* compile-path]
> (doseq [lib libs]
> (compile (symbol lib)
>
> It works when run from within the Clojure repl:
>
> % ls build/classes/clojure/hello*
> ls: build/classes/clojure/*hello*: No such file or directory
> % java -cp clojure.jar:src/clj/ clojure.lang.Repl
> Clojure
> user=> (require 'clojure.compile)
> nil
> user=> (clojure.compile/main "build/classes" "clojure.hello")
> Compiling 1 libs to build/classes
> nil
> user=>
> % ls build/classes/clojure/hello*
> build/classes/clojure/hello$main__8.class   build/classes/clojure/
> hello.class
>
> but when run as a standalone main, it gives an exception that appears
> to be related to static initializers:
>
> % java -cp clojure.jar:src/clj/ clojure.compile build/classes
> clojure.hello
> Compiling 1 libs to build/classes
> Exception in thread "main" java.lang.IllegalStateException: Var null/
> null is unbound. (hello.clj:3)
> at clojure.lang.Compiler.analyzeSeq(Compiler.java:4067)
> at clojure.lang.Compiler.analyze(Compiler.java:3896)
> at clojure.lang.Compiler.analyzeSeq(Compiler.java:4050)
> at clojure.lang.Compiler.analyze(Compiler.java:3896)
> at clojure.lang.Compiler.access$100(Compiler.java:38)
> at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:365)
> at clojure.lang.Compiler.analyzeSeq(Compiler.java:4060)
> at clojure.lang.Compiler.analyze(Compiler.java:3896)
> at clojure.lang.Compiler.analyzeSeq(Compiler.java:4050)
> at clojure.lang.Compiler.analyze(Compiler.java:3896)
> at clojure.lang.Compiler.analyze(Compiler.java:3869)
> at clojure.lang.Compiler.compile(Compiler.java:4498)
> at clojure.lang.RT.compile(RT.java:408)
> at clojure.lang.RT.load(RT.java:450)
> at clojure.lang.RT.load(RT.java:422)
> at clojure.core$load__4423$fn__4425.invoke(core.clj:3343)
> at clojure.core$load__4423.doInvoke(core.clj:3342)
> at clojure.lang.RestFn.invoke(RestFn.java:413)
> at clojure.core$load_one__4386.invoke(core.clj:3189)
> at clojure.core$compile__4429.invoke(core.clj:3347)
> at clojure.compile$main__5162.doInvoke(compile.clj:23)
> at clojure.lang.RestFn.invoke(RestFn.java:428)
> at clojure.lang.Var.invoke(Var.java:323)
> at clojure.lang.AFn.applyToHelper(AFn.java:195)
> at clojure.lang.Var.applyTo(Var.java:436)
> at clojure.compile.main(Unknown Source)
> Caused by: java.lang.IllegalStateException: Var null/null is unbound.
> at clojure.lang.Var.get(Var.java:129)
> at clojure.lang.Compiler$FnExpr.parse(Compiler.java:2947)
> at clojure.lang.Compiler.analyzeSeq(Compiler.java:4058)
> ... 25 more
> %
>
> For reference, here is the test compilee: src/clj/clojure/hello.clj:
>
> (ns clojure.hello)
>
> (defn main
>   [greetee]
>   (printf "Hello, %s wow\n" greetee)
>   (flush))
>
> I'd appreciate help in getting a standalone invocation of something
> like compile.clj above (i.e., using it's own main without Repl or
> Script) to work.
>
> In working through this, I also found that a compiler driver written
> in Java may be preferable for use via build.xml because of a bootstrap
> problem. Until we compile (something like) "compile.clj", we can't
> call it as a standalone main. (One could add a step that builds the
> compiler driver via a clojure.lang.Script invocation.)
>


Fixed (SVN 1108) - thanks for the report.

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Working combination of .emacs, Aquamacs, swank-clojure, clojure-mode?

[Raffael Cavallaro]

On Nov 17, 8:43 pm, "Bill Clementson" <[EMAIL PROTECTED]> wrote:
>
> Rather than ask someone to assemble a package and post it for you, it
> is usually nicer (and a better learning experience) if you list
> exactly what you did, and post the minimal config scripts that you the
> tried out and which illustrate what didn't work for you.

I think you miss the point here. I'm suggesting that all new users
would be much better served if clojure.org site cached a combination
of the necessary elements of a working slime install, not that someone
post something for me alone.

The alternative is that new users end up chasing their tails because
several of the necessary elements are moving targets. The concept of
an actual stable release seems to be missing in the slime world as
well, and I'm not the only experienced lisp user to have voiced
misgivings about this state of affairs:



Stumbling over regressions among multiple continually moving targets
is not a "learning experience," it is merely an excercise in
frustration. This is why projects have releases. Then other projects
can build against those releases, and combinations of multiple
interdependent projects can have known working versions.

Where such releases are not available the next best thing is to grab a
known working combination and cache it. Pointing at the continually
shifting sands of multiple repositories is a really good way to ensure
that only the most persistent and experienced will stick around very
long. One could cynically suggest that this is desirable, but I
actually believe that the clojure community does not want to drive
away newcomers (after all, look at the volume of excellent
documentation). Simply caching a set of known working components would
completely eliminate this issue.

> However,
> since I recently upgraded to the latest Clojure, I'll share what
> worked for me:
>
> 0. Delete (or move away) any old versions of the following (e.g. don't
> assume that something you downloaded a couple of days ago is ok to
> use)
> 1. Download latest Clojure from 
> svn:http://sourceforge.net/svn/?group_id=137961
> 2. Download latest clojure-mode & swank-clojure from 
> git:http://github.com/jochu/
> 3. Download latest slime from cvs:http://common-lisp.net/project/slime/
> 4. Download latest clojure-contrib from 
> svn:http://sourceforge.net/svn/?group_id=223136
> 5. Use ant to build clojure and clojure-contrib
> 6. Create a shell script (called "clojure") to launch clojure and put
> it in your PATH :
>
> #!/bin/sh -e
> java -server -cp /Users/bc/lisp/clojure/clojure/trunk/clojure.jar:\
> /Users/bc/lisp/clojure/clojure-contrib/trunk/clojure-contrib.jar:\
>      clojure.lang.Repl
>
> 7.  Put the following minimal setup in your .emacs file (adjusting the
> paths as necessary):
>
> (setq load-path (append (list "/Users/bc/lisp/clbuild/source/slime"
>                               "/Users/bc/lisp/clbuild/source/slime/contrib"
>                               "/Users/bc/lisp/clojure/clojure-mode"
>                               "/Users/bc/lisp/clojure/swank-clojure")
>                         load-path))
>
> (setq swank-clojure-binary "clojure")
>
> (require 'clojure-auto)
> (require 'swank-clojure-autoload)
>
> (defun run-clojure ()
>   "Starts clojure in Slime"
>   (interactive)
>   (slime 'clojure))
>
> (global-set-key [f5] 'run-clojure)
> (global-set-key [(control f11)] 'slime-selector)
>
> (add-hook 'slime-connected-hook 'slime-redirect-inferior-output)
>
> 8. Restart Aquamacs and press F5 - you should get a repl
>
> The above worked for me when I re-installed Clojure (with the latest
> AOT changes) a couple of days ago.

This works for me as well, thanks for the detailed instructions.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: multi-method dispatch for structs

[[EMAIL PROTECTED]]

On Nov 14, 3:42 pm, Chouser <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 14, 2008 at 2:11 PM, Jeff Rose <[EMAIL PROTECTED]> wrote:
> > Does my dispatch function have to inspect the passed in values to
> > figure out whichtypeof struct they are, or can I query that
> > somehow?
>
> My understanding is that StructMaps are just Maps with an
> implementation that's optimized to reduce memory usage.  The different
> basis types don't really function as "classes" of StractMaps or
> anything.  You can still add new keys to StructMaps, for example, just
> like any other Map.  So if you want some kind of 'type'datado
> dispatch off of, you'll have to attach that yourself, either as
> another key that all your Maps share or as metadata.
>
I've actually got the same use case as Jeff Rose -- I want some
generic methods on algebraic data types. Is there any reason to prefer
a data field over a metadata field, or vice versa, for the type tag?

-- Steve

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Eager map?

[Chouser]

On Mon, Nov 17, 2008 at 9:01 PM, Adam Jones <[EMAIL PROTECTED]> wrote:
>
> I'm in the middle of writing some code to extract sql results, which
> means I'm doing a *lot* of forcing right now. It's almost enough for
> me to wish there was a convention (and provided definitions) for
> denoting lazy/strict versions of functions. (e.g. (map f ...) is a
> lazy seq, (map! f ...) is strict)

(vec x) will force a lazy seq x and store it in a vector.  (apply list
x) will force and store in a list.

--Chouser

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Giancarlo Angulo]

+1 for projecture
=
ANGOL
=
-|[EMAIL PROTECTED], =|+^_^X++~_~,@-

"The only thing worse than a hopeless romantic is a hopeful one"

Magbasa bago Mamuna. Mag-isip bago mambatikos

Without Truth there is no Justice,
Without Justice, there is Tyranny

Semper fi

Proof of Desire is Pursuit

www.onthe8spot.com
[EMAIL PROTECTED]
09173822367


On Tue, Nov 18, 2008 at 4:12 AM, Stephen C. Gilardi <[EMAIL PROTECTED]>wrote:

>
> On Nov 17, 2008, at 3:08 PM, J. McConnell wrote:
>
> I'm liking projecture
>
>
> And its evil twin anti-site...
>
> conjecture
>
> --Steve
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Eager map?

[Adam Jones]

On Nov 17, 4:25 pm, Bradbev <[EMAIL PROTECTED]> wrote:
> On Nov 17, 3:50 pm, Adam Jones <[EMAIL PROTECTED]> wrote:
>
> > On Nov 17, 3:26 pm, Robert Ewald <[EMAIL PROTECTED]> wrote:
>
> > > Hello,
>
> > > Doing some small experiments I stumbled over map returning a lazy seq 
> > > instead
> > > of performing the function. I had to convert that to a doseq. Is there any
> > > rationale for not having an eager map. Or was I just not reading the docs
> > > properly?
>
> > Many of Clojure's functions that operate on seqs have this property.
> > The idea is to capture the space efficiency of lazy list processing by
> > default. If you really need strict evaluation, wrap the map with
> > doall. I'm guessing that strict equivalents aren't provided to
> > encourage the use of the lazy functions unless they absolutely aren't
> > needed.
>
> What is the preferred idiom for converting from a Lazy seq to a proper
> seq?
> I've been using (into [] (map .)).
> doall and dorun don't really appeal to me in this usage, because to me
> they say "This code is lazy and I'm executing it for side effects, not
> results".  (into []...) says to me "This code is lazy, and I really
> want a concrete vector here.
>
> Thoughts?

This is true for dorun, but not exactly for doall. (For instance,
there's no difference in the result between (into '() ...) and
(doall ...)) I'm not really confident enough to speculate on the
relative efficiency of either. As far as I have seen, there is no
preferred idiom for forcing the thunks in a seq.

I'm in the middle of writing some code to extract sql results, which
means I'm doing a *lot* of forcing right now. It's almost enough for
me to wish there was a convention (and provided definitions) for
denoting lazy/strict versions of functions. (e.g. (map f ...) is a
lazy seq, (map! f ...) is strict)

-Adam

>
> Cheers,
> Brad
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Daily Build

[Adam Jones]

On Nov 17, 5:22 pm, Robert <[EMAIL PROTECTED]> wrote:
> Is there a server that tests every day if Clojure builds correctly? I
> pulled the latest a few days ago and couldn't get it to build (whereas
> the 2008-09-16 "release" does build for me). Having such a server
> would
> assist in determining if such problems are the user's fault (likely,
> in my case) or not (unlikely).

So far as I've heard, no such server exists. Can you provide any more
information about your problem?

I'm not sure how the AOT compilation is progressing, but that has
disrupted the (usually rock solid) stability of the trunk a bit. You
may want to see how revision 1088 (svn co -r 1088
http://clojure.svn.sourceforge.net/svnroot/clojure/trunk) builds for
you. It's the last revision before the AOT compilation project
started.

-Adam

>
> Robert
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Working combination of .emacs, Aquamacs, swank-clojure, clojure-mode?

[Bill Clementson]

Hi Raffael,

On Mon, Nov 17, 2008 at 4:21 PM, Raffael Cavallaro
<[EMAIL PROTECTED]> wrote:
> As the mention of Aquamacs in the title suggests, I'm on Mac OS X.
> I've read Bill Clementson's Blog on setting up clojure, and I'm not
> exactly a neophyte - I've been using slime with sbcl, openmcl, and
> other lisps for years.
>
> Nevertheless, even starting with an absolutely blank .emacs and
> freshly downloaded copies of Aquamacs, clojure, swank-clojure, and
> clojure-mode, the instructions in Bill's blog do not yield a working
> clojure under slime.

Unfortunately (or, fortunately, depending on your perspective),
Clojure is a moving target and an emacs/slime configuration that
worked one month ago will not necessarily work today.

> I've managed to get M-x run-lisp to work with the more basic of the
> two clojure modes out there, so Bill's shell script in and of itself
> is not the problem at all (it also works fine from a terminal window).
> However, I've never gotten slime to work, so somehow it doesn't play
> nice with swank-clojure and/or clojure-mode and/or slime.
>
> Is there anyone who would be willing to post an *actual* .emacs (not
> "add this line...,"  .emacs files involve clobbering globals, so order
> really does matter), and links to the *actual* versions of clojure,
> slime, swank-clojure, and clojure-mode that together, produce a
> functioning clojure under slime/Aquamacs?
>
> As a side note, I might suggest that links to a combination of ever-
> changing git repositories might not be the very best idea on a page
> entitled "Getting Started." IOW, it might be a good idea to take a
> known working combination of the above, zip them up and link to that
> instead.

Rather than ask someone to assemble a package and post it for you, it
is usually nicer (and a better learning experience) if you list
exactly what you did, and post the minimal config scripts that you
tried out and which illustrate what didn't work for you. However,
since I recently upgraded to the latest Clojure, I'll share what
worked for me:

0. Delete (or move away) any old versions of the following (e.g. don't
assume that something you downloaded a couple of days ago is ok to
use)
1. Download latest Clojure from svn: http://sourceforge.net/svn/?group_id=137961
2. Download latest clojure-mode & swank-clojure from git:
http://github.com/jochu/
3. Download latest slime from cvs: http://common-lisp.net/project/slime/
4. Download latest clojure-contrib from svn:
http://sourceforge.net/svn/?group_id=223136
5. Use ant to build clojure and clojure-contrib
6. Create a shell script (called "clojure") to launch clojure and put
it in your PATH :

#!/bin/sh -e
java -server -cp /Users/bc/lisp/clojure/clojure/trunk/clojure.jar:\
/Users/bc/lisp/clojure/clojure-contrib/trunk/clojure-contrib.jar:\
 clojure.lang.Repl

7.  Put the following minimal setup in your .emacs file (adjusting the
paths as necessary):

(setq load-path (append (list "/Users/bc/lisp/clbuild/source/slime"
  "/Users/bc/lisp/clbuild/source/slime/contrib"
  "/Users/bc/lisp/clojure/clojure-mode"
  "/Users/bc/lisp/clojure/swank-clojure")
load-path))

(setq swank-clojure-binary "clojure")

(require 'clojure-auto)
(require 'swank-clojure-autoload)

(defun run-clojure ()
  "Starts clojure in Slime"
  (interactive)
  (slime 'clojure))

(global-set-key [f5] 'run-clojure)
(global-set-key [(control f11)] 'slime-selector)

(add-hook 'slime-connected-hook 'slime-redirect-inferior-output)

8. Restart Aquamacs and press F5 - you should get a repl

The above worked for me when I re-installed Clojure (with the latest
AOT changes) a couple of days ago. If you have any problems with the
above, post a reply with any errors you encountered as well as any
differences in your setup.

--
Bill Clementson

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Daily Build

[Robert]

Is there a server that tests every day if Clojure builds correctly? I
pulled the latest a few days ago and couldn't get it to build (whereas
the 2008-09-16 "release" does build for me). Having such a server
would
assist in determining if such problems are the user's fault (likely,
in my case) or not (unlikely).

Robert
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Working combination of .emacs, Aquamacs, swank-clojure, clojure-mode?

[Raffael Cavallaro]

As the mention of Aquamacs in the title suggests, I'm on Mac OS X.
I've read Bill Clementson's Blog on setting up clojure, and I'm not
exactly a neophyte - I've been using slime with sbcl, openmcl, and
other lisps for years.

Nevertheless, even starting with an absolutely blank .emacs and
freshly downloaded copies of Aquamacs, clojure, swank-clojure, and
clojure-mode, the instructions in Bill's blog do not yield a working
clojure under slime.

I've managed to get M-x run-lisp to work with the more basic of the
two clojure modes out there, so Bill's shell script in and of itself
is not the problem at all (it also works fine from a terminal window).
However, I've never gotten slime to work, so somehow it doesn't play
nice with swank-clojure and/or clojure-mode and/or slime.

Is there anyone who would be willing to post an *actual* .emacs (not
"add this line...,"  .emacs files involve clobbering globals, so order
really does matter), and links to the *actual* versions of clojure,
slime, swank-clojure, and clojure-mode that together, produce a
functioning clojure under slime/Aquamacs?

As a side note, I might suggest that links to a combination of ever-
changing git repositories might not be the very best idea on a page
entitled "Getting Started." IOW, it might be a good idea to take a
known working combination of the above, zip them up and link to that
instead.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Eager map?

[Bradbev]

On Nov 17, 3:50 pm, Adam Jones <[EMAIL PROTECTED]> wrote:
> On Nov 17, 3:26 pm, Robert Ewald <[EMAIL PROTECTED]> wrote:
>
> > Hello,
>
> > Doing some small experiments I stumbled over map returning a lazy seq 
> > instead
> > of performing the function. I had to convert that to a doseq. Is there any
> > rationale for not having an eager map. Or was I just not reading the docs
> > properly?
>
> Many of Clojure's functions that operate on seqs have this property.
> The idea is to capture the space efficiency of lazy list processing by
> default. If you really need strict evaluation, wrap the map with
> doall. I'm guessing that strict equivalents aren't provided to
> encourage the use of the lazy functions unless they absolutely aren't
> needed.

What is the preferred idiom for converting from a Lazy seq to a proper
seq?
I've been using (into [] (map .)).
doall and dorun don't really appeal to me in this usage, because to me
they say "This code is lazy and I'm executing it for side effects, not
results".  (into []...) says to me "This code is lazy, and I really
want a concrete vector here.

Thoughts?

Cheers,
Brad

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[John]

+1 Clojury

-oryNoun: place for, serves for

Sounds best to me.

On Nov 17, 5:23 pm, Dave Newton <[EMAIL PROTECTED]> wrote:
> --- On Mon, 11/17/08, Drew Crampsie wrote:
>
> >  - projecture
>
> Nice, because Clojure "sticks out" beyond Java/JVM, besides the other obvious 
> meanings
>
> >  - proj4cloj
>
> Too hard to say.
>
> >  - clojforge, cloforj,
>
> sourceforj?
>
> >  - forj
> > - clojects
>
> Source code coming out of the cloject; me likey.
>
> > - clojury
> > - openjure
>
> - Nondisclojure (Stealth Clojure projects in Java houses)
> - 4LeafClojure (it's good luck, top o' the mornin' to ye)
> - Code4Clojure
> - SeekingClojure
>
> 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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Eager map?

[Allen Rohner]

>. If you really need strict evaluation, wrap the map with
> doall.

Another way to do that would be to use doseq.

Allen

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure.contrib.test-is changes

[Meikel Brandmeyer]

Hi,

Am 18.11.2008 um 00:13 schrieb Frantisek Sodomka:

B) What about 'throws' macro? Could this become a function returning
true/false? Then we could stick it inside 'is' or 'all-true'. (I  
guess it

doesn't matter that much, does it?)


I have a is-like construct, which is build-up slightly different.
Instead of checking, what I get, I immediatelly dispatch to a
multimethod.

(defmacro is [t msg] (is* t msg))

(defmulti is* (fn [t _] (first t)))

(defmethod is* :default `(simply-run-t-here ...))
(defmethod is* nil `(always-fail ...))
(defmethod is* '= `(do-test-here ...))
(defmethod is* 'not= `(do-test-here ...))
(defmethod is* 'instance? `(do-test-here ...))
(defmethod is* 'throwing? `(do-test-here ...))

So it is easy to extend is with other tests, while still being able
to provide diagnostics in case a test should fail.

Furthermore I use a test driver function, which reduces the repition to
a minimum. It takes care to run the tests in a try, report the result
and provide diagnostics in case of a failure. Then each methods above
just has to specify in a callback how the actual test is carried out and
what kind diagnostics should be printed. (eg. compare assert-expr
for = and instance?. They are very similar.)

What do you think about such a structure?

Sincerely
Meikel




smime.p7s
Description: S/MIME cryptographic signature

Re: Eager map?

[Adam Jones]

On Nov 17, 3:26 pm, Robert Ewald <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Doing some small experiments I stumbled over map returning a lazy seq instead
> of performing the function. I had to convert that to a doseq. Is there any
> rationale for not having an eager map. Or was I just not reading the docs
> properly?

Many of Clojure's functions that operate on seqs have this property.
The idea is to capture the space efficiency of lazy list processing by
default. If you really need strict evaluation, wrap the map with
doall. I'm guessing that strict equivalents aren't provided to
encourage the use of the lazy functions unless they absolutely aren't
needed.

-Adam

>
> --
> Robert Ewald
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Eager map?

[Jarkko Oranen]

On Nov 18, 1:26 am, Robert Ewald <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Doing some small experiments I stumbled over map returning a lazy seq instead
> of performing the function. I had to convert that to a doseq. Is there any
> rationale for not having an eager map. Or was I just not reading the docs
> properly?

you can use either doall or dorun depending on whether
you need the results or just want to force side-effects:

For example, compare:
(dorun (map println ["This" "is" "an" "example"]))
(doall (map (memfn toUpperCase) ["This" "is" "an" "example"]))

Hope this helps
--
Jarkko
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Eager map?

[Robert Ewald]

Hello,

Doing some small experiments I stumbled over map returning a lazy seq instead 
of performing the function. I had to convert that to a doseq. Is there any 
rationale for not having an eager map. Or was I just not reading the docs 
properly?

-- 
Robert Ewald

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure.contrib.test-is changes

[Frantisek Sodomka]

Thinking about test-is little more...

Lets look at this test for minus:

(deftest test-minus
   (all-true
 (number? (- 1 2))
 (integer? (- 1 2))
 (float? (- 1.0 2))
 (ratio? (- 2/3 1))
 (float? (- 2/3 (/ 1.0 3
   (throws IllegalArgumentException (-))
   (each=
 (- 1) -1
 (- 1 2) -1
 (- 1 2 3) -4

 (- -2) 2
 (- 1 -2) 3
 (- 1 -2 -3) 6

 (- 1 1) 0
 (- -1 -1) 0

 (- 2/3) -2/3
 (- 2/3 1) -1/3
 (- 2/3 1/3) 1/3

 (- 1.2) -1.2
 (- 2.2 1.1) 1.1
 (- 6.6 2.2 1.1) 3.3)
   ; no underflow :)
   (is (< (- Integer/MIN_VALUE 10) Integer/MIN_VALUE)))

There are currently 4 elements - all-true, throws, each=, is. I am  
scratching my head, trying to figure out, how to merge these together or  
to make it read better...

Ideas:

A) Lets merge 'is' and 'all-true'
Would it be possible to abandon the optional message 'is' macro has? I am  
sure, I will not use it. Then 'is' could accept multiple params and we are  
down to 3! (all-true is out)

B) What about 'throws' macro? Could this become a function returning  
true/false? Then we could stick it inside 'is' or 'all-true'. (I guess it  
doesn't matter that much, does it?)

C) Lets name them more similar, so it reads better: 'is', 'is-each',  
'is-true'.

Just what came to my mind :-)

Greetings, Frantisek

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Newbie: Default map parameters

[Mark McGranaghan]

Mark,

You can read some about destructuring in the documentation for the
special form "let":
http://clojure.org/special_forms#let

You can also explore the functionality at the repl:

user=> (destructure '[{x :x, y :y, :or {y 3}} given])
[map__59 given y (clojure.core/get map__59 :y 3) x (clojure.core/get
map__59 :x)]

There might be a case for more generally located documentation about
destructuring, since it is used in various places besides let, though
of course everyone should read the special forms page before
programming Clojure.

- Mark



On Mon, Nov 17, 2008 at 5:17 PM, samppi <[EMAIL PROTECTED]> wrote:
>
> Ah! Thank you.
>
> On Nov 17, 2:48 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
>> On Nov 17, 4:22 pm, samppi <[EMAIL PROTECTED]> wrote:
>>
>> > Inhttp://groups.google.com/group/clojure/browse_thread/thread/62140a28b...,
>> > the following example was given:
>>
>> > (defn test1 [{x :x, y :y, :or {:y 3}}]
>> > [x y])
>> > (test1 {:x 2}) => [2 3]
>>
>> > But this doesn't work on the latest Clojure from Subversion I just
>> > got:
>>
>> > (test1 {:x 2}) => [2 nil]
>>
>> > Was this a feature that was removed? Or should it work?
>>
>> That's a typo in the original, should be:
>>
>> (defn test1 [{x :x, y :y, :or {y 3}}]
>>   [x y])
>>
>> Rich
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Newbie: Default map parameters

[Rich Hickey]

On Nov 17, 5:16 pm, "Mark Volkmann" <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 17, 2008 at 3:48 PM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> > On Nov 17, 4:22 pm, samppi <[EMAIL PROTECTED]> wrote:
> >> Inhttp://groups.google.com/group/clojure/browse_thread/thread/62140a28b...,
> >> the following example was given:
>
> >> (defn test1 [{x :x, y :y, :or {:y 3}}]
> >> [x y])
> >> (test1 {:x 2}) => [2 3]
>
> >> But this doesn't work on the latest Clojure from Subversion I just
> >> got:
>
> >> (test1 {:x 2}) => [2 nil]
>
> >> Was this a feature that was removed? Or should it work?
>
> > That's a typo in the original, should be:
>
> > (defn test1 [{x :x, y :y, :or {y 3}}]
> >  [x y])
>
> Can someone explain what this does?

Yes!

> It looks to me like the function named test1 returns a vector
> containing the values of x and y.

Right.

> Are you suppose to pass a map to the function?

Yes.

> Does it take the value for the key :x and put it in the parameter x,
> and similarly for y?

Yes.

> Is the value 3 used for y if the key :y isn't present in the map?
>

Right again.

> I'm still at the point where reading some Clojure code is like trying
> understand a complicated regular expression.
>

You seem to be doing fine!

This is an example of Clojure's destructuring binding. The basic idea
is that you are in a context in which you'd normally be using a
symbol, intended to be bound to something, e.g. a fn arglist or let
binding. But instead of using a symbol, you instead use a data
structure. In it, there are symbols. Those symbols will be bound to
corresponding parts of a composite data structure. There is general
destructuring for sequences and associative things, like maps.

Destructuring is described here:

http://clojure.org/special_forms#let

While it may look like a regular expression to you right now, it
actually still is code-as-data. The vector and map binding forms are
actual vectors and maps, there are just some rules for interpretation
of things like :or, :keys, :as etc., all described above.

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure.contrib.test-is changes

[Frantisek Sodomka]

Hello Stuart!

Few more ideas for you :)

each= could be extended to allow more freedom. The first parameter could  
say what operation we want to perform:

each =
each not=
each <
each >
...

(each =
   a b
   c d)
=>
(all-true
   (= a b)
   (= c d))


(each not=
   a b
   c d)
=>
(all-true
   (not= a b)
   (not= c d))

Since 'each' might be too general (could it be part of Clojure core?), I  
also like the name is-each which fits nicely  with 'is'.

is-each =
is-each not=
...

It might be a good idea to check if count of forms passed to each/is-each  
is even:
(if (odd? (count forms)) (throw ... "even number of forms needed!"))

Many thanks, Frantisek

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Dave Newton]

--- On Mon, 11/17/08, Drew Crampsie wrote:
>  - projecture

Nice, because Clojure "sticks out" beyond Java/JVM, besides the other obvious 
meanings

>  - proj4cloj

Too hard to say.

>  - clojforge, cloforj,

sourceforj?

>  - forj
> - clojects

Source code coming out of the cloject; me likey.

> - clojury
> - openjure

- Nondisclojure (Stealth Clojure projects in Java houses)
- 4LeafClojure (it's good luck, top o' the mornin' to ye)
- Code4Clojure
- SeekingClojure

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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Newbie: Default map parameters

[samppi]

Ah! Thank you.

On Nov 17, 2:48 pm, Rich Hickey <[EMAIL PROTECTED]> wrote:
> On Nov 17, 4:22 pm, samppi <[EMAIL PROTECTED]> wrote:
>
> > Inhttp://groups.google.com/group/clojure/browse_thread/thread/62140a28b...,
> > the following example was given:
>
> > (defn test1 [{x :x, y :y, :or {:y 3}}]
> >         [x y])
> > (test1 {:x 2}) => [2 3]
>
> > But this doesn't work on the latest Clojure from Subversion I just
> > got:
>
> > (test1 {:x 2}) => [2 nil]
>
> > Was this a feature that was removed? Or should it work?
>
> That's a typo in the original, should be:
>
> (defn test1 [{x :x, y :y, :or {y 3}}]
>   [x y])
>
> Rich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Newbie: Default map parameters

[Mark Volkmann]

On Mon, Nov 17, 2008 at 3:48 PM, Rich Hickey <[EMAIL PROTECTED]> wrote:
>
> On Nov 17, 4:22 pm, samppi <[EMAIL PROTECTED]> wrote:
>> Inhttp://groups.google.com/group/clojure/browse_thread/thread/62140a28b...,
>> the following example was given:
>>
>> (defn test1 [{x :x, y :y, :or {:y 3}}]
>> [x y])
>> (test1 {:x 2}) => [2 3]
>>
>> But this doesn't work on the latest Clojure from Subversion I just
>> got:
>>
>> (test1 {:x 2}) => [2 nil]
>>
>> Was this a feature that was removed? Or should it work?
>
> That's a typo in the original, should be:
>
> (defn test1 [{x :x, y :y, :or {y 3}}]
>  [x y])

Can someone explain what this does?
It looks to me like the function named test1 returns a vector
containing the values of x and y.
Are you suppose to pass a map to the function?
Does it take the value for the key :x and put it in the parameter x,
and similarly for y?
Is the value 3 used for y if the key :y isn't present in the map?

I'm still at the point where reading some Clojure code is like trying
understand a complicated regular expression.

-- 
R. Mark Volkmann
Object Computing, Inc.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Newbie: Default map parameters

[Rich Hickey]

On Nov 17, 4:22 pm, samppi <[EMAIL PROTECTED]> wrote:
> Inhttp://groups.google.com/group/clojure/browse_thread/thread/62140a28b...,
> the following example was given:
>
> (defn test1 [{x :x, y :y, :or {:y 3}}]
> [x y])
> (test1 {:x 2}) => [2 3]
>
> But this doesn't work on the latest Clojure from Subversion I just
> got:
>
> (test1 {:x 2}) => [2 nil]
>
> Was this a feature that was removed? Or should it work?

That's a typo in the original, should be:

(defn test1 [{x :x, y :y, :or {y 3}}]
  [x y])

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Paul Stadig]

I'm in favor of something with clojure in it (like clojureforge).
Something simple to spell and pronounce. I'm also in favor of not
forcing code hosting, but providing it as an option.


Paul

On Mon, Nov 17, 2008 at 4:18 PM, Drew Crampsie <[EMAIL PROTECTED]> wrote:
>
>
> 2008/11/17 Matt Revelle <[EMAIL PROTECTED]>:
>>
>> Is the project site going to be more similar to the Python package
>> index and CLiki or Sourceforge?
>
> The closest analog is common-lisp.net.. which is like sourceforge.
> However, I like the idea of an index as well, and building the backend
> seems like a fun project, so don't rule this out as well.
>
> Cliki is really just a wiki, and i host it as well, so adding another
> Cliki instance for clojure projects is possible as well, if there is
> demand.
>
>>
>> I still think keeping the site focused on providing an index of
>> projects and storing project metadata is best.  Let projects use their
>> code hosting solution of choice.
>
> No particular code hosting solution will be enforced, but having seen
> and used projects that moved project hosting sites to keep up with
> trends in VCS, and having seen projects go from cvs->svn->darcs->git
> without moving (on common-lisp.net), i can see some value to having
> source hosting available on projecture as well.
>
> Thanks for the input. Given the popularity of github, google code etc,
> i don't plan to focus on the VCS aspect, but nor do i plan to ignore
> it. It really comes  down to demand :).
>
> Cheers,
>
> drewc
>>
>> -Matt
>>
>>>
>>>
>>
>>> On Mon, Nov 17, 2008 at 2:52 PM, Drew Crampsie <[EMAIL PROTECTED]
>>> > wrote:

 Hey All,

 I've finally found some time to start getting the project hosting
 site
 together, and i need a name.. so lets put it to a vote.

 Here are some suggestions so far, but please feel free to chime in
 with your own as well.

 - projecture
 - clojr
 - proj4cloj
 - clojforge, cloforj,
 - forj
 - clojects
 - clojury
 - openjure

 Thanks for the help Clojurians!

 Cheers,

 drewc
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Newbie: Default map parameters

[samppi]

In http://groups.google.com/group/clojure/browse_thread/thread/62140a28b8d4ef36,
the following example was given:

(defn test1 [{x :x, y :y, :or {:y 3}}]
[x y])
(test1 {:x 2}) => [2 3]

But this doesn't work on the latest Clojure from Subversion I just
got:

(test1 {:x 2}) => [2 nil]

Was this a feature that was removed? Or should it work?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Drew Crampsie]

2008/11/17 Matt Revelle <[EMAIL PROTECTED]>:
>
> Is the project site going to be more similar to the Python package
> index and CLiki or Sourceforge?

The closest analog is common-lisp.net.. which is like sourceforge.
However, I like the idea of an index as well, and building the backend
seems like a fun project, so don't rule this out as well.

Cliki is really just a wiki, and i host it as well, so adding another
Cliki instance for clojure projects is possible as well, if there is
demand.

>
> I still think keeping the site focused on providing an index of
> projects and storing project metadata is best.  Let projects use their
> code hosting solution of choice.

No particular code hosting solution will be enforced, but having seen
and used projects that moved project hosting sites to keep up with
trends in VCS, and having seen projects go from cvs->svn->darcs->git
without moving (on common-lisp.net), i can see some value to having
source hosting available on projecture as well.

Thanks for the input. Given the popularity of github, google code etc,
i don't plan to focus on the VCS aspect, but nor do i plan to ignore
it. It really comes  down to demand :).

Cheers,

drewc
>
> -Matt
>
>>
>>
>
>> On Mon, Nov 17, 2008 at 2:52 PM, Drew Crampsie <[EMAIL PROTECTED]
>> > wrote:
>>>
>>> Hey All,
>>>
>>> I've finally found some time to start getting the project hosting
>>> site
>>> together, and i need a name.. so lets put it to a vote.
>>>
>>> Here are some suggestions so far, but please feel free to chime in
>>> with your own as well.
>>>
>>> - projecture
>>> - clojr
>>> - proj4cloj
>>> - clojforge, cloforj,
>>> - forj
>>> - clojects
>>> - clojury
>>> - openjure
>>>
>>> Thanks for the help Clojurians!
>>>
>>> Cheers,
>>>
>>> drewc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Brian Carper]

On Nov 17, 11:52 am, Drew Crampsie <[EMAIL PROTECTED]> wrote:
> Here are some suggestions so far, but please feel free to chime in
> with your own as well.

What about something made of whole words, like clojureforge?  It has
the benefit of discoverability and being pronounceable by the human
tongue.  : )  Any URL that requires a person to spell it every time
it's said aloud is a bad thing, in my opinion.

Projecture is best on the list given.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Vincent Foley]

+1 for projecture

Vincent
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Aaron Brooks]

Other options:

 - creatjure?
 - featjure?
 - cultjure?

All three have low Google search hit counts. I think cultjure is
better suited for discussion forums. Creatjure seems a good place for
our Clojure creatures.

On Nov 17, 2:52 pm, Drew Crampsie <[EMAIL PROTECTED]> wrote:
> Hey All,
>
> I've finally found some time to start getting the project hosting site
> together, and i need a name.. so lets put it to a vote.
>
> Here are some suggestions so far, but please feel free to chime in
> with your own as well.
>
>  - projecture
>  - clojr
>  - proj4cloj
>  - clojforge, cloforj,
>  - forj
> - clojects
> - clojury
> - openjure
>
> Thanks for the help Clojurians!
>
> Cheers,
>
> drewc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Adam Jones]

On Nov 17, 11:52 am, Drew Crampsie <[EMAIL PROTECTED]> wrote:
> Hey All,
>
> I've finally found some time to start getting the project hosting site
> together, and i need a name.. so lets put it to a vote.
>
> Here are some suggestions so far, but please feel free to chime in
> with your own as well.
>
>  - projecture
>  - clojr
>  - proj4cloj
>  - clojforge, cloforj,
>  - forj
> - clojects
> - clojury
> - openjure
>

I'm liking forj, short and sweet.

> Thanks for the help Clojurians!
>
> Cheers,
>
> drewc
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Matt Moriarity]

my vote is for projecture or clojects
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Matt Revelle]

On Nov 17, 2008, at 3:08 PM, "J. McConnell" <[EMAIL PROTECTED]> wrote:

>
> I'm liking projecture

+1, at least from those options.

Is the project site going to be more similar to the Python package  
index and CLiki or Sourceforge?

I still think keeping the site focused on providing an index of  
projects and storing project metadata is best.  Let projects use their  
code hosting solution of choice.

-Matt

>
>

> On Mon, Nov 17, 2008 at 2:52 PM, Drew Crampsie <[EMAIL PROTECTED] 
> > wrote:
>>
>> Hey All,
>>
>> I've finally found some time to start getting the project hosting  
>> site
>> together, and i need a name.. so lets put it to a vote.
>>
>> Here are some suggestions so far, but please feel free to chime in
>> with your own as well.
>>
>> - projecture
>> - clojr
>> - proj4cloj
>> - clojforge, cloforj,
>> - forj
>> - clojects
>> - clojury
>> - openjure
>>
>> Thanks for the help Clojurians!
>>
>> Cheers,
>>
>> drewc
>>
>>
>>>
>>
>
> >

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: slime fu

[Bill Clementson]

Oops, yes, that's definitely better.

On Mon, Nov 17, 2008 at 12:03 PM,  <[EMAIL PROTECTED]> wrote:
>
> Maybe it was just my setup, but that didn't work for me.  What did
> work was:
>
> (add-hook 'slime-connected-hook 'slime-redirect-inferior-output)
>
> --Darren
>
>
> On Nov 17, 11:42 am, "Bill Clementson" <[EMAIL PROTECTED]> wrote:
>> You could add the following to your .emacs file:
>>
>> (add-hook 'slime-mode-hook 'slime-redirect-inferior-output)
>>
>> --
>> Bill Clementson
>>
>> On Mon, Nov 17, 2008 at 11:31 AM, Stuart Halloway
>>
>> <[EMAIL PROTECTED]> wrote:
>>
>> > Is there are way to make (slime-redirect-inferior-output) happen by
>> > default?
>>
>> > Stuart
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Craig Andera]

Despite the fact that I suggested clojury and openjure in the first
place, I think I like clojr, forj, projecture, and clojects, in that
order.

Decisive - that's me!

> On Mon, Nov 17, 2008 at 3:08 PM, J. McConnell <[EMAIL PROTECTED]> wrote:
>>
>> I'm liking projecture
>>
>> On Mon, Nov 17, 2008 at 2:52 PM, Drew Crampsie <[EMAIL PROTECTED]> wrote:
>>>
>>> Hey All,
>>>
>>> I've finally found some time to start getting the project hosting site
>>> together, and i need a name.. so lets put it to a vote.
>>>
>>> Here are some suggestions so far, but please feel free to chime in
>>> with your own as well.
>>>
>>>  - projecture
>>>  - clojr
>>>  - proj4cloj
>>>  - clojforge, cloforj,
>>>  - forj
>>> - clojects
>>> - clojury
>>> - openjure
>>>
>>> Thanks for the help Clojurians!
>>>
>>> Cheers,
>>>
>>> drewc
>>>
>>>
>>> >
>>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[Stephen C. Gilardi]

On Nov 17, 2008, at 3:08 PM, J. McConnell wrote:

> I'm liking projecture

And its evil twin anti-site...

conjecture

--Steve


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[J. McConnell]

I'm liking projecture

On Mon, Nov 17, 2008 at 2:52 PM, Drew Crampsie <[EMAIL PROTECTED]> wrote:
>
> Hey All,
>
> I've finally found some time to start getting the project hosting site
> together, and i need a name.. so lets put it to a vote.
>
> Here are some suggestions so far, but please feel free to chime in
> with your own as well.
>
>  - projecture
>  - clojr
>  - proj4cloj
>  - clojforge, cloforj,
>  - forj
> - clojects
> - clojury
> - openjure
>
> Thanks for the help Clojurians!
>
> Cheers,
>
> drewc
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Patch: standalone compiler (almost)

[Matt Revelle]

I like it and Obj-C inspired syntax on the JVM is cosmic justice.

On Nov 17, 2008, at 2:37 PM, "Stephen C. Gilardi" <[EMAIL PROTECTED]>  
wrote:

>
> On Nov 17, 2008, at 9:51 AM, Rich Hickey wrote:
>>  main now needs to be called -main, as all methods will be defined  
>> with leading -.
>
> Seeing that makes me think of Objective-C where instance methods  
> have a leading - and static methods (class methods) having a leading  
> +. I think a convention like that might make for an easier read than  
> associating #^{:static true} with static methods, so I thought I'd  
> mention it.
>
> --Steve
>
>
> >

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: slime fu

[darren . austin]

Maybe it was just my setup, but that didn't work for me.  What did
work was:

(add-hook 'slime-connected-hook 'slime-redirect-inferior-output)

--Darren


On Nov 17, 11:42 am, "Bill Clementson" <[EMAIL PROTECTED]> wrote:
> You could add the following to your .emacs file:
>
> (add-hook 'slime-mode-hook 'slime-redirect-inferior-output)
>
> --
> Bill Clementson
>
> On Mon, Nov 17, 2008 at 11:31 AM, Stuart Halloway
>
> <[EMAIL PROTECTED]> wrote:
>
> > Is there are way to make (slime-redirect-inferior-output) happen by
> > default?
>
> > Stuart
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: POLL: Domain name for project hosting site.

[David Hilton]

On Mon, Nov 17, 2008 at 12:52 PM, Drew Crampsie <[EMAIL PROTECTED]>wrote:

>
> Hey All,
>
> I've finally found some time to start getting the project hosting site
> together, and i need a name.. so lets put it to a vote.
>
> Here are some suggestions so far, but please feel free to chime in
> with your own as well.
>
>  - projecture
>  - clojr
>  - proj4cloj
>  - clojforge, cloforj,
>  - forj
> - clojects
> - clojury
> - openjure


Clojforge and clojury seem to roll off the tongue fairly well.

David

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

POLL: Domain name for project hosting site.

[Drew Crampsie]

Hey All,

I've finally found some time to start getting the project hosting site
together, and i need a name.. so lets put it to a vote.

Here are some suggestions so far, but please feel free to chime in
with your own as well.

 - projecture
 - clojr
 - proj4cloj
 - clojforge, cloforj,
 - forj
- clojects
- clojury
- openjure

Thanks for the help Clojurians!

Cheers,

drewc


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: slime fu

[Bill Clementson]

You could add the following to your .emacs file:

(add-hook 'slime-mode-hook 'slime-redirect-inferior-output)

--
Bill Clementson

On Mon, Nov 17, 2008 at 11:31 AM, Stuart Halloway
<[EMAIL PROTECTED]> wrote:
>
> Is there are way to make (slime-redirect-inferior-output) happen by
> default?
>
> Stuart
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Patch: standalone compiler (almost)

[Stephen C. Gilardi]

On Nov 17, 2008, at 9:51 AM, Rich Hickey wrote:
>  main now needs to be called -main, as all methods will be defined  
> with leading -.

Seeing that makes me think of Objective-C where instance methods have  
a leading - and static methods (class methods) having a leading +. I  
think a convention like that might make for an easier read than  
associating #^{:static true} with static methods, so I thought I'd  
mention it.

--Steve


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[notallama]

the vector syntax seems nice to me. you get the whole "() means
function", "[] means sequential binding", "{} means associative
binding", and it makes code easier to read/skim over.
you could have lists for seq binding, but i think using a different
syntax gets you out of that "everything is a list" way of thinking.

also, something i just thought of:
maybe some time, you could have a function like: (fn {a 5, b 1, [c d]
3, :or {a "hay guys"}} [a b c d])
things like that can be harder to think about if you're used to
nothing but lists.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

slime fu

[Stuart Halloway]

Is there are way to make (slime-redirect-inferior-output) happen by  
default?

Stuart

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: offtopic - where are you come from? (poll)

[[EMAIL PROTECTED]]

+1 for Baltimore.

On Oct 17, 8:12 am, Paul Barry <[EMAIL PROTECTED]> wrote:
> Baltimore, Maryland, US
>
> On Oct 17, 5:27 am, "Rastislav Kassak" <[EMAIL PROTECTED]> wrote:
>
> > Hello Clojurians,
>
> > I think after 1st year of Clojure life it's good to check how far has
> > Clojure spread all over the world.
>
> > So wherever are you come from, be proud and say it.
>
> > I'm from Slovakia. :)
>
> > RK

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Daily Build

[Robert Winslow]

Is there a server that tests every day if Clojure builds correctly? I
pulled the latest a few days ago and couldn't get it to build (whereas
the 2008-09-16 "release" does build for me). Having this server would
assist in determining if such problems are the user's fault (likely)
or not (unlikely).

Robert

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: add-classpath erroring out, post r1100...

[Phil Jordan]

Rich Hickey wrote:
> I'm going to deprecate add-classpath because people consistently use
> it to avoid the standard classpath-setting mechanisms, at least until
> I can figure out a way to coordinate it with the standard classloader.

You could make it a thread-local binding within the repl and unbind it
when gets (load )ed from file. That'll show 'em! ;)

~phil

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: add-classpath erroring out, post r1100...

[Scott Fleckenstein]

Thanks Rich,

While I understand the desire to stick with java conventions when it
comes to adding to the classpath, it is too bad because it takes away
from the 'explorability' you get with a Repl.  I've gotten into the
habit of just dumping jars into my scratch folder and tooling away on
my running Repl to learn an API.  Oh well, I can tweak my workflow :)

-Scott

On Nov 17, 10:32 am, Rich Hickey <[EMAIL PROTECTED]> wrote:
> On Nov 17, 1:00 pm, Scott Fleckenstein <[EMAIL PROTECTED]> wrote:
>
>
>
> > Hi All,
>
> > I've run into a bug since upgrading past revision 1100, specifically
> > around adding to the classpath at runtime using add-classpath.  I've
> > attached a test case 
> > here:http://s3.amazonaws.com/nullstyle/precompile-bug.tar.gz
>
> > That file has three versions of clojure (r1100, r1101, r1106) and
> > web.clj, a sample app that loads jetty and starts a simple web
> > server.  You can use run.sh in that same tar to run each revision, one
> > after the other, to illustrate the breakage.
>
> > Basically, after adding a jar to the classpath, when importing a class
> > file from that jar I get a ClassNotFoundException thrown.  I don't
> > have enough java experience to know what would cause this problem.
> > Things work as expected on revision 1100.
>
> > Does anyone know what would cause this?  I'd be happy to put in the
> > time to help debug and fix this, but I'm at a loss for where next to
> > go.
>
> Such use of add-classpath is discouraged. The only reason for add-
> classpath is to let you pull in something if you've started up the
> repl without it. It shouldn't be a permanent part of any application
> design. In your case, you can get the local Jetty jars in the mix by
> supplying an extension dirs directive (-Djava.ext.dirs=) on the
> command line:
>
> java -Djava.ext.dirs=. -cp clojure-r1106.jar clojure.lang.Script
> web.clj
>
> All three revisions work with this change, and you can remove the add-
> classpath calls.
>
> The change that caused this is that now .class files for Clojure fn
> classes can be found and loaded by a classloader higher up in the
> chain, one which can't see the effects of add-classpath.
>
> I'm going to deprecate add-classpath because people consistently use
> it to avoid the standard classpath-setting mechanisms, at least until
> I can figure out a way to coordinate it with the standard classloader.
>
> Rich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: add-classpath erroring out, post r1100...

[Rich Hickey]

On Nov 17, 1:00 pm, Scott Fleckenstein <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I've run into a bug since upgrading past revision 1100, specifically
> around adding to the classpath at runtime using add-classpath.  I've
> attached a test case 
> here:http://s3.amazonaws.com/nullstyle/precompile-bug.tar.gz
>
> That file has three versions of clojure (r1100, r1101, r1106) and
> web.clj, a sample app that loads jetty and starts a simple web
> server.  You can use run.sh in that same tar to run each revision, one
> after the other, to illustrate the breakage.
>
> Basically, after adding a jar to the classpath, when importing a class
> file from that jar I get a ClassNotFoundException thrown.  I don't
> have enough java experience to know what would cause this problem.
> Things work as expected on revision 1100.
>
> Does anyone know what would cause this?  I'd be happy to put in the
> time to help debug and fix this, but I'm at a loss for where next to
> go.
>

Such use of add-classpath is discouraged. The only reason for add-
classpath is to let you pull in something if you've started up the
repl without it. It shouldn't be a permanent part of any application
design. In your case, you can get the local Jetty jars in the mix by
supplying an extension dirs directive (-Djava.ext.dirs=) on the
command line:

java -Djava.ext.dirs=. -cp clojure-r1106.jar clojure.lang.Script
web.clj

All three revisions work with this change, and you can remove the add-
classpath calls.

The change that caused this is that now .class files for Clojure fn
classes can be found and loaded by a classloader higher up in the
chain, one which can't see the effects of add-classpath.

I'm going to deprecate add-classpath because people consistently use
it to avoid the standard classpath-setting mechanisms, at least until
I can figure out a way to coordinate it with the standard classloader.

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

add-classpath erroring out, post r1100...

[Scott Fleckenstein]

Hi All,

I've run into a bug since upgrading past revision 1100, specifically
around adding to the classpath at runtime using add-classpath.  I've
attached a test case here: 
http://s3.amazonaws.com/nullstyle/precompile-bug.tar.gz

That file has three versions of clojure (r1100, r1101, r1106) and
web.clj, a sample app that loads jetty and starts a simple web
server.  You can use run.sh in that same tar to run each revision, one
after the other, to illustrate the breakage.

Basically, after adding a jar to the classpath, when importing a class
file from that jar I get a ClassNotFoundException thrown.  I don't
have enough java experience to know what would cause this problem.
Things work as expected on revision 1100.

Does anyone know what would cause this?  I'd be happy to put in the
time to help debug and fix this, but I'm at a loss for where next to
go.

Thanks,
Scott Fleckenstein

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Patch: standalone compiler (2nd try)

[Stuart Sierra]

Patch attached.  This uses clojure.core/compile.  But it still doesn't
work.  I get the same error Stephen reported:

 [java] java.lang.IllegalStateException: Var null/null is unbound.
(core.clj:21)
 [java] at
org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:194)
 [java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:747)
...
 [java] Caused by: java.lang.IllegalStateException: Var null/null
is unbound. (core.clj:21)
 [java] at clojure.lang.Compiler.analyzeSeq(Compiler.java:4067)
 [java] at clojure.lang.Compiler.analyze(Compiler.java:3896)
...
 [java] Caused by: java.lang.IllegalStateException: Var null/null
is unbound.
 [java] at clojure.lang.Var.get(Var.java:129)
 [java] at clojure.lang.Compiler$FnExpr.parse(Compiler.java:2947)
 [java] at clojure.lang.Compiler.analyzeSeq(Compiler.java:4058)
 [java] ... 42 more
 [java] --- Nested Exception ---
 [java] java.lang.IllegalStateException: Var null/null is unbound.
(core.clj:21)
 [java] at clojure.lang.Compiler.analyzeSeq(Compiler.java:4067)
 [java] at clojure.lang.Compiler.analyze(Compiler.java:3896)
...
 [java] Caused by: java.lang.IllegalStateException: Var null/null
is unbound.
 [java] at clojure.lang.Var.get(Var.java:129)
 [java] at clojure.lang.Compiler$FnExpr.parse(Compiler.java:2947)
 [java] at clojure.lang.Compiler.analyzeSeq(Compiler.java:4058)
 [java] ... 42 more


-Stuart Sierra

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Index: src/clj/precompile.clj
===
--- src/clj/precompile.clj	(revision 1106)
+++ src/clj/precompile.clj	(working copy)
@@ -1,11 +0,0 @@
-;; This script is run by the Ant build task to precompile the core
-;; Clojure source files.
-
-(println "Compiling Clojure core sources...")
-
-(binding [*compile-path* (System/getProperty "clojure.compile.path")]
-  (compile 'clojure.core)
-  (compile 'clojure.set)
-  (compile 'clojure.xml)
-  (compile 'clojure.zip)
-  (compile 'clojure.inspector))
Index: src/jvm/clojure/lang/CompileFiles.java
===
--- src/jvm/clojure/lang/CompileFiles.java	(revision 0)
+++ src/jvm/clojure/lang/CompileFiles.java	(revision 0)
@@ -0,0 +1,58 @@
+/**
+ *   Copyright (c) Rich Hickey. All rights reserved.
+ *   The use and distribution terms for this software are covered by the
+ *   Common Public License 1.0 (http://opensource.org/licenses/cpl.php)
+ *   which can be found in the file CPL.TXT at the root of this distribution.
+ *   By using this software in any fashion, you are agreeing to be bound by
+ * 	 the terms of this license.
+ *   You must not remove this notice, or any other, from this software.
+ **/
+
+package clojure.lang;
+
+import java.io.OutputStreamWriter;
+import java.io.PrintWriter;
+import java.io.IOException;
+import java.io.File;
+import java.io.Reader;
+import java.io.FileReader;
+import java.io.BufferedReader;
+import java.util.List;
+import java.util.Arrays;
+
+/** Static compiler for .clj files.  All files given on the command
+ * line will be compiled and saved to the directory named in the Java
+ * system property "clojure.compile.path".  That directory must also
+ * be on the classpath. */
+public class CompileFiles {
+
+private static final String PATH_PROP = "clojure.compile.path";
+private static final Var COMPILE = RT.var("clojure.core", "compile");
+private static final IFn COMPILE_FN = COMPILE.fn();
+private static final Var NS = RT.var("clojure.core", "*ns*");
+static final Symbol USER = Symbol.create("user");
+static final Symbol CLOJURE = Symbol.create("clojure.core");
+
+static final Var in_ns = RT.var("clojure.core", "in-ns");
+static final Var refer = RT.var("clojure.core", "refer");
+
+public static void main(String[] args) throws Exception {
+if (System.getProperty(PATH_PROP) == null) {
+System.err.println("ERROR: Must set system property " + PATH_PROP +
+   "\nto the location for compiled .class files." +
+   "\nThis directory must also be on your CLASSPATH.");
+System.exit(1);
+}
+Var.pushThreadBindings(RT.map(NS, NS.get(),
+  Compiler.COMPILE_FILES, RT.T,
+  Compiler.COMPILE_PATH, System.getProperty(PATH_PROP),
+  RT.WARN_ON_REFLECTION, RT.WARN_ON_REFLECTION.get()));
+in_ns.invoke

Re: Strange behaviour

[Konrad Hinsen]

On Nov 17, 2008, at 14:30, Rich Hickey wrote:

> It's best to do this as generally as possible, building on something
> like this:
>
> (defn map-same [f coll]
>   (let [ret (into (empty coll) (map f coll))]
> (if (seq? coll)
>   (reverse ret)
>   ret)))

OK, so I have as a minimal set of cases (1) seq (2) other coll and  
(3) everything else. That gives me

(defn replace-syms
[sym-map expr]
(cond (coll? expr) (let [replace #(replace-syms sym-map %)
 r-expr (map replace expr)]
  (if (seq? expr)
 r-expr
 (into (empty expr) r-expr)))
  (contains? sym-map expr) (get sym-map expr)
  :else expr))


This experience leaves me wondering if perhaps "seq" is the closest  
equivalent to the list concept in other Lisps. Everything that test  
positive with (seq?) seems to print like a list and behave like a  
list. But then, what would be a valid reason to use the (list?) test?

Konrad.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: thanks, errata, and one gaffe

[Stuart Halloway]

It's harder than that. :-) In general, to coordinate two transactional  
systems, you need a transaction coordinator, like Microsoft's DTC or  
the ones baked into various JEE containers. And that is what you are  
talking about here: the Tx system in Clojure + the Tx system in a  
database.

Good news is that true coordination is not always needed.

Better news is that Rich may have something in mind, per his recent  
comment about UUID in the source code.

> I'm really interested in how you would coordinate a database
> transaction with an STM transaction.  Do you message an agent to do
> the database update?
>
> On Mon, Nov 17, 2008 at 6:13 AM, Stuart Halloway
> <[EMAIL PROTECTED]> wrote:
>>
>> Hi Brian,
>>
>> The libraries chapter will cover a bunch of different libraries in
>> Clojure-Contrib and elsewhere. Obviously, being only one chapter, it
>> won't go terribly deep. I'd love to hear what folks want to see. I am
>> planning on at least:
>>
>> * db
>> * web apps
>> * testing/BDD
>> * zipper
>>
>>>
>>> Stuart:
>>>
>>> I read through the table of contents. Are you planning on addressing
>>> interacting with a database (preferably postgres or mysql) in
>>> Clojure?
>>>
>>> Maybe the "Working with Java" chapter will be sufficient, but one of
>>> the benefits of Clojure is "batteries included", so helping folks  
>>> get
>>> up to speed with a db example would be great.
>>>
>>> Brian
>>>

>>
>>
>>>
>>
>
>
>
> -- 
> Howard M. Lewis Ship
>
> Creator Apache Tapestry and Apache HiveMind
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

"Parallel Programming with Transactional Memory" (ACM Queue Article)

[Randall R Schulz]

Hi,

Clojure users might find this ACM Queue article interesting:

-==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-
"Parallel Programming with Transactional Memory"



While still primarily a research project, transactional memory
shows promise for making parallel programming easier.

by Ulrich Drepper, Red Hat

 From the The Concurrency Problem issue, vol. 6, no. 5 - September 2008

article excerpt:

"With the speed of individual cores no longer increasing at the rate we 
came to love over the past decades, programmers have to look for other 
ways to increase the speed of our ever-more-complicated applications. 
The functionality provided by the CPU manufacturers is an increased 
number of execution units, or CPU cores.

..."
-==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==-


Randall Schulz

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[Luc Prefontaine]

I fully agree with you Konrad.

If Clojure eases up code reading for non-Lispers while not changing the
principles behind then what's the problem ?
As far as breaking the s-expr esthetics... bof, I could not care less.
Easier here means easier to understand for non-Lispers.
They are the ones we need to convince to embrace Clojure. Before
commonly used applications starts to generate code as part of their
design
will not be the norm before a decade at least. Then we can start to
worry about s-expr lack of uniformity if really this is still an issue.

Clojure unifies a lot of operations on diverse data structures and this
compensates a lot for this scratch to s-expr esthetic.
Just for this advantage, I will never cry in despair for the lack of
car, cdr, cadr and other siblings...  

We used to have an Algol-60 compiler on the DEC-10 and event in the
1980s it was seldom used, mainly to show some
compiler/language principles. I would never attempted to create a
dialect based on Algo and hope that it flies.

Algol is unknown to the majority of coders these days, they're more
familiar with Java hence the edge
that Clojure has compared to other Lisp dialects. Most people have a
great lack of historical perspective so for them anything
coming up on the market are "new" concepts. Who remembers Simula-67 ? I
do because I worked with it so when C++ and then
Java came up those object concepts were not surprises for me but it was
for many of my younger co-workers at the time.

Everyone was looking at this stuff as the latest Ferrari, for me it
looked like a revamped Ford model T. For me many aspects of the
Java language were annoying because of my previous experience with
Simula-67 but for newcomers it was not an issue.
For them it looked like the 8th marvel of the world...

It's not only a taste issue, it's about habits and mind flexibility.
Like any new language (I'm up to around 15 excluding half a dozen
assembly languages)
I had to bend my mind a bit to learn Clojure but no need to get myself
lobotomized here :)))


Luc

On Mon, 2008-11-17 at 14:22 +0100, Konrad Hinsen wrote:

> On Nov 17, 2008, at 13:56, Simon Brooke wrote:
> 
> > However, you're dead wrong about Lots of Irritating Stupid
> > Parentheses. They are the heart of the language: the fact that it does
> > not need any irregular syntax, because everything is regular.
> 
> For me, the heart of Lisp is that code is expressed in terms of data  
> structures, i.e. that there is no separate syntax for code and data.  
> Clojure respects that principle.
> 
> While it is true that Clojure's syntax is slightly less regular than  
> other Lisps' in using both lists and vectors to define code, that is  
> a minor issue for me, and my experience is that Clojure code is  
> definitely easier to read than other Lisps because of this.
> 
> Of course, the only universally true statement about syntax is that  
> it is a matter of taste...
> 
> Konrad.
> 
> > 
> 

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: thanks, errata, and one gaffe

[Howard Lewis Ship]

I'm really interested in how you would coordinate a database
transaction with an STM transaction.  Do you message an agent to do
the database update?

On Mon, Nov 17, 2008 at 6:13 AM, Stuart Halloway
<[EMAIL PROTECTED]> wrote:
>
> Hi Brian,
>
> The libraries chapter will cover a bunch of different libraries in
> Clojure-Contrib and elsewhere. Obviously, being only one chapter, it
> won't go terribly deep. I'd love to hear what folks want to see. I am
> planning on at least:
>
> * db
> * web apps
> * testing/BDD
> * zipper
>
>>
>> Stuart:
>>
>> I read through the table of contents. Are you planning on addressing
>> interacting with a database (preferably postgres or mysql) in
>> Clojure?
>>
>> Maybe the "Working with Java" chapter will be sufficient, but one of
>> the benefits of Clojure is "batteries included", so helping folks get
>> up to speed with a db example would be great.
>>
>> Brian
>>
>> >
>
>
> >
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Patch: standalone compiler (almost)

[Stephen C. Gilardi]

> I think you've got some of the interim work I've done integrating gen-
> class. main now needs to be called -main, as all methods will be
> defined with leading -.

I'm at SVN 1106 which doesn't appear to have any changes relative to  
1104 in this area. My compiled "hello.clj" works with its function  
called simply "main".

--Steve


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure.contrib.test-is changes

[Stuart Sierra]

Hi Paul,
Thanks, glad you like it.  I hadn't seen your earlier post -- wasn't
following the group for a couple weeks there.  My first inclination is
not to catch any Error subclasses, as Sun says,
http://java.sun.com/javase/6/docs/api/java/lang/Error.html

But, StackOverflowError might be an exception (no pun intended) to the
rule, at least according to this guy:
http://blog.igorminar.com/2008/05/catching-stackoverflowerror-and-bug-in.html

In any case, if you want to assert that a particular form *always*
throws an error, you can use the "throws" macro:

user=> (use 'clojure.contrib.test-is)
nil
user=> (defn foo ([] (foo))
 {:test (fn [] (throws java.lang.StackOverflowError (foo)))})
#'user/foo
user=> (run-tests)
Testing user

Ran 1 tests with 1 assertions.
0 failures, 0 exceptions.
nil
user=> (foo)
java.lang.StackOverflowError (NO_SOURCE_FILE:0)


So I probably won't catch Error, unless there's another scenario in
which it's needed.
-Stuart Sierra



On Nov 17, 6:33 am, "Paul Drummond" <[EMAIL PROTECTED]> wrote:
> Hi Stuart,
>
> Cool additions - I will certainly use them.
>
> Regarding test-is additions, did you ever get a chance to check out the
> patch I submitted a while back?
>
> http://groups.google.com/group/clojure/browse_thread/thread/c509d589e...
>
> It was my first patch so appologies if there are some glaring errors or
> bad-style in there (but it was a very simple addition so I'd hope not!).
>
> I realised just after posting that catching Errors in the general case could
> be viewed as a no-no because the JVM could be in an unstable state after the
> Error (depending on which error was thrown) so the desired outcome would be
> to terminate.  Is that your view?
>
> For my particular scenario, I wanted test-is to support StackOverflowError.
> I was working on a SICP exercise that caused StackOverflowErrors and I
> wanted to have a test that passed when a StackOverflowError occurred, then
> continue processing other tests.  So in my specific case, I felt the patch
> made sense but maybe supporting *all* Errors is going to far?
>
> Hmmm
>
> Cheers,
> Paul.
>
> --
> Iode Software Ltd, registered in England No. 6299803.
>
> Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne &
> Wear, DH5 8NE.
>
> This message is intended only for the use of the person(s) ("the intended
> recipient(s)") to whom it is addressed. It may contain information which is
> privileged and confidential within the meaning of applicable law. If you are
> not the intended recipient, please contact the sender as soon as possible.
> The views expressed in this communication may not necessarily be the views
> held by The Company.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Patch: standalone compiler (almost)

[Stuart Sierra]

On Nov 17, 8:50 am, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote:
> In working through this, I also found that a compiler driver written  
> in Java may be preferable for use via build.xml because of a bootstrap  
> problem.

Yes, that's why I wanted to implement it in Java.
-S
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[Dave Newton]

--- On Mon, 11/17/08, Rich Hickey wrote:
> I've presented Clojure to many of the people who wrote 
> CL and Scheme, and no one can deny it is a Lisp.

I'd also add that at Lisp50 Clojure was very well received by many Lisperati, 
and many, if not most, of the folks there were *way* into Scheme and Lisp 
(although most also share a certain... hesitation when it comes to CL ;) with 
several I'd even classify as gushing-in-the-reserved-Lisp-fashion.

On an un-related note, at one point gls sat down next to me in the back of the 
room. I texted to a friend of mine "omg guy steele just sat down next to me" 
and my friend (he's young) texted back "cool ask him who guy steele is".

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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Patch: standalone compiler (almost)

[Rich Hickey]

On Nov 17, 8:50 am, "Stephen C. Gilardi" <[EMAIL PROTECTED]> wrote:
> On Nov 16, 2008, at 10:34 PM, Rich Hickey wrote:
>
> > Since it only requires main, might I suggest you write this in
> > Clojure instead?
>
> I gave that a try.
>
> Here's a simple version of a driver for the compiler, stored in src/
> clj/clojure/compile.clj:
>
> (ns clojure.compile)
>
> (defn main
>   "Compiles libs into class files stored at compile-path.
>   All args are strings"
>   [compile-path & libs]
>   (printf "Compiling %d libs to %s\n" (count libs) compile-path)
>   (flush)
>   (binding [*compile-path* compile-path]
> (doseq [lib libs]
> (compile (symbol lib)
>
> It works when run from within the Clojure repl:
>
> % ls build/classes/clojure/hello*
> ls: build/classes/clojure/*hello*: No such file or directory
> % java -cp clojure.jar:src/clj/ clojure.lang.Repl
> Clojure
> user=> (require 'clojure.compile)
> nil
> user=> (clojure.compile/main "build/classes" "clojure.hello")
> Compiling 1 libs to build/classes
> nil
> user=>
> % ls build/classes/clojure/hello*
> build/classes/clojure/hello$main__8.class   build/classes/clojure/
> hello.class
>
> but when run as a standalone main, it gives an exception that appears
> to be related to static initializers:
>
> % java -cp clojure.jar:src/clj/ clojure.compile build/classes
> clojure.hello
> Compiling 1 libs to build/classes
> Exception in thread "main" java.lang.IllegalStateException: Var null/
> null is unbound. (hello.clj:3)
> For reference, here is the test compilee: src/clj/clojure/hello.clj:
>
> (ns clojure.hello)
>
> (defn main
>   [greetee]
>   (printf "Hello, %s wow\n" greetee)
>   (flush))
>
> I'd appreciate help in getting a standalone invocation of something
> like compile.clj above (i.e., using it's own main without Repl or
> Script) to work.
>

I think you've got some of the interim work I've done integrating gen-
class. main now needs to be called -main, as all methods will be
defined with leading -.

> In working through this, I also found that a compiler driver written
> in Java may be preferable for use via build.xml because of a bootstrap
> problem. Until we compile (something like) "compile.clj", we can't
> call it as a standalone main. (One could add a step that builds the
> compiler driver via a clojure.lang.Script invocation.)
>

Good point. This may just be an exercise then.

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[Michael Wood]

On Mon, Nov 17, 2008 at 4:18 PM, Stuart Halloway
<[EMAIL PROTECTED]> wrote:
>
> Hi Simon,
>
> I have converted a bunch of the examples from Practical Common Lisp
> into Clojure [1].  You might find this helpful in seeing things from a
> Clojure perspective.
>
> Cheers,
> Stuart
>
> [1] http://blog.thinkrelevance.com/2008/9/16/pcl-clojure

Are you planning on updating these to work with current versions of Clojure? :)

e.g. the syntax for doseq has changed.

-- 
Michael Wood <[EMAIL PROTECTED]>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[Rich Hickey]

You contend that Lisp is regular, without defining regular. I contend
that as soon as you have ' it is not regular, and no one writes Lisp
without '.

You keep using the term 'syntax' for Clojure's non-list data
structures. If list literals are not syntax, neither are vector or map
literals.

You consistently presume the differences in Clojure are gratuitous.
That presumption isn't going to help you, as it is wrong.

I understand, you have a world with which you are familiar, and enter
a new world where things are different, and it's frustrating. But you
are complaining about how it ought to be more similar to what you
know, without spending any time to understand why it is the way it is.
Part of that may come from expectations driven by the claim that
Clojure is a Lisp. It is a Lisp, but in a much more expansive notion
of Lisp than a mere syntactic one. I've presented Clojure to many of
the people who wrote CL and Scheme, and no one can deny it is a Lisp.
But it is not Common Lisp, nor Scheme, nor a derivative thereof. I am
not 'changing things'. I've written a new Lisp.

In some ways, you sound a lot like the people drifting into
comp.lang.lisp over the years, who within the first few hours/days
with CL know what's wrong with it and how it should be changed in
order to be better. Those people normally get responses of this sort:
once you understand it, these differences will seem less gratuitous
and you'll see how it all fits together. Same here, with fewer
flames :)

I contend that Clojure is as regular as Common Lisp, i.e. both are
mostly regular, except for reader macros. That the point of Lisp is
not 'everything is a list', but that 'code is data', which is true for
Clojure. Clojure is not like Dylan, or Arc.

Nothing about the differences is gratuitous. There is a holistic
nature to Clojure that it may take a while to see. Not every decision
is ideal, but all were considered.

I think you'll have a much better experience if you:

Keep an open mind.

Ask questions rather than presume. If you must presume, presume the
better rather than the worse.

Leverage the documentation and support channels - there are 82 people
logged in to the #clojure IRC right now. Someone there could get you
unstuck in an instant rather than an hour.

Accept up front that it is going to be different.

Yes, cond has fewer parens, and do and assoc mean something different
etc. These things, while initially frustrating, are superficial. Many
Lispers have become productive with Clojure. Yes, there could be more
of a roadmap for Lispers, but there's a Wiki and I encourage users to
help each other out by contributing any advice or tips they feel will
be helpful.

I think, if you stick with it, you'll find that Clojure is indeed a
Lisp, at a deep level, and its core non-list data structures are
considerably lispier than their counterparts in other Lisps. That
Clojure programs are shorter and clearer than corresponding CL
programs. That the sequence abstraction is a powerful expansion of the
list concept. That adding first-class maps/sets/vectors to lists is
empowering. That functional programming and concurrency are well
supported. And much more.

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[Stuart Halloway]

Hi Simon,

I have converted a bunch of the examples from Practical Common Lisp  
into Clojure [1].  You might find this helpful in seeing things from a  
Clojure perspective.

Cheers,
Stuart

[1] http://blog.thinkrelevance.com/2008/9/16/pcl-clojure

> Has anyone written a very simple introduction to Clojure for LISP
> hackers? I've spend an evening playing with it pretty intensively, and
> thus far I haven't got a thing to work. I've read
> http://en.wikibooks.org/wiki/Clojure_Programming#Clojure_for_Common_Lisp_Programmers
>  
> ,
> but it hasn't helped me.
>
> In LISP:
>
> * (defun fact (n) (cond ((= 1 n) 1)(t (* n (fact (- n 1))
> FACT
> * (fact 10)
> 3628800
>
> that is Common LISP, but what the hell; in Portable Standard LISP it
> would have been identical except 'de' instead of 'defun'; in Scheme
> it's a little different:
>
>> (define (fact n) (cond ((= n 1) 1)(#t (* n (fact (- n 1))
>> (fact 10)
> 3628800
>
> But the family resemblance is there... So, let's try it in Clojure:
>
> user=> (defun fact (n) (cond ((= n 1) 1) (t (* n (fact (- n 1))
> java.lang.Exception: Unable to resolve symbol: defun in this context
> user=> (de fact (n) ( cond ((= n 1) 1) (t (* n (fact (- n 1))
> java.lang.Exception: Unable to resolve symbol: de in this context
> user=> (def fact (n) ( cond ((= n 1) 1) (t (* n (fact (- n 1))
> java.lang.Exception: Too many arguments to def
> user=> (defn fact [n] (cond ((= n 1) 1)(t (* n (fact (- n 1))
> java.lang.Exception: Unable to resolve symbol: t in this context
> user=> (defn fact [n](cond ((= n 1) 1)(#t  (* n (fact (- n 1))
> java.lang.Exception: No dispatch macro for: t
> user=> (defn fact [n](cond ((= n 1) 1)(#true (* n (fact (- n 1))
> java.lang.Exception: No dispatch macro for: t
> user=> (defn fact [n] (cond ((= n 1) 1)(true (* n (fact (- n 1))
> #'user/fact
>
> OK, what's with the funny square brackets? A sequence of forms
> enclosed in square brackets is a vector, not a list. Why is the
> arglist for a function a vector? For now let's accept that it is, and
> pass on.
>
> user=> (fact 10)
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to
> clojure.lang.IFn
>
> OK, so that doesn't work. As Zaphod memorably put it, 'hey, what is
> truth, man?' Good question:
>
> user=> (true? 'true)
> true
> user=> (true? true)
> true
> user=> (true? t)
> java.lang.Exception: Unable to resolve symbol: t in this context
> user=> (true? 't)
> false
> user=> (def t 'true)
> #'user/t
> user=> (true? t)
> true
>
> OK, now we know the truth, surely we can write a valid fact?
>
> user=> (defn fact [n] (cond ((= n 1) 1)('true (* n (fact (- n 1))
> #'user/fact
> user=> (fact 10)
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to
> clojure.lang.IFn
> user=> (defn fact [n] (cond ((= n 1) 1)((true? 'true) (* n (fact (- n
> 1))
> #'user/fact
> user=> (fact 10)
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to
> clojure.lang.IFn
>
> OK, it looks like whatever's causing the break isn't the guard on the
> second cond branch. Let's for a moment try something that's purely
> boolean:
>
> user=> (defn band [l] (cond ((nil? l) true)((true? (car l))(band (cdr
> l)
> java.lang.Exception: Unable to resolve symbol: cdr in this context
>
> No CDR? It's LISP, but it can't fetch the contents of the decrement
> register? fifty years of LISP history tossed into the dirt. So if the
> CDR isn't called the CDR, what is it called (and what's the CDADR
> called)?
>
> user=> (defn band [l] (cond ((nil? l) true)((true? (first l))(band
> (rest l)
> #'user/band
> user=> (band '(true true true))
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to
> clojure.lang.IFn
>
> OK, can we write any function at all that works?
>
> user=> (defn square [n] (* n n))
> #'user/square
> user=> (square 4)
> 16
>
> Fine, so recurse up from that:
>
> user=> (defn power [n m] (cond ((= m 0) 1)(true (* n (power n (- m
> 1))
> #'user/power
> user=> (power 2 2)
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to
> clojure.lang.IFn
>
> Aggghhh...
>
> Getting LISP to work seamlessly inside a Java environment with easy
> intercalling between LISP and Java is a very big win, and potentially
> knocks things like JScheme and Armed Bear Common LISP into a cocked
> hat...
>
> But it would be nice to be able to get started!
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: thanks, errata, and one gaffe

[Stuart Halloway]

Hi Brian,

The libraries chapter will cover a bunch of different libraries in  
Clojure-Contrib and elsewhere. Obviously, being only one chapter, it  
won't go terribly deep. I'd love to hear what folks want to see. I am  
planning on at least:

* db
* web apps
* testing/BDD
* zipper

>
> Stuart:
>
> I read through the table of contents. Are you planning on addressing
> interacting with a database (preferably postgres or mysql) in
> Clojure?
>
> Maybe the "Working with Java" chapter will be sufficient, but one of
> the benefits of Clojure is "batteries included", so helping folks get
> up to speed with a db example would be great.
>
> Brian
>
> >


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Patch: standalone compiler (almost)

[Stephen C. Gilardi]

On Nov 16, 2008, at 10:34 PM, Rich Hickey wrote:

> Since it only requires main, might I suggest you write this in  
> Clojure instead?

I gave that a try.

Here's a simple version of a driver for the compiler, stored in src/ 
clj/clojure/compile.clj:

(ns clojure.compile)

(defn main
  "Compiles libs into class files stored at compile-path.
  All args are strings"
  [compile-path & libs]
  (printf "Compiling %d libs to %s\n" (count libs) compile-path)
  (flush)
  (binding [*compile-path* compile-path]
(doseq [lib libs]
(compile (symbol lib)

It works when run from within the Clojure repl:

% ls build/classes/clojure/hello*
ls: build/classes/clojure/*hello*: No such file or directory
% java -cp clojure.jar:src/clj/ clojure.lang.Repl
Clojure
user=> (require 'clojure.compile)
nil
user=> (clojure.compile/main "build/classes" "clojure.hello")
Compiling 1 libs to build/classes
nil
user=>
% ls build/classes/clojure/hello*
build/classes/clojure/hello$main__8.class   build/classes/clojure/ 
hello.class

but when run as a standalone main, it gives an exception that appears  
to be related to static initializers:

% java -cp clojure.jar:src/clj/ clojure.compile build/classes  
clojure.hello
Compiling 1 libs to build/classes
Exception in thread "main" java.lang.IllegalStateException: Var null/ 
null is unbound. (hello.clj:3)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:4067)
at clojure.lang.Compiler.analyze(Compiler.java:3896)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:4050)
at clojure.lang.Compiler.analyze(Compiler.java:3896)
at clojure.lang.Compiler.access$100(Compiler.java:38)
at clojure.lang.Compiler$DefExpr$Parser.parse(Compiler.java:365)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:4060)
at clojure.lang.Compiler.analyze(Compiler.java:3896)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:4050)
at clojure.lang.Compiler.analyze(Compiler.java:3896)
at clojure.lang.Compiler.analyze(Compiler.java:3869)
at clojure.lang.Compiler.compile(Compiler.java:4498)
at clojure.lang.RT.compile(RT.java:408)
at clojure.lang.RT.load(RT.java:450)
at clojure.lang.RT.load(RT.java:422)
at clojure.core$load__4423$fn__4425.invoke(core.clj:3343)
at clojure.core$load__4423.doInvoke(core.clj:3342)
at clojure.lang.RestFn.invoke(RestFn.java:413)
at clojure.core$load_one__4386.invoke(core.clj:3189)
at clojure.core$compile__4429.invoke(core.clj:3347)
at clojure.compile$main__5162.doInvoke(compile.clj:23)
at clojure.lang.RestFn.invoke(RestFn.java:428)
at clojure.lang.Var.invoke(Var.java:323)
at clojure.lang.AFn.applyToHelper(AFn.java:195)
at clojure.lang.Var.applyTo(Var.java:436)
at clojure.compile.main(Unknown Source)
Caused by: java.lang.IllegalStateException: Var null/null is unbound.
at clojure.lang.Var.get(Var.java:129)
at clojure.lang.Compiler$FnExpr.parse(Compiler.java:2947)
at clojure.lang.Compiler.analyzeSeq(Compiler.java:4058)
... 25 more
%

For reference, here is the test compilee: src/clj/clojure/hello.clj:

(ns clojure.hello)

(defn main
  [greetee]
  (printf "Hello, %s wow\n" greetee)
  (flush))

I'd appreciate help in getting a standalone invocation of something  
like compile.clj above (i.e., using it's own main without Repl or  
Script) to work.

In working through this, I also found that a compiler driver written  
in Java may be preferable for use via build.xml because of a bootstrap  
problem. Until we compile (something like) "compile.clj", we can't  
call it as a standalone main. (One could add a step that builds the  
compiler driver via a clojure.lang.Script invocation.)

--Steve


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[mac]

On Nov 17, 4:52 am, Luc Prefontaine <[EMAIL PROTECTED]>
wrote:
> I never read anywhere in the documentation or in the user group that
> Clojure is a Common LISP implementation.
>
> Since it's existence, LISP has not gained a large acceptance in the
> commercial market compared to other "conventional" programming
> languages.
> I started to use it 28 years ago (UCI Lisp on a DEC10) and never crossed
> over it in my professional work except twice
> (ITA implemented their services in LISP and it is a big commercial
> success and another of my customer uses Scheme to implement
> some specialized algorithms).
> For a language that's been around for 50 years, it's at least annoying
> if not strange given the power of the language.
> Worse some companies have success stories using LISP but don't go public
> about it.
>
> Certainly, having "t" to represent the truth value instead of "true",
> using defun instead of defn or making an indigestion of parenthesis
> are not essential LISP features.
>
> Compromises at the syntax level are very small concessions to get LISP
> endorsed by a majority in the software community.
> The post fix notation is already a challenge (look back at people using
> HP calculators in the 70s/80s), so lets make things a bit easier for
> the non LISP programmer used to left-right assignments...
> Clojure is not a second citizen LISP because it implements a simplified
> syntax.
>
> You may need to start from a blank sheet if your Common Lisp knowledge
> interferes with your learning curve :)))
> Get Stuart's bookhttp://pragprog.com/titles/shcloj/programming-clojure
> and start from there.
> This should give you a clear vision of what Clojure is and is not.
>
> It's time for LISP to get a significant share of commercial success
> stories and the only way is to add some sex appeal to it to
> attract the masses. Considering that the software industry stagnates
> since the 1980s, it's a welcomed change.
>
> Personally, Clojure is the breath of fresh air I was waiting for. The
> reality is that most of my customers are using Java with
> thousands of code lines with pitiful results in terms of ROI. According
> to them, Java is the best gizmo on the market (including
> all the frameworks written around it), I think that Cobol had a better
> ROI than Java in many instances.
> Getting them away from Java is impossible to do but something like
> Clojure is an open door to a lot of significant applications,
> better ROI and better time to market schedules.
>
> I think that Clojure's main audience are these people drowning in this
> ocean of java code, not the LISP advocates :)))
>
> Luc
>
> On Sun, 2008-11-16 at 15:32 -0800, Dave Newton wrote:
> > I'll add that:
>
> > (cond (foo bar) (baz plugh)) => (cond (foo) (bar) (baz) (plugh))
>
> > This particular CL difference is listed on the wiki page you listed:
>
> >http://en.wikibooks.org/wiki/Clojure_Programming#Clojure_for_Common_L...
>
> > I also didn't have anywhere near these kinds of problems getting things to 
> > work, although I've been doing a lot of Java lately, and more Scheme than 
> > CL, so that may have helped.
>
> > I'm sure other folks would also be interested in your contributions towards 
> > a CL => Clojure document; sounds like a good opportunity.
>
> > Dave
>
> > --- On Sun, 11/16/08, Brian W <[EMAIL PROTECTED]> wrote:
> > > I'm going to assume this is serious and not a joke, but you do
> > > realize Clojure is already quite well documented at clojure.org?
>
> > > #t  t     =>     true
> > > define  defun  =>    defn
> > > car, cdr, caar, etc.   ~>  first, rest, ffirst, rrest,
> > > frest, rfirst
>
> > > arglists are vectors because [ ] stand out better
>
> > > On Nov 16, 2:31 pm, Simon Brooke
> > > <[EMAIL PROTECTED]> wrote:
> > > > Has anyone written a very simple introduction to
> > > Clojure for LISP
> > > > hackers? I've spend an evening playing with it
> > > pretty intensively, and
> > > > thus far I haven't got a thing to work. I've
> > > readhttp://en.wikibooks.org/wiki/Clojure_Programming#Clojure_for_Common_L...,
> > > > but it hasn't helped me.
>
> > > > In LISP:
>
> > > > * (defun fact (n) (cond ((= 1 n) 1)(t (* n (fact (- n
> > > 1))
> > > > FACT
> > > > * (fact 10)
> > > > 3628800
>
> > > > that is Common LISP, but what the hell; in Portable
> > > Standard LISP it
> > > > would have been identical except 'de' instead
> > > of 'defun'; in Scheme
> > > > it's a little different:
>
> > > > > (define (fact n) (cond ((= n 1) 1)(#t (* n (fact
> > > (- n 1))
> > > > > (fact 10)
>
> > > > 3628800
>
> > > > But the family resemblance is there... So, let's
> > > try it in Clojure:
>
> > > > user=> (defun fact (n) (cond ((= n 1) 1) (t (* n
> > > (fact (- n 1))
> > > > java.lang.Exception: Unable to resolve symbol: defun
> > > in this context
> > > > user=> (de fact (n) ( cond ((= n 1) 1) (t (* n
> > > (fact (- n 1))
> > > > java.lang.Exception: Unable to resolve symbol: de in
> > > this context
> > > > user=> (de

Re: recur in catch and finally?

[Rich Hickey]

On Nov 17, 2:06 am, mb <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On 17 Nov., 02:09, Chouser <[EMAIL PROTECTED]> wrote:
>
> > You could of course work around this by putting your loop in some
> > other function and calling it from inside catch.
>
> In this specific case I used:
> (last (take-while #(not (nil? %)) (iterate #(.getCause %) e)))
>
> However, a separate function would also work. That is not
> the point. One can work around it. But I try to follow the
> principle of least surprise as much as possible. So when
> valid looking code doesn't work for an obscure reason, this
> certainly is a surprise.
>
> I have no problem putting the loop into a dedicated function.
> Or find some equivalent way to express it. However then it
> should be documented somewhere, that this is actually
> necessary. ("for technical reasons loop/recur cannot be
> used in/at/for")

Yes, it's an arbitrary restriction (due to complexity) which I should
document.

Rich

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Strange behaviour

[Rich Hickey]

On Nov 17, 7:56 am, Konrad Hinsen <[EMAIL PROTECTED]> wrote:
> On Nov 17, 2008, at 13:33, mb wrote:
>
> > vals returns a clojure.lang.APersistentMap$ValSeq, which
> > is not a list. Hence list? returns false and you get the true
> > branch, ie. the thing itself.
>
> A. It looks like a list, but it isn't a list.
>
> > I know. It doesn't help much, but it shows, that you have to take
> > care to distinguish the abstraction vs. the specific implementation.
>
> That's fine with me in principle, but not if the language makes an
> effort to hide the implementation from me.
>
> A fix that works (at least for the examples I tried) is
>
> (defn replace-syms
> [sym-map expr]
> (let [replace #(replace-syms sym-map %)]
>(cond (contains? sym-map expr) (get sym-map expr)
> (vector? expr) (into [] (map replace expr))
> (map? expr) (into {} (map replace (seq expr)))
> (set? expr) (set (map replace expr))
> (seq? expr) (map #(replace-syms sym-map %) expr)
> :else expr)))
>
> I have moved the seq? test to the end just in case that one day
> vectors, sets, or maps implement the seq interface as well.
>

It's best to do this as generally as possible, building on something
like this:

(defn map-same [f coll]
  (let [ret (into (empty coll) (map f coll))]
(if (seq? coll)
  (reverse ret)
  ret)))

(map-same inc [1 2 3 4])
-> [2 3 4 5]
(map-same inc '(1 2 3 4))
-> (2 3 4 5)
(map-same inc (seq [1 2 3 4]))
-> (2 3 4 5)
(map-same inc #{1 2 3 4})
-> #{2 3 4 5}
(map-same (fn [[k v]] [k (inc v)]) {:a 1 :b 2 :c 3})
-> {:a 2, :c 4, :b 3}

Rich
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[Konrad Hinsen]

On Nov 17, 2008, at 13:56, Simon Brooke wrote:

> However, you're dead wrong about Lots of Irritating Stupid
> Parentheses. They are the heart of the language: the fact that it does
> not need any irregular syntax, because everything is regular.

For me, the heart of Lisp is that code is expressed in terms of data  
structures, i.e. that there is no separate syntax for code and data.  
Clojure respects that principle.

While it is true that Clojure's syntax is slightly less regular than  
other Lisps' in using both lists and vectors to define code, that is  
a minor issue for me, and my experience is that Clojure code is  
definitely easier to read than other Lisps because of this.

Of course, the only universally true statement about syntax is that  
it is a matter of taste...

Konrad.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[Simon Brooke]

On Nov 17, 3:52 am, Luc Prefontaine <[EMAIL PROTECTED]>
wrote:
> Since it's existence, LISP has not gained a large acceptance in the
> commercial market compared to other "conventional" programming
> languages.

This is true; I think, though, it's largely a fashion thing. In the
days when you and I learned LISP, LISP was inherently too big (and
played with too big ideas) for the computers most people used. Now we
have computers - hell, we have cellphones - which can actually run big
LISP systems effectively, but LISP is still out of fashion because
managers in IT - people our age - still think of it as 'too big' and
'too strange' (and the successor generations see it as 'too old').

> I started to use it 28 years ago (UCI Lisp on a DEC10) and never crossed
> over it in my professional work except twice

I started with Portable Standard LISP (on 32016 and later on the first
generation ARM) in 1984 and went onto InterLISP-D on Xerox Dandelion
(1108) and Daybreak (1186) before the ubiquitous but unlovely Common
LISP took over. I still think PSL (which had some faults) was the best
LISP I've used from the programmers point of view - elegant,
orthogonal, simple to use and simple to build things in (as an aside
both PSL and InterLISP were designed for in-core development and the
use of structure editors, both of which I see as very important to
ease and speed of development).

> For a language that's been around for 50 years, it's at least annoying
> if not strange given the power of the language.

Could not agree more.

> Certainly, having "t" to represent the truth value instead of "true",
> using defun instead of defn or making an indigestion of parenthesis
> are not essential LISP features.

I mostly agree with you about the names of functions. Willfully
changing things to make life difficult for people seems perverse, but
at the same time 't', 'car', 'cdr' and so on are historical accidents.
However, you're dead wrong about Lots of Irritating Stupid
Parentheses. They are the heart of the language: the fact that it does
not need any irregular syntax, because everything is regular. This
makes learning - after the initial 'where am I what the f*** is this'
phase - very simple and quick. Obviously, structure editors help...
which is why Common LISP makes them so bloody awkward to implement
(though Harlequin managed).

> Compromises at the syntax level are very small concessions to get LISP
> endorsed by a majority in the software community.

People have been saying that for fifty years, and those people have
been this: wrong. The SExpr notation was not LISP's original syntax -
it was adopted in preference to infix syntax because it works better.
InterLISP had an alternative 'conventional' syntax which looked like
an Algol family language - it was used so rarely I've forgotten what
it was called. Dylan was another LISP which used an Algol-like syntax
in an attempt to gain popularity. Where is Dylan now? And these are
only the best known of dozens - they've all failed, been lost in the
dustbins of history.. Arc is also following this path. I am convinced
it is a mistake.

Of course syntax is a sprinkling of sugar on the top of a language; of
course the same underlying semantics can be expressed in many
different syntaxes, and it is the semantics that matter. But SExprs
are the second most successful programming syntax after the Algol
family; and, as compared to Algol-derived languages (BCPL, Pascal, C,
Java, C#) the very regularity of SExprs and their lack of special
cases makes LISP relatively easy to learn.

> The post fix notation is already a challenge (look back at people using
> HP calculators in the 70s/80s), so lets make things a bit easier for
> the non LISP programmer used to left-right assignments...
> Clojure is not a second citizen LISP because it implements a simplified
> syntax.

But that is precisely my point. The syntax isn't simplified: it has
special cases /added/.

> You may need to start from a blank sheet if your Common Lisp knowledge
> interferes with your learning curve :)))
> Get Stuart's bookhttp://pragprog.com/titles/shcloj/programming-clojure
> and start from there.
> This should give you a clear vision of what Clojure is and is not.

I don't want to preserve Common LISP, heaven knows - Common LISP is a
perversely bad LISP variant. I was on the BSI LISP standardisation
committee at the time that Common LISP was going through and I was one
of several people who voted against, for a whole slew of reasons.
There is no reason to slavishly follow Common LISP.

> It's time for LISP to get a significant share of commercial success
> stories and the only way is to add some sex appeal to it to
> attract the masses. Considering that the software industry stagnates
> since the 1980s, it's a welcomed change.

Making a LISP which interoperates well with (and can leverage the
libraries of) Java or .Net is a big win. Some of the other stuff in
Clojure looks extremely interesting - I'm looking at con

Re: Strange behaviour

[Konrad Hinsen]

On Nov 17, 2008, at 13:33, mb wrote:

> vals returns a clojure.lang.APersistentMap$ValSeq, which
> is not a list. Hence list? returns false and you get the true
> branch, ie. the thing itself.

A. It looks like a list, but it isn't a list.

> I know. It doesn't help much, but it shows, that you have to take
> care to distinguish the abstraction vs. the specific implementation.

That's fine with me in principle, but not if the language makes an  
effort to hide the implementation from me.

A fix that works (at least for the examples I tried) is

(defn replace-syms
[sym-map expr]
(let [replace #(replace-syms sym-map %)]
   (cond (contains? sym-map expr) (get sym-map expr)
(vector? expr) (into [] (map replace expr))
(map? expr) (into {} (map replace (seq expr)))
(set? expr) (set (map replace expr))
(seq? expr) (map #(replace-syms sym-map %) expr)
:else expr)))

I have moved the seq? test to the end just in case that one day  
vectors, sets, or maps implement the seq interface as well.

Thanks for your quick reply,
   Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure.contrib.test-is changes

[Frantisek Sodomka]

Thanks Stuart!

It will certainly make writing tests more enjoyable :-)

Inspiration for :equal-pairs/each= came from the test framework I wrote  
for newLISP:
http://newlisp-on-noodles.org/wiki/index.php/Function_Testing

Tests there are written as each= with 2 exceptions:
'->' evaluates the next expression without testing it
'err' works as 'throws'

Function 'test-fn' evaluates tests and returns the list of results.  
Function 'print-test-fn' can take these results and just print them out.

Feel free to get inspired from it. If you see something nice, we can use  
it.

Frantisek

PS: newLISP is changing fast. Test framework was written for older version  
so many things might not work at this moment.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Strange behaviour

[mb]

Hi,

On 17 Nov., 13:05, Konrad Hinsen <[EMAIL PROTECTED]> wrote:
>         (defn replace-syms
>            [sym-map expr]
>            (let [replace #(replace-syms sym-map %)]
>               (cond (contains? sym-map expr) (get sym-map expr)
>                     (list? expr) (map #(replace-syms sym-map %) expr)
>                     (vector? expr) (into [] (map replace expr))
>                     (map? expr) (into {} (map replace (seq expr)))
>                     (set? expr) (set (map replace expr))
>                     true expr)))

vals returns a clojure.lang.APersistentMap$ValSeq, which
is not a list. Hence list? returns false and you get the true
branch, ie. the thing itself.

I tried the following approach, which also doesn't work, because
clojure.lang.PersistentHashMap$LeafNode does not return
something of a similar type or a vector when called with empty,
but a list. Hence the following doesn't work for maps. Note
also the annoying special case for the list...

(defn replace-syms
  [sym-map expr]
  (cond
(contains? sym-map expr) (sym-map expr)
(list? expr) (map #(replace-syms sym-map %) expr)
(coll? expr) (into (empty expr)
   (map #(replace-syms sym-map %)
expr))
:elseexpr))

I know. It doesn't help much, but it shows, that you have to take
care to distinguish the abstraction vs. the specific implementation.

Sincerely
Meikel


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Strange behaviour

[Konrad Hinsen]

Given the function

(defn replace-syms
   [sym-map expr]
   (let [replace #(replace-syms sym-map %)]
  (cond (contains? sym-map expr) (get sym-map expr)
(list? expr) (map #(replace-syms sym-map %) expr)
(vector? expr) (into [] (map replace expr))
(map? expr) (into {} (map replace (seq expr)))
(set? expr) (set (map replace expr))
true expr)))

and the definition

(def m {:a 1 :b :a})

I'd expect the results of

(replace-syms m (vals m))

and

(replace-syms m '(1 :a))

to be the same, but they aren't:

user=> (replace-syms m (vals m))
(1 :a)
user=> (replace-syms m '(1 :a))
(1 1)
user=> (= (vals m) '(1 :a))
true

Does anyone have an explanation?

Konrad.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[Dave Newton]

--- On Mon, 11/17/08, Simon Brooke wrote:
> I admit I started without reading the documentation, but having got
> stuck I then read the documentation - both that at Clojure.org and
> that in the Wikibook - carefully. It didn't help.

I just don't see how that's possible, since somehow I've managed to write 
programs using only the publicly-available documentation. Sure, I'd like it to 
be laid out and organized different. But I guess I'd have to argue that there's 
more than enough there to make significant progress in understanding Clojure.

> A list is a list is a list. Introducing irregularity for the 
> sake of has no benefit and only disbenefit.

IIRC one of the reasons given for that syntax was to reduce the number of 
parenthesis. Perhaps that's the reason (cond...) was implemented the way it was 
too; I don't really know.

Maybe Clojure isn't the Lisp for you: it's one thing to bring up a disagreement 
about how a language's syntax has been implemented, it's another (IMO) to 
*keep* bringing it up with the thought that there's only one way to do things. 
I don't like the argument/vector syntax either--but oh well. Not my language.

>From your other response:

> A programming construct which has remained unchanged for fifty
> years is almost certainly unchanged because it works.

That shouldn't imply that nothing *else* can work, though.

> But don't mess with COND!

It's already been "messed with"--move on!

> [...] my initial performance tests this morning impress me.

Never underestimate the abilities of the JVM: it's a pretty well-done JVM 
(except for a couple noticable issues, like the lack of tail recursion support. 
Another flaw may be corrected if invokedynamic or similar gets implemented in a 
shipping version.)

'Nuff said. It seems like our time could be better spent doing something else; 
the horse has been sufficiently beaten.

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
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

newbie swank problem

[brus]

Hope that someone will help me or clarify this problem:

- when I run example 2dplot.clj from command line it is compiled and
run
- but in emacs it never end with compiling

Here is my swank-clojure-cmd from emacs:
("java" "-server" "-classpath" "d:/tools/clojure/target/clojure-
lang-1.0-SNAPSHOT.jar;d:/tools/java/lib/gluegen-rt.jar;d:/tools/java/
lib/j3dcore.jar;d:/tools/java/lib/j3dutils.jar;d:/tools/java/lib/
jline-0.9.94.jar;d:/tools/java/lib/joalmixer.jar;d:/tools/java/lib/
jogl.jar;d:/tools/java/lib/vecmath.jar" "clojure.lang.Repl")
>From .emacs :

(setq swank-clojure-extra-classpaths (directory-files "d:/tools/java/
lib" t ".*.jar"))

thanks



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: thanks, errata, and one gaffe

[Brian Adkins]

Stuart:

I read through the table of contents. Are you planning on addressing
interacting with a database (preferably postgres or mysql) in
Clojure?

Maybe the "Working with Java" chapter will be sufficient, but one of
the benefits of Clojure is "batteries included", so helping folks get
up to speed with a db example would be great.

Brian

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: clojure.contrib.test-is changes

[Paul Drummond]

Hi Stuart,

Cool additions - I will certainly use them.

Regarding test-is additions, did you ever get a chance to check out the
patch I submitted a while back?

http://groups.google.com/group/clojure/browse_thread/thread/c509d589e181df1e/4319c02c9930d12e?lnk=gst&q=PATCH+test-is#4319c02c9930d12e

It was my first patch so appologies if there are some glaring errors or
bad-style in there (but it was a very simple addition so I'd hope not!).

I realised just after posting that catching Errors in the general case could
be viewed as a no-no because the JVM could be in an unstable state after the
Error (depending on which error was thrown) so the desired outcome would be
to terminate.  Is that your view?

For my particular scenario, I wanted test-is to support StackOverflowError.
I was working on a SICP exercise that caused StackOverflowErrors and I
wanted to have a test that passed when a StackOverflowError occurred, then
continue processing other tests.  So in my specific case, I felt the patch
made sense but maybe supporting *all* Errors is going to far?

Hmmm

Cheers,
Paul.

-- 
Iode Software Ltd, registered in England No. 6299803.

Registered Office Address: 12 Sancroft Drive, Houghton-le-Spring, Tyne &
Wear, DH5 8NE.

This message is intended only for the use of the person(s) ("the intended
recipient(s)") to whom it is addressed. It may contain information which is
privileged and confidential within the meaning of applicable law. If you are
not the intended recipient, please contact the sender as soon as possible.
The views expressed in this communication may not necessarily be the views
held by The Company.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[Simon Brooke]

On Nov 17, 7:43 am, "Howard Lewis Ship" <[EMAIL PROTECTED]> wrote:
> I generally like that Clojure dispenses with parens that exist for the
> benefit of the evaluator rather than the developer; thus far fewer
> parens when using (cond).  Still, my old Lisp habits (20 years without
> use) succumbed as much as Simons.  See my earlier thread about
> exception reporting.
>
> Could Clojure display errors like "seems like you're coding up some
> Common Lisp here"?

C'mon, guys. There are no excess params in COND, COND is regular.

(COND
  (condition value)
  (condition value)
  ...
  (condition value))

It's like that for good reason, and it's been like that since LISP 1.5
[1]. A programming construct which has remained unchanged for fifty
years is almost certainly unchanged because it works. This is
different from changing 'CAR' and 'CDR' to 'first' and 'rest' - our
computers no longer have decrement registers, so calling an important
function 'contents of the decrement register' is at best a geeky joke,
at worst obscurantism. I'll continue to prefer CAR and CDR because I'm
of that generation and that's what I'm used to, but it's unimportant.
Replacing the word 'lambda' with 'fn' bothers me more. 'Lambda' isn't
a piece of obscure history like CAR or CDR. It's a reminder that we're
implementing - however imperfectly - the lambda calculus. The
regularity of the language, however, is very important. If you want a
separate macro called IF then I have no objection - I shan't use it so
it doesn't worry me. But don't mess with COND!

Having said that my initial performance tests this morning impress me.
Factorial 1000 is a pretty poor test of overall performance but it's
one I've used for twenty-five years and it's still always the first
one I try. So

Clojure: user=> (time (fact 1000))
  "Elapsed time: 25.418373 msecs"
Armed Bear Common Lisp:  CL-USER(2): (time (fact 1000))
  0.093 seconds real time
  3998 cons cells
JScheme : fails to compute, fails to report an error!
CMUCL (non-JVM): * (time (fact 1000))
  ; Compiling LAMBDA NIL:
  ; Compiling Top-Level Form:

  ; Evaluation took:
  ;   0.02 seconds of real time
  ;   0.012 seconds of user run time
  ;   0.0 seconds of system run time
  ;   18,716,873 CPU cycles
  ;   0 page faults and
  ;   686,080 bytes consed.
Java [2] : 0.071 seconds elapsed

Now, this needs to be taken with a pinch of salt because I've timed
only a few runs with each system, and haven't formally averaged - the
above figures are typical figures for each system rather than strictly
averaged ones. GC could potentially throw the figures way out on any
of these systems. Nevertheless, what's interesting here is that
Clojure is nearly four times faster than Armed Bear, and three times
as fast as a (not exactly comparable) Java implementation. Clojure is
even reasonably competitive with CMUCL, which seems to me very
impressive.

It would be interesting (and in the next few days I may) code up some
of the benchmarks from http://shootout.alioth.debian.org/ in Clojure
and see how they compare against Java, ABCL and SBCL.


[1] Lisp 1.5 Programmers Manual, page 10, section 1.6; First published
1958.
[2] Java 6 in its default form can't compute factorial 1000
recursively because it runs out of stack, and clearly doesn't optimise
out the tail recursion - so you have to code it as iterative
explicitly. Java also can't move transparently between integers and
'BigIntegers', so you have to code that explicitly as well. The Java
implementation I used was:

public BigInteger bigFact( BigInteger n) {
BigInteger value = BigInteger.ONE;

for ( BigInteger i = BigInteger.ONE; i.compareTo(n) < 0; i = 
i.add
(BigInteger.ONE)) {
value = value.multiply(i);
}
return value;
}


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[Simon Brooke]

On Nov 16, 11:01 pm, Brian W <[EMAIL PROTECTED]> wrote:
> I'm going to assume this is serious and not a joke, but you do realize
> Clojure is already quite well documented at clojure.org?

I admit I started without reading the documentation, but having got
stuck I then read the documentation - both that at Clojure.org and
that in the Wikibook - carefully. It didn't help. I've been writing
LISP for half the history of the language, so I'm not exactly
unfamiliar with it.

> #t  t     =>     true
> define  defun  =>    defn
> car, cdr, caar, etc.   ~>  first, rest, ffirst, rrest, frest, rfirst
>
> arglists are vectors because [ ] stand out better

This is very badly missing the point. The point about LISP is that
(ideally at least) it is completely regular and orthogonal, with no
artificial syntax. A list is a list is a list. Introducing
irregularity for the sake of has no benefit and only disbenefit. If
arglists are vectors for some efficiency reason connected to the need
to integrate with Java, that's a good reason, and worth putting up
with. But if it's syntax for the sake of syntax, then that's just
counterproductive.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Clojure for LISP programmers....

[Jeff Rose]

I hope you are either 14 years old, or joking.  Rather than sitting down 
and attempting to conjure up perfect lines of a new programming language 
you have never used before, it might be good to spend some time reading! 
  Learning new things is good for your brain, and I can promise you 
Clojure will be especially good.   By the extreme laziness displayed in 
your email, maybe you would prefer watching the movies at 
http://clojure.blip.tv rather than reading documentation to get started, 
but it will be inevitable so you might as well dig in.  Just start at 
the top left of the homepage with rationale, and work your way down. 
You will not only be able to write some experiments that will be less 
frustrating, but you will also learn some pretty cool new stuff, one of 
the most profound being Clojure's pervasive support for concurrency. 
After that you should start reading code, lots of it.

-Jeff

Simon Brooke wrote:
> Has anyone written a very simple introduction to Clojure for LISP
> hackers? I've spend an evening playing with it pretty intensively, and
> thus far I haven't got a thing to work. I've read
> http://en.wikibooks.org/wiki/Clojure_Programming#Clojure_for_Common_Lisp_Programmers,
> but it hasn't helped me.
> 
> In LISP:
> 
> * (defun fact (n) (cond ((= 1 n) 1)(t (* n (fact (- n 1))
> FACT
> * (fact 10)
> 3628800
> 
> that is Common LISP, but what the hell; in Portable Standard LISP it
> would have been identical except 'de' instead of 'defun'; in Scheme
> it's a little different:
> 
>> (define (fact n) (cond ((= n 1) 1)(#t (* n (fact (- n 1))
>> (fact 10)
> 3628800
> 
> But the family resemblance is there... So, let's try it in Clojure:
> 
> user=> (defun fact (n) (cond ((= n 1) 1) (t (* n (fact (- n 1))
> java.lang.Exception: Unable to resolve symbol: defun in this context
> user=> (de fact (n) ( cond ((= n 1) 1) (t (* n (fact (- n 1))
> java.lang.Exception: Unable to resolve symbol: de in this context
> user=> (def fact (n) ( cond ((= n 1) 1) (t (* n (fact (- n 1))
> java.lang.Exception: Too many arguments to def
> user=> (defn fact [n] (cond ((= n 1) 1)(t (* n (fact (- n 1))
> java.lang.Exception: Unable to resolve symbol: t in this context
> user=> (defn fact [n](cond ((= n 1) 1)(#t  (* n (fact (- n 1))
> java.lang.Exception: No dispatch macro for: t
> user=> (defn fact [n](cond ((= n 1) 1)(#true (* n (fact (- n 1))
> java.lang.Exception: No dispatch macro for: t
> user=> (defn fact [n] (cond ((= n 1) 1)(true (* n (fact (- n 1))
> #'user/fact
> 
> OK, what's with the funny square brackets? A sequence of forms
> enclosed in square brackets is a vector, not a list. Why is the
> arglist for a function a vector? For now let's accept that it is, and
> pass on.
> 
> user=> (fact 10)
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to
> clojure.lang.IFn
> 
> OK, so that doesn't work. As Zaphod memorably put it, 'hey, what is
> truth, man?' Good question:
> 
> user=> (true? 'true)
> true
> user=> (true? true)
> true
> user=> (true? t)
> java.lang.Exception: Unable to resolve symbol: t in this context
> user=> (true? 't)
> false
> user=> (def t 'true)
> #'user/t
> user=> (true? t)
> true
> 
> OK, now we know the truth, surely we can write a valid fact?
> 
> user=> (defn fact [n] (cond ((= n 1) 1)('true (* n (fact (- n 1))
> #'user/fact
> user=> (fact 10)
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to
> clojure.lang.IFn
> user=> (defn fact [n] (cond ((= n 1) 1)((true? 'true) (* n (fact (- n
> 1))
> #'user/fact
> user=> (fact 10)
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to
> clojure.lang.IFn
> 
> OK, it looks like whatever's causing the break isn't the guard on the
> second cond branch. Let's for a moment try something that's purely
> boolean:
> 
> user=> (defn band [l] (cond ((nil? l) true)((true? (car l))(band (cdr
> l)
> java.lang.Exception: Unable to resolve symbol: cdr in this context
> 
> No CDR? It's LISP, but it can't fetch the contents of the decrement
> register? fifty years of LISP history tossed into the dirt. So if the
> CDR isn't called the CDR, what is it called (and what's the CDADR
> called)?
> 
> user=> (defn band [l] (cond ((nil? l) true)((true? (first l))(band
> (rest l)
> #'user/band
> user=> (band '(true true true))
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to
> clojure.lang.IFn
> 
> OK, can we write any function at all that works?
> 
> user=> (defn square [n] (* n n))
> #'user/square
> user=> (square 4)
> 16
> 
> Fine, so recurse up from that:
> 
> user=> (defn power [n m] (cond ((= m 0) 1)(true (* n (power n (- m
> 1))
> #'user/power
> user=> (power 2 2)
> java.lang.ClassCastException: java.lang.Boolean cannot be cast to
> clojure.lang.IFn
> 
> Aggghhh...
> 
> Getting LISP to work seamlessly inside a Java environment with easy
> intercalling between LISP and Java is a very big win, and potentially
> knocks things like JScheme and A

Re: Running Clojure scripts at the command line

[mb]

Hi,

On 17 Nov., 09:07, "Michael Wood" <[EMAIL PROTECTED]> wrote:
> #!/usr/bin/env java -cp /sq/ext/clojure/clojure.jar clojure.lang.Script

Most systems only allow one argument to the command.
scsh solved this issue with the special \ argument and
block comment #! ... !#

#! /usr/bin/scsh \
-m ore -o ptions -g o -h ere
!#

So when encountering a \ in the command-line options,
scsh reads the second line and parses it as additional
commandline args.

However, this leads to the usual problems with #! scripts:
hardcoded path, env hack doesn't work and the interpreter
(/usr/bin/scsh in this case) must not be a script itself!

Sincerely
Meikel


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---

Re: Running Clojure scripts at the command line

[Michael Wood]

Hi

On Sun, Nov 16, 2008 at 11:46 PM, Stephen C. Gilardi <[EMAIL PROTECTED]> wrote:
>
> On Nov 16, 2008, at 1:21 PM, Stuart Sierra wrote:
>
> I would like both the REPL and Script to be callable from the same main
> (), i.e. you should just be able to call java -jar clojure.jar without
> naming a class.  Default behavior would be to run a script, as with
> bash/perl/ruby, use a special command-line arg to run a REPL.  Or
> maybe imitate python, and run a REPL if there are no command-line
> args.  Either way is cool by me.
>
> If I have time today, I'll cook up some code for this.
>
> One canonical, flexible main sounds good to me too. I was mistaken about how
> things work now, though. With Rich's change today, the following already
> works as an executable script (hello.clj):

> #!/usr/bin/env java -cp /sq/ext/clojure/clojure.jar clojure.lang.Script
> (println "Hello, cores!")

> For me, that launches and runs in about 1.1 seconds of real time.
> Cool!

Using the shebang line like this is not portable.  See the following
post for details:

http://lists.freebsd.org/pipermail/freebsd-arch/2005-February/003525.html

To summarise the above post, on many operating systems if you ran a
script called scriptname.clj that started with the following shebang
line:

#!/usr/bin/env java -cp /sq/ext/clojure/clojure.jar clojure.lang.Script

it would be as if you had written:

$ /usr/bin/env "java -cp /sq/ext/clojure/clojure.jar
clojure.lang.Script" scriptname.clj

which would give you an error like:

/usr/bin/env: java -cp /sq/ext/clojure/clojure.jar
clojure.lang.Script: No such file or directory

I've just tried this on Linux with a 2.6 kernel and that's exactly what I got.

-- 
Michael Wood <[EMAIL PROTECTED]>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/clojure?hl=en
-~--~~~~--~~--~--~---