Re: Literate programming
Tim, I recall that at some point you described your setup for doing Clojure literate programming, and if I recall correctly, you were primarily working in LaTeX, relying on incremental compilation to test little snippets of code as you wrote them. Have there been any new developments on the literate programming / Clojure front, in terms of tools that leverage existing build tools, test suites, generating meaningful line numbers for stack traces and debugging? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
(dir *ns*) doesn't work??
Hi there, when I tried to execute "(dir *ns*)" in REPL, I found it doesn't work -- with exception of: Exception No namespace: *ns* found clojure.core/the-ns (core.clj:3689) I'm not sure if I used it the right way. Following are my execution tries: = Clojure 1.3.0 user=> (doc dir) - clojure.repl/dir ([nsname]) Macro Prints a sorted directory of public vars in a namespace nil user=> (dir *ns*) Exception No namespace: *ns* found clojure.core/the-ns (core.clj: 3689) user=> *ns* # user=> (the-ns *ns*) # user=> (the-ns 'user) # user=> = Any suggestions?? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (dir *ns*) doesn't work??
The dir macro is quite picky in what it accepts as arguments. Try: (dir user) (dir clojure.core) On Thu, Oct 27, 2011 at 10:57 AM, jaime wrote: > Hi there, when I tried to execute "(dir *ns*)" in REPL, I found it > doesn't work -- with exception of: > Exception No namespace: *ns* found clojure.core/the-ns > (core.clj:3689) > I'm not sure if I used it the right way. Following are my execution > tries: > = > Clojure 1.3.0 > user=> (doc dir) > - > clojure.repl/dir > ([nsname]) > Macro > Prints a sorted directory of public vars in a namespace > nil > user=> (dir *ns*) > Exception No namespace: *ns* found clojure.core/the-ns (core.clj: > 3689) > user=> *ns* > # > user=> (the-ns *ns*) > # > user=> (the-ns 'user) > # > user=> > = > Any suggestions?? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: (dir *ns*) doesn't work??
dir is a macro. It doesn't evaluate its arguments. So when you say (dir *ns*), Clojure sees: show me what's in the namespace named "*ns*", and there is no such namespace because *ns* is the name of a variable which contains the name of the current namespace. Dir is this way because for interactive use, it's convenient not to have to quote the symbol naming the namespace. So (dir user) and (dir clojure.core) should work. In your situation you'll want to call dir-fn, which is a function that will evaluate its arguments, so: if we assume (= *ns* 'user) (i.e. you're currently in the namespace "user") (dir-fn *ns*) is equivalent to (dir-fn 'user) and (dir user) HTH // Ben On Thu, Oct 27, 2011 at 10:57, jaime wrote: > Hi there, when I tried to execute "(dir *ns*)" in REPL, I found it > doesn't work -- with exception of: > Exception No namespace: *ns* found clojure.core/the-ns > (core.clj:3689) > I'm not sure if I used it the right way. Following are my execution > tries: > = > Clojure 1.3.0 > user=> (doc dir) > - > clojure.repl/dir > ([nsname]) > Macro > Prints a sorted directory of public vars in a namespace > nil > user=> (dir *ns*) > Exception No namespace: *ns* found clojure.core/the-ns (core.clj: > 3689) > user=> *ns* > # > user=> (the-ns *ns*) > # > user=> (the-ns 'user) > # > user=> > = > Any suggestions?? > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
appengine-magic, directory not found, strange file: hierarchy
Hi!
I recently upgraded my Linux distribution and while everything regarding
Clojure, Leiningen, Emacs and my project should be like it was before,
but I get the following error when trying to test my website project in
a browser:
---
HTTP ERROR 500
Problem accessing /. Reason:
Directory does not exist:
/media/sda4/app_engine/tlog-clj-gae/file:/usr/lib/jvm/java-6-openjdk/jre/lib/ext/pulse-java.jar!/../war
Caused by:
java.lang.Exception: Directory does not exist:
/media/sda4/app_engine/tlog-clj-gae/file:/usr/lib/jvm/java-6-openjdk/jre/lib/ext/pulse-java.jar!/../war
at ring.middleware.file$ensure_dir.invoke(file.clj:12)
at ring.middleware.file$wrap_file.doInvoke(file.clj:22)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at appengine_magic.core$wrap_war_static$fn__2337.invoke(core_local.clj:43)
at
appengine_magic.servlet$make_servlet_service_method$fn__1730.invoke(servlet.clj:99)
at appengine_magic.servlet$servlet$fn__1733.invoke(servlet.clj:108)
at
appengine_magic.servlet.proxy$javax.servlet.http.HttpServlet$0.service(Unknown
Source)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1166)
at
com.google.appengine.api.blobstore.dev.ServeBlobFilter.doFilter(ServeBlobFilter.java:58)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at
appengine_magic.core$make_appengine_request_environment_filter$reify__2351.doFilter(core_local.clj:74)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:923)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:547)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
---
/usr/lib/jvm/java-6-openjdk/jre/lib/ext/pulse-java.jar does exist and
has no specific relation to my project at all.
Afterwards, I find the following hierarchy added in my project dir:
/media/sda4/app_engine/tlog-clj-gae: tree file\:/
file:/
└── usr
└── lib
└── jvm
└── java-6-openjdk
└── jre
└── lib
└── ext
└── war
└── WEB-INF
└── appengine-generated
My project.clj:
---
(defproject tlog "0.3.0-SNAPSHOT"
:description "A blog for Google App Engine"
:repositories {"sonatype-oss-public"
"https://oss.sonatype.org/content/groups/public/"}
:dependencies [[org.clojure/clojure "1.3.0"]
[org.clojure/algo.monads "0.1.1-SNAPSHOT"]
[org.clojure/math.numeric-tower "0.0.1"]
[net.cgrand/moustache "1.0.0"]
[hiccup "0.3.6"]]
:dev-dependencies [[appengine-magic "0.4.6-SNAPSHOT"]])
---
Using Leiningen 1.6.1.1 on Java 1.6.0_23 OpenJDK 64-Bit Server VM,
swank-clojure plugin 1.3.2. Starting Jetty via appengine-magic's serve.
Any idea what's going on?
--
Thorsten Wilms
thorwil's design for free software:
http://thorwil.wordpress.com/
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: appengine-magic, directory not found, strange file: hierarchy
Hello Thorsten,
are you sure you used OpenJDK before the upgrade? I remember having
problems with OpenJDK + AppengineMagic which were resolved by switching to
Sun's JDK (this was on Ubuntu 10.04).
Cheers
Paul
On Thu, Oct 27, 2011 at 13:29, Thorsten Wilms wrote:
> Hi!
>
> I recently upgraded my Linux distribution and while everything regarding
> Clojure, Leiningen, Emacs and my project should be like it was before, but
> I get the following error when trying to test my website project in a
> browser:
>
> ---
> HTTP ERROR 500
>
> Problem accessing /. Reason:
>
> Directory does not exist: /media/sda4/app_engine/tlog-**
> clj-gae/file:/usr/lib/jvm/**java-6-openjdk/jre/lib/ext/**
> pulse-java.jar!/../war
>
> Caused by:
>
> java.lang.Exception: Directory does not exist: /media/sda4/app_engine/tlog-
> **clj-gae/file:/usr/lib/jvm/**java-6-openjdk/jre/lib/ext/**
> pulse-java.jar!/../war
> at ring.middleware.file$ensure_**dir.invoke(file.clj:12)
> at ring.middleware.file$wrap_**file.doInvoke(file.clj:22)
> at clojure.lang.RestFn.invoke(**RestFn.java:425)
> at appengine_magic.core$wrap_war_**static$fn__2337.invoke(core_**
> local.clj:43)
> at appengine_magic.servlet$make_**servlet_service_method$fn__**
> 1730.invoke(servlet.clj:99)
> at appengine_magic.servlet$**servlet$fn__1733.invoke(**servlet.clj:108)
> at
> appengine_magic.servlet.proxy$**javax.servlet.http.**HttpServlet$0.service(Unknown
> Source)
> at org.mortbay.jetty.servlet.**ServletHolder.handle(**
> ServletHolder.java:511)
> at org.mortbay.jetty.servlet.**ServletHandler$CachedChain.**
> doFilter(ServletHandler.java:**1166)
> at com.google.appengine.api.**blobstore.dev.ServeBlobFilter.**
> doFilter(ServeBlobFilter.java:**58)
> at org.mortbay.jetty.servlet.**ServletHandler$CachedChain.**
> doFilter(ServletHandler.java:**1157)
> at com.google.apphosting.utils.**servlet.**TransactionCleanupFilter.**
> doFilter(**TransactionCleanupFilter.java:**43)
> at org.mortbay.jetty.servlet.**ServletHandler$CachedChain.**
> doFilter(ServletHandler.java:**1157)
> at appengine_magic.core$make_**appengine_request_environment_**
> filter$reify__2351.doFilter(**core_local.clj:74)
> at org.mortbay.jetty.servlet.**ServletHandler$CachedChain.**
> doFilter(ServletHandler.java:**1157)
> at org.mortbay.jetty.servlet.**ServletHandler.handle(**
> ServletHandler.java:388)
> at org.mortbay.jetty.servlet.**SessionHandler.handle(**
> SessionHandler.java:182)
> at org.mortbay.jetty.handler.**ContextHandler.handle(**
> ContextHandler.java:765)
> at org.mortbay.jetty.handler.**ContextHandlerCollection.**handle(**
> ContextHandlerCollection.java:**230)
> at org.mortbay.jetty.handler.**HandlerWrapper.handle(**
> HandlerWrapper.java:152)
> at org.mortbay.jetty.Server.**handle(Server.java:326)
> at org.mortbay.jetty.**HttpConnection.handleRequest(**
> HttpConnection.java:542)
> at org.mortbay.jetty.**HttpConnection$RequestHandler.**
> headerComplete(HttpConnection.**java:923)
> at org.mortbay.jetty.HttpParser.**parseNext(HttpParser.java:547)
> at org.mortbay.jetty.HttpParser.**parseAvailable(HttpParser.**java:212)
> at org.mortbay.jetty.**HttpConnection.handle(**HttpConnection.java:404)
> at org.mortbay.jetty.bio.**SocketConnector$Connection.**
> run(SocketConnector.java:228)
> at org.mortbay.thread.**QueuedThreadPool$PoolThread.**
> run(QueuedThreadPool.java:582)
>
> ---
>
> /usr/lib/jvm/java-6-openjdk/**jre/lib/ext/pulse-java.jar does exist and
> has no specific relation to my project at all.
>
> Afterwards, I find the following hierarchy added in my project dir:
>
> /media/sda4/app_engine/tlog-**clj-gae: tree file\:/
> file:/
> └── usr
>└── lib
>└── jvm
>└── java-6-openjdk
>└── jre
>└── lib
>└── ext
>└── war
>└── WEB-INF
>└── appengine-generated
>
> My project.clj:
> ---
> (defproject tlog "0.3.0-SNAPSHOT"
> :description "A blog for Google App Engine"
> :repositories {"sonatype-oss-public" "https://oss.sonatype.org/**
> content/groups/public/
Re: (dir *ns*) doesn't work??
Oh yes you guys are right. I should have look at the source first: (defmacro dir "Prints a sorted directory of public vars in a namespace" [nsname] `(doseq [v# (dir-fn '~nsname)] (println v#))) from it, we can see the "quote" thing. Thank you all. I got it now! On Oct 27, 5:12 pm, Ben Smith-Mannschott wrote: > dir is a macro. It doesn't evaluate its arguments. So when you say > (dir *ns*), Clojure sees: show me what's in the namespace named > "*ns*", and there is no such namespace because *ns* is the name of a > variable which contains the name of the current namespace. > > Dir is this way because for interactive use, it's convenient not to > have to quote the symbol naming the namespace. So (dir user) and (dir > clojure.core) should work. > > In your situation you'll want to call dir-fn, which is a function that > will evaluate its arguments, so: > > if we assume (= *ns* 'user) (i.e. you're currently in the namespace "user") > (dir-fn *ns*) > is equivalent to > (dir-fn 'user) > and > (dir user) > > HTH > // Ben > > > > > > > > On Thu, Oct 27, 2011 at 10:57, jaime wrote: > > Hi there, when I tried to execute "(dir *ns*)" in REPL, I found it > > doesn't work -- with exception of: > > Exception No namespace: *ns* found clojure.core/the-ns > > (core.clj:3689) > > I'm not sure if I used it the right way. Following are my execution > > tries: > > = > > Clojure 1.3.0 > > user=> (doc dir) > > - > > clojure.repl/dir > > ([nsname]) > > Macro > > Prints a sorted directory of public vars in a namespace > > nil > > user=> (dir *ns*) > > Exception No namespace: *ns* found clojure.core/the-ns (core.clj: > > 3689) > > user=> *ns* > > # > > user=> (the-ns *ns*) > > # > > user=> (the-ns 'user) > > # > > user=> > > = > > Any suggestions?? > > > -- > > You received this message because you are subscribed to the Google > > Groups "Clojure" group. > > To post to this group, send email to clojure@googlegroups.com > > Note that posts from new members are moderated - please be patient with > > your first post. > > To unsubscribe from this group, send email to > > clojure+unsubscr...@googlegroups.com > > For more options, visit this group at > >http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: appengine-magic, directory not found, strange file: hierarchy
On 10/27/2011 02:45 PM, Paul Koerbitz wrote: are you sure you used OpenJDK before the upgrade? I remember having problems with OpenJDK + AppengineMagic which were resolved by switching to Sun's JDK (this was on Ubuntu 10.04). Switching to Oracle's version fixed it. I must have had it installed long before getting into Clojure, to then forget about it, on Ubuntu 10.04. Since there's apparently no package for 11.10, I followed http://www.webupd8.org/2011/09/how-to-install-oracle-java-7-jdk-in.html Thanks! -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ClojureScript and Counterclockwise?
Hi All - Do any of you happen to know if Counterclockwise supports the development of apps using ClojureScript? Thanks! Base -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Literate programming
On Thu, 2011-10-27 at 00:17 -0700, Mark Engelberg wrote: > Tim, > > I recall that at some point you described your setup for doing Clojure > literate programming, and if I recall correctly, you were primarily > working in LaTeX, relying on incremental compilation to test little > snippets of code as you wrote them. Yes, the idea is to write a literate version of Clojure, see http://daly.literatesoftware.com/clojure.pamphlet http://daly.literatesoftware.com/clojure.pdf similar in style to "Lisp in Small Pieces". (The effort has been stalled temporarily while I try to find new employment.) >From the above document you extract the Makefile, type 'make' and end up with the newly formatted PDF and a running REPL. So any edits to the document text are immediately reflected in the PDF and any edits to the code are immediately reflected in the compiled results. > > Have there been any new developments on the literate programming / > Clojure front, in terms of tools that leverage existing build tools, > test suites, generating meaningful line numbers for stack traces and > debugging? > The question is ill-posed in sense that literate programming is not a tool or technology but a change in mindset. To quote Knuth: I believe that the time is ripe for significantly better documentation of programs, and that we can best achieve this by considering programs to be works of literature. Hence, my title "Literate Programming". Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do. -- Donald Knuth "Literate Programming (1984) CSLI 1992 pg. 99 So imagine a world where the eloquence of Rich Hickey was expressed in book form. Imagine the whole immutability lecture written down and decorated with the actual running code as illustration. Imagine that the original authors clearly explained software transactional memory and illustrated it with the actual code. Imagine a discussion of argument destructuring with running code illustrations. How many more people would be able to dive into the details of Clojure to maintain and modify the code? How many people would find it much easier to understand prototypes, defrecords, macros, and all of the other struggles that populate the current email forums? How are infinite sequences supported and what code supports it? What does NIL mean and why was it defined that way? We do not capture the ideas. We do not rewrite the explanations to clarify the fine points of confusion. We do not illustrate how the ideas of Red-Black tries are moved "from ideas to implementation". We do not communicate the ideas to each other. We code for the machine. So we end up with the traditional "tree of sand" pile of little files. In order to overcome this we construct tools (IDEs) that know how to navigate this pile, tools to store the changes (SVN, git, hg), tools to put the sandpiles together (#include), tools to build guardrails, tools, tools, tools... (You can, of course, keep each chapter and section and subsection in separate files and "include" them in the book.) Now imagine that the "book" is multimedia where you can include animation (watch the tree balance), video, and a running REPL. Think Khan Academy for Clojure. This community is willing to overthrow the traditional ideas of lisp in order to make progress on a new path. Yet we continue to structure the development as though we worked on a PDP 11/40 with 4k file size limits. We continue to let the most valuable information which is the meat of Clojure disappear while we keep only the code, the bones of Clojure. Open the source code. Stare at it. Ask yourself if you understand exactly why it was needed, why it is structured that way, what would happen if you changed it and what else depends on this code. Imagine your job is to maintain and modify it but Rich is not available for questions and answers. Ultimately that is what matters. In the long term the code will be the only remaining artifact after Rich leaves the project. Look at Sourceforge and you will see thousands of dead projects that will never be picked up because they are just trees of code, dead code. Et tu, Clojure? Literate programming is about making code live. I like Clojure and I really want it to live. Think long term. Imagine a better way. Tim Daly -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
ultra-noob read-line question
At the REPL in Emacs, shouldn't the following code allow me to type something followed by [Enter] and then shouldn't it print my input back out? (println (read-line)) When I enter this at the prompt, I immediately see the following. It doesn't wait for input. user> (println (read-line)) nil nil user> I thought maybe it was a Windows ^M issue, but this happens in a Linux environment as well. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ultra-noob read-line question
On Thu, Oct 27, 2011 at 11:32 AM, Andrew wrote: > At the REPL in Emacs, shouldn't the following code allow me to type > something followed by [Enter] and then shouldn't it print my input back out? > (println (read-line)) > When I enter this at the prompt, I immediately see the following. It doesn't > wait for input. > user> (println (read-line)) > nil > nil > user> > I thought maybe it was a Windows ^M issue, but this happens in a Linux > environment as well. This is just a shortcoming of the way the JVM launches subprocesses; the stdin of the subprocesses aren't hooked up to the parent process. You should be able to get around it by using "lein trampoline repl" -Phil -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Literate programming
I would gladly pay for such a thing to materialize on my screen; if it only took money to get that, I'm sure we'd all be willing to finance such an effort however we can. On Thursday, October 27, 2011 1:58:52 PM UTC-4, TimDaly wrote: > > So imagine a world where the eloquence of Rich Hickey was expressed in > book form. Imagine the whole immutability lecture written down and > decorated with the actual running code as illustration. Imagine that > the original authors clearly explained software transactional memory > and illustrated it with the actual code. Imagine a discussion of > argument destructuring with running code illustrations. > > How many more people would be able to dive into the details of Clojure > to maintain and modify the code? How many people would find it much > easier to understand prototypes, defrecords, macros, and all of the > other struggles that populate the current email forums? How are > infinite sequences supported and what code supports it? What does > NIL mean and why was it defined that way? > > We do not capture the ideas. We do not rewrite the explanations to > clarify the fine points of confusion. We do not illustrate how the > ideas of Red-Black tries are moved "from ideas to implementation". > We do not communicate the ideas to each other. We code for the machine. > > ... > Now imagine that the "book" is multimedia where you can include > > animation (watch the tree balance), video, and a running REPL. > Think Khan Academy for Clojure. > > This community is willing to overthrow the traditional ideas of lisp > in order to make progress on a new path. Yet we continue to structure > the development as though we worked on a PDP 11/40 with 4k file size > limits. We continue to let the most valuable information which is the > meat of Clojure disappear while we keep only the code, the bones of > Clojure. > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Literate programming
Thank you for your persistence on this subject : I'm sure that I'm not the only lurker on this list that you manage to get interested in LP. I wanted to share two thought that I had when looking at your LP take on Clojure code : 1°) The infrsastructure should really lower the barrier to participation as wiki did for wikipedia. I gain some insight into the persistent data structures in Clojure implementation as I ported persistent vector to C++ : I wish I could just jump in and add that insight as a few paragraphs. Programs nowadays can be massive hence the need of collaborative developpement. A github account would be more appropriate imho that a http server. 2°) It was my understanding that Clojure implementation was both large and poised for some overhaul (Clojure in Clojure ?). On the other hand, I heard that Clojurescript implementation was damn small and maybe the experience carried from Clojure implementation means that its foundation will last : maybe it could be an opportunity for a LP project ? Best Regards, B PS: I'm seeing awsome potential in LP as a teaching tool ! I long for the day where I can direct my students to LP projects to help them understand the tought processes that went into great programs. On Oct 27, 7:58 pm, daly wrote: > On Thu, 2011-10-27 at 00:17 -0700, Mark Engelberg wrote: > > Tim, > > > I recall that at some point you described your setup for doing Clojure > > literate programming, and if I recall correctly, you were primarily > > working in LaTeX, relying on incremental compilation to test little > > snippets of code as you wrote them. > > Yes, the idea is to write a literate version of Clojure, > seehttp://daly.literatesoftware.com/clojure.pamphlethttp://daly.literatesoftware.com/clojure.pdf > similar in style to "Lisp in Small Pieces". (The effort has been > stalled temporarily while I try to find new employment.) > > Open the source code. Stare at it. Ask yourself if you understand > exactly why it was needed, why it is structured that way, what would > happen if you changed it and what else depends on this code. Imagine > your job is to maintain and modify it but Rich is not available for > questions and answers. > > Ultimately that is what matters. In the long term the code will be > the only remaining artifact after Rich leaves the project. Look at > Sourceforge and you will see thousands of dead projects that will > never be picked up because they are just trees of code, dead code. > Et tu, Clojure? > > Literate programming is about making code live. > I like Clojure and I really want it to live. > > Think long term. Imagine a better way. > > Tim Daly Thank you for your persistence on this subject : I'm sure that I'm not the only lurker on this list that you manage to get interested in LP. I wanted to share two thought that I had when looking at your LP take on Clojure code : 1°) The infrsastructure should really lower the barrier to participation as wiki did for wikipedia. I gain some insight into the persistent data structures in Clojure implementation as I ported persistent vector to C++ : I wish I could just jump in and add that insight as a few paragraphs. Programs nowadays can be massive hence the need of collaborative developpement. A github account would be more appropriate imho that a http server. 2°) It was my understanding that Clojure implementation was both large and poised for some overhaul (Clojure in Clojure ?). On the other hand, I heard that Clojurescript implementation was damn small and maybe the experience carried from Clojure implementation means that its foundation will last : maybe it could be an opportunity for a LP project ? Best Regards, B PS: I'm seeing awsome potential in LP as a teaching tool ! I long for the day where I can direct my students to LP projects to help them understand the tought processes that went into great programs. PS2: I'd be willing to help fund LP work on Clojure[Script], now that donations to Clojure are not possible anymore . -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ultra-noob read-line question
What does the exception below mean? Does trampoline require something to be defined/included that the usual way doesn't? Exception in thread "main" java.lang.IllegalArgumentException: No implementation of method: :make-writer of protocol: #'clojure.java.io/IOFactory found for class: nil (NO_SOURCE_FILE:0) at clojure.lang.Compiler.eval(Compiler.java:5440) at clojure.lang.Compiler.eval(Compiler.java:5391) at clojure.core$eval.invoke(core.clj:2382) at clojure.main$eval_opt.invoke(main.clj:235) at clojure.main$initialize.invoke(main.clj:254) at clojure.main$script_opt.invoke(main.clj:270) at clojure.main$main.doInvoke(main.clj:354) at clojure.lang.RestFn.invoke(RestFn.java:483) at clojure.lang.Var.invoke(Var.java:381) at clojure.lang.AFn.applyToHelper(AFn.java:180) at clojure.lang.Var.applyTo(Var.java:482) at clojure.main.main(main.java:37) Caused by: java.lang.IllegalArgumentException: No implementation of method: :make-writer of protocol: #'clojure.java.io/IOFactory found for class: nil at clojure.core$_cache_protocol_fn.invoke(core_deftype.clj:471) at clojure.java.io$fn__7420$G__7374__7427.invoke(io.clj:63) at clojure.java.io$writer.doInvoke(io.clj:113) at clojure.lang.RestFn.invoke(RestFn.java:411) at clojure.lang.AFn.applyToHelper(AFn.java:163) at clojure.lang.RestFn.applyTo(RestFn.java:133) at clojure.core$apply.invoke(core.clj:542) at clojure.core$spit.doInvoke(core.clj:5385) at clojure.lang.RestFn.invoke(RestFn.java:426) at leiningen.trampoline$write_trampoline.invoke(trampoline.clj:32) at leiningen.trampoline$trampoline.doInvoke(trampoline.clj:57) at clojure.lang.RestFn.invoke(RestFn.java:426) at clojure.lang.Var.invoke(Var.java:369) at clojure.lang.AFn.applyToHelper(AFn.java:165) at clojure.lang.Var.applyTo(Var.java:482) at clojure.core$apply.invoke(core.clj:542) at leiningen.core$apply_task.invoke(core.clj:228) at leiningen.core$_main.doInvoke(core.clj:294) at clojure.lang.RestFn.applyTo(RestFn.java:140) at clojure.core$apply.invoke(core.clj:542) at leiningen.core$_main.invoke(core.clj:297) at user$eval42.invoke(NO_SOURCE_FILE:1) at clojure.lang.Compiler.eval(Compiler.java:5424) ... 11 more -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Rides to the conj
Hi everyone, I haven't seen a lot of discussion about people organizing rides/roomshares etc for the conj so far, I hope this is an appropriate venue. Is anyone driving down from the DC area who could offer a ride down? I'll be flying out of Durham after the conj, but I can help with gas and driving on the way down. Also, I've currently got a room reserved at the Sheraton and might potentially be interested in finding a roommate. --Aaron -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: repl output for list seems inconsistent and a holdover from yesteryear
Hi!
Well [1 2 3] is just a syntaxic sugar for (vector 1 2 3):
=>(vector 1 2 3)
[1 2 3]
When you enter a vector in the repl, it is evaluted to itself. Here an
example that show it:
=>[1 2 (+ 1 2)]
[1 2 3]
And you can use the vector function for the same result:
=>(vector 1 2 (+ 1 2))
[1 2 3]
The quote prevent evaluation but this is not specific to lists:
=>'[1 2 (+ 1 2)]
[1 2 (+ 1 2)]
The way to make function calls in lisp (and in clojure) is to consider
the first element of the list to be the function, and the next one to
be the argument of the function. This what happen when you perform say
an addition
(+ 1 2) is a call to the add function with 2 parameters.
But this mean that you can't define a list (data structure) just by
writing it, because it will be evaluated. To prevent this, maybe the
best solution is to use the list function, that return a list with its
arguments.
=>(list 1 2 3)
(1 2 3)
You see the consistency here. As vectors are contructed with vector
function. Notice calling the list function is very different that
using a quote:
=>(list 1 2 (+ 1 2))
(1 2 3)
=>'(1 2 (+ 1 2))
(1 2 (+ 1 2))
This mean that you might not want to use quote everywhere just to say
'here is a list data structure'.
The preference for vectors as data structure when possible is to make
code more lisible. Using a list is just adding more parens, in a
language with lot of parens. Doesn't help the reading.
Using syntaxic sugar for vector, on the contrary help the reading.
On 27 oct, 01:08, e wrote:
> not necessarily.
>
> [1 2 3] is a vector that is not evaluated. Since there is no overload with
> things that are, there's no need for a special mark.
>
> '(1 2 3) is currently a way of say, "don't evaluate this list", but it could
> have been:
>
> '(1 2 3) is a list that is not evaluated. No loss of generality. it's a
> special type of list. One that's not evaluated. as opposed to a special
> indicator to the repl.
>
> On Wed, Oct 26, 2011 at 6:09 PM, Mark Rathwell wrote:
>
>
>
>
>
>
>
> > The point to think about here is that functions are also lists, the
> > same as your list of integers. The difference is that one is
> > evaluated, the other is not. That is what the quote is saying: "don't
> > evaluate me". The quote is not actually a part of the list. It's just
> > the way you tell the reader not to evaluate the list that follows.
>
> > So the question is should all unevaluated forms be preceded with a
> > quote in the repl output? To me that would be more confusing.
>
> > On Wed, Oct 26, 2011 at 5:34 PM, e wrote:
> > > long long time since I last looked a clojure, but I've never lost
> > > interest and I'm trying to find the time again.
>
> > > for the short version see "*INCONSISTENT*", in the example at the end.
>
> > > I know what the answer will be here. Something like "you will get
> > > used to it". or "it's not important". or "no one hardly uses lists
> > > anymore, anyway, since vectors are not purely contiguous". But, if
> > > you can make things better and it's easy, then why not?
>
> > > So here's the deal:
>
> > > I still think the following is only inconsistent because that's how it
> > > was in older lisps. Specifically, lists had to be quoted so the first
> > > argument wouldn't be called as a function. I asked long ago (here and
> > > in person) why, then regular functions couldn't require the quote so
> > > the paren could be reserved for the list data structure, and Rich
> > > answered that it'd simply be a pain to have to quote every function
> > > call. Well, my mind moves slowly. I'm just now realizing to ask,
> > > "Ok, then how about making the list really be defined using the single
> > > quote as part of it just like sets include the sharp to distinguish
> > > them from maps?". That's a much simpler explanation than saying, "you
> > > have to escape them, etc, etc." I realize this is a small matter since
> > > all I am talking about is how lists are represented as text.
>
> > > checking out the "Try Clojure":
>
> > > if you type the following, you get output that matches what you typed
> > > in every case except for lists.
>
> > > Vectors: --> [1 2 3 4]
> > > [1 2 3 4]
>
> > > Maps: --> {:foo "bar" 3 4}
> > > {:foo "bar" 3 4}
>
> > > Lists: --> '(1 2 3 4)
> > > (1 2 3 4) <- *INCONSISTENT* why not render this as '(1 2 3 4) ...
> > > this would make much more sense to newbies.
>
> > > Sets: --> #{1 2 3 4}
> > > #{1 2 3 4}
>
> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clojure@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with
> > your first post.
> > > To unsubscribe from this group, send email to
> > > clojure+unsubscr...@googlegroups.com
> > > For more options, visit this group at
> > >http://groups.google.com/group/clojure?hl=en
>
> > --
> > You received this message because you are subscribed to the Google
> >
Re: Clojure Conj extracurricular activities spreadsheet
On Tue Oct 25 14:10 2011, Roger Austin wrote: > One idea would be to organize something for people wanting to set up local > clojure meetups. I don't think this needs to be a BOF, but I don't know the > best > way to promote the idea. > > Anyone coming with family and/or spouse-dates? If so, let us locals know so > we can suggest some local activities. I will be joined by my wife and our toddler. I think she's planning on visiting some of the local museums while we're there, but I don't think she has any specific plans, yet. As far as things on the spreadsheet that interest me are: 1. core.logic/minikanren 2. Tooling BoF 3. Jamming with Overtone 4. Web and Clojure I'd like to propose a new activity: Android. It'd be more of a hack and chat about doing Android development in Clojure. Some things to talk about could include creating Clojure-friendly tools for Android development and perhaps the possibility of an Android contrib module. Thanks, Daniel Solano Gómez signature.asc Description: Digital signature
Re: repl output for list seems inconsistent and a holdover from yesteryear
On Oct 26, 2011 7:15 PM, "Stuart Halloway"
wrote:
>>
>> checking out the "Try Clojure":
>>
>> if you type the following, you get output that matches what you typed
>> in every case except for lists.
>>
>> Vectors: --> [1 2 3 4]
>> [1 2 3 4]
>>
>> Maps: --> {:foo "bar" 3 4}
>> {:foo "bar" 3 4}
>>
>> Lists: --> '(1 2 3 4)
>> (1 2 3 4) <- *INCONSISTENT* why not render this as '(1 2 3 4) ...
>> this would make much more sense to newbies.
>>
>> Sets: --> #{1 2 3 4}
>> #{1 2 3 4}
>
>
> This is an interesting question. Consistency is important, but consistency
with what? Your mental model for what happens at the REPL needs to keep the
R, E, and P steps clearly separate.
>
> Working backward: the P (Print) prints things in a way that they can be
read back, where possible:
>
> (read-string "[1 2 3 4]")
> => [1 2 3 4]
>
> (read-string "(1 2 3 4)")
> => (1 2 3 4)
>
> (read-string "#{1 2 3 4}")
> => #{1 2 3 4}
>
> (read-string "{1 2 3 4}")
> => {1 2, 3 4}
>
> If the P part of the REPL put a tick in front of lists, they would not
read back correctly:
>
> (read-string "'(1 2 3 4)")
> => (quote (1 2 3 4))< INCONSISTENT
>
I see the problem that token " ' " is already taken to be short hand for
"quote" so to be truly consistent, I might be compelled to argue that
(read-string "'(1 2 3 4)") should, seeing some hypothetical "list start"
multi-char token " '( " just like set-start is " #{ ", be: => '(1 2 3
4).
You'd need two single quotes: "''(1 2 3 4) to get "quote '(1 2 3 4)" ...
Wheras (1 2 3 4) means "call 1 with ..."
I'll have to reread the explanation about the repl phases, but maybe I'm
wondering if things don't have to be quoted if lists had the syntax I
describe, and requests for function invocation had a simple paren. Then you
are not saying, "treat this as data, do not eval". You are just saying,
"see my single quote paren token? That's for lists".
Maybe it would be clearer if I proposed some other, lesser-used chars, like
"%(1 2 3 4)" or even "<1 2 3 4>". That is, I'm not so much saying, "this
needs to be treated as data and not eval'd" as I am simply saying, "this is
the 'list' data structure as opposed to some other".
Now, if you ever need to read in a program and treat it like "data", well,
what structure would you like to put it in? A list? A vector? A string? This
is, indeed, where I am fuzzy on lisps, but it seems like you parse it as
desired and put it where/how you like it. Why is there an assumption that
code as data means code as lists? Or is there?
> Now to the R (Reader) part. If, as you suggest, the tick were part of the
reader syntax for lists, you could "fix" the inconsistency above:
>
> ;; hypothetical Clojure with '(...) list literals
> (read-string "' '(1 2 3 4)")
> => (1 2 3 4)
>
> Finally, consider the poor E (Evaluator) in this scenario. The evaluator
must (1) evaluate lists except (2) *not* evaluate lists that are protected
by quote. But now that the tick is part of the syntax you have two
challenges:
>
> (1) Since the tick no longer prevents evaluation, you have to spell out
the quote (and still use the tick!)
>
> ;; hypothetical literal list
> (quote '(1 2 3))
>
> (2) Since the tick is required as part of list syntax, your programs have
to be written with ticks everywhere like this:
>
> '(defn hello-world
> []
> '(println "hello")
>
> You have to understand R, E and P as separate steps to understand the
REPL.
>
> As a side note, it is worth mentioning that the REPL is composed of three
simple parts, and that interactive shells that do not have this factoring
are much less useful. Imagine if your language didn't separate reading and
evaluating. You would need JSON or something to serialize data...
>
> Stu
>
>
> Stuart Halloway
> Clojure/core
> http://clojure.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
Re: repl output for list seems inconsistent and a holdover from yesteryear
You can also use the list function if you don't care about syntactic sugar,
and it seems. Like it should look like this:
=> (list 1 2 3 4)
'(1 2 3 4)
or
<1 2 3 4> <-- although i'd use that for vectors and use [] for lists.
Wouldn't that be cool?
I imagine (set 1 2 3 4) prints as #{1 2 3 4}
On Oct 27, 2011 5:46 PM, "Nicolas" wrote:
> Hi!
>
> Well [1 2 3] is just a syntaxic sugar for (vector 1 2 3):
> =>(vector 1 2 3)
> [1 2 3]
>
> When you enter a vector in the repl, it is evaluted to itself. Here an
> example that show it:
> =>[1 2 (+ 1 2)]
> [1 2 3]
>
> And you can use the vector function for the same result:
> =>(vector 1 2 (+ 1 2))
> [1 2 3]
>
> The quote prevent evaluation but this is not specific to lists:
> =>'[1 2 (+ 1 2)]
> [1 2 (+ 1 2)]
>
> The way to make function calls in lisp (and in clojure) is to consider
> the first element of the list to be the function, and the next one to
> be the argument of the function. This what happen when you perform say
> an addition
> (+ 1 2) is a call to the add function with 2 parameters.
>
> But this mean that you can't define a list (data structure) just by
> writing it, because it will be evaluated. To prevent this, maybe the
> best solution is to use the list function, that return a list with its
> arguments.
> =>(list 1 2 3)
> (1 2 3)
>
> You see the consistency here. As vectors are contructed with vector
> function. Notice calling the list function is very different that
> using a quote:
> =>(list 1 2 (+ 1 2))
> (1 2 3)
> =>'(1 2 (+ 1 2))
> (1 2 (+ 1 2))
>
> This mean that you might not want to use quote everywhere just to say
> 'here is a list data structure'.
>
> The preference for vectors as data structure when possible is to make
> code more lisible. Using a list is just adding more parens, in a
> language with lot of parens. Doesn't help the reading.
>
> Using syntaxic sugar for vector, on the contrary help the reading.
>
> On 27 oct, 01:08, e wrote:
> > not necessarily.
> >
> > [1 2 3] is a vector that is not evaluated. Since there is no overload
> with
> > things that are, there's no need for a special mark.
> >
> > '(1 2 3) is currently a way of say, "don't evaluate this list", but it
> could
> > have been:
> >
> > '(1 2 3) is a list that is not evaluated. No loss of generality. it's a
> > special type of list. One that's not evaluated. as opposed to a special
> > indicator to the repl.
> >
> > On Wed, Oct 26, 2011 at 6:09 PM, Mark Rathwell >wrote:
> >
> >
> >
> >
> >
> >
> >
> > > The point to think about here is that functions are also lists, the
> > > same as your list of integers. The difference is that one is
> > > evaluated, the other is not. That is what the quote is saying: "don't
> > > evaluate me". The quote is not actually a part of the list. It's just
> > > the way you tell the reader not to evaluate the list that follows.
> >
> > > So the question is should all unevaluated forms be preceded with a
> > > quote in the repl output? To me that would be more confusing.
> >
> > > On Wed, Oct 26, 2011 at 5:34 PM, e wrote:
> > > > long long time since I last looked a clojure, but I've never lost
> > > > interest and I'm trying to find the time again.
> >
> > > > for the short version see "*INCONSISTENT*", in the example at the
> end.
> >
> > > > I know what the answer will be here. Something like "you will get
> > > > used to it". or "it's not important". or "no one hardly uses lists
> > > > anymore, anyway, since vectors are not purely contiguous". But, if
> > > > you can make things better and it's easy, then why not?
> >
> > > > So here's the deal:
> >
> > > > I still think the following is only inconsistent because that's how
> it
> > > > was in older lisps. Specifically, lists had to be quoted so the
> first
> > > > argument wouldn't be called as a function. I asked long ago (here
> and
> > > > in person) why, then regular functions couldn't require the quote so
> > > > the paren could be reserved for the list data structure, and Rich
> > > > answered that it'd simply be a pain to have to quote every function
> > > > call. Well, my mind moves slowly. I'm just now realizing to ask,
> > > > "Ok, then how about making the list really be defined using the
> single
> > > > quote as part of it just like sets include the sharp to distinguish
> > > > them from maps?". That's a much simpler explanation than saying,
> "you
> > > > have to escape them, etc, etc." I realize this is a small matter
> since
> > > > all I am talking about is how lists are represented as text.
> >
> > > > checking out the "Try Clojure":
> >
> > > > if you type the following, you get output that matches what you typed
> > > > in every case except for lists.
> >
> > > > Vectors: --> [1 2 3 4]
> > > > [1 2 3 4]
> >
> > > > Maps: --> {:foo "bar" 3 4}
> > > > {:foo "bar" 3 4}
> >
> > > > Lists: --> '(1 2 3 4)
> > > > (1 2 3 4) <- *INCONSISTENT* why not render this as '(1 2 3 4)
> ...
> > > > this would make much more sense to newbies.
> >
> > > > S
Re: repl output for list seems inconsistent and a holdover from yesteryear
On Oct 26, 2011, at 7:08 PM, e wrote: > [1 2 3] is a vector that is not evaluated. Since there is no overload with > things that are, there's no need for a special mark. If you type [1 2 3] into the REPL it is evaluated. The E part of the REPL always runs. Some expressions evaluate to themselves. In this case each number evaluates to itself and the vector evaluates to itself: user> [1 2 3] [1 2 3] If you have an expression as one of the items in the vector, it will be evaluated: user> [1 (+ 1 1) 3] [1 2 3] Putting a quote out front suppresses all evaluation: user> '[1 (+ 1 1) 3] [1 (+ 1 1) 3] > '(1 2 3) is currently a way of say, "don't evaluate this list", More completely it says, "don't evaluate the entire expression that follows including any and all sub-expressions" > but it could have been: > > '(1 2 3) is a list that is not evaluated. No loss of generality. it's a > special type of list. One that's not evaluated. as opposed to a special > indicator to the repl. Current behavior: user> '(1 (+ 1 1) 3) (1 (+ 1 1) 3) The behavior you propose: user> '(1 (+ 1 1) 3) (1 2 3) Currently 'x is equivalent to (quote x) for all values of x. With the syntax you propose that's no longer true. clojure.main/repl allows you to replace the evaluator with any function of one argument. If you bring up a repl with, say, lein repl, you can start a nested repl with identity as the evaluator and see how things are read (which can be interesting): % lein repl REPL started; server listening on localhost port 46512 user=> (clojure.main/repl :eval identity) user=> (+ 1 2) (+ 1 2) user=> '(+ 1 2) (quote (+ 1 2)) user=> [1 2 3] [1 2 3] user=> [1 (+ 1 1) 3] [1 (+ 1 1) 3] user=> 'x (quote x) user=> x x user=> '[1 (+ 1 1) 3] (quote [1 (+ 1 1) 3]) user=> #(+ 3 %) (fn* [p1__161#] (+ 3 p1__161#)) --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 Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: ClojureScript and Counterclockwise?
I run cljs_watch in a terminal window at the top of the project and I defined .cljs files to use the CCW editor. cljs_watch spots the changed .cljs files through Eclipse and recompiles on the fly. Then I refresh the browser. It does most of the job. Luc P. On Thu, 27 Oct 2011 10:27:29 -0700 (PDT) Base wrote: > Hi All - > > Do any of you happen to know if Counterclockwise supports the > development of apps using ClojureScript? > > Thanks! > > Base > -- Luc P. The rabid Muppet -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: repl output for list seems inconsistent and a holdover from yesteryear
> Maybe it would be clearer if I proposed some other, lesser-used chars, like
> "%(1 2 3 4)" or even "<1 2 3 4>". That is, I'm not so much saying, "this
> needs to be treated as data and not eval'd" as I am simply saying, "this is
> the 'list' data structure as opposed to some other".
A list data structure and a list code structure are the same. The
only difference is that the programmer decides when one should not be
evaluated. By creating separate syntax for a list data structure you
are in essence creating a different structure for lists of data than
lists of code, and you no longer have a straightforwardly homoiconic
language.
> Why is there an assumption that
> code as data means code as lists? Or is there?
This is the key to everything. Code is data, data is code, they are
the same structure. By treating a list of data (integers for example)
differently than a list of code (function and args), you create a
situation where code and data are no longer the same thing. That
trait is a fundamental trait of lisps, and makes things like macros
much simpler. You don't have to call the structure a list, you can
call it something else if you prefer, but whatever it is called, it
must be the same structure that defines code and defines data.
On Thu, Oct 27, 2011 at 6:58 PM, e wrote:
>
> On Oct 26, 2011 7:15 PM, "Stuart Halloway"
> wrote:
>>>
>>> checking out the "Try Clojure":
>>>
>>> if you type the following, you get output that matches what you typed
>>> in every case except for lists.
>>>
>>> Vectors: --> [1 2 3 4]
>>> [1 2 3 4]
>>>
>>> Maps: --> {:foo "bar" 3 4}
>>> {:foo "bar" 3 4}
>>>
>>> Lists: --> '(1 2 3 4)
>>> (1 2 3 4) <- *INCONSISTENT* why not render this as '(1 2 3 4) ...
>>> this would make much more sense to newbies.
>>>
>>> Sets: --> #{1 2 3 4}
>>> #{1 2 3 4}
>>
>>
>> This is an interesting question. Consistency is important, but consistency
>> with what? Your mental model for what happens at the REPL needs to keep the
>> R, E, and P steps clearly separate.
>>
>> Working backward: the P (Print) prints things in a way that they can be
>> read back, where possible:
>>
>> (read-string "[1 2 3 4]")
>> => [1 2 3 4]
>>
>> (read-string "(1 2 3 4)")
>> => (1 2 3 4)
>>
>> (read-string "#{1 2 3 4}")
>> => #{1 2 3 4}
>>
>> (read-string "{1 2 3 4}")
>> => {1 2, 3 4}
>>
>> If the P part of the REPL put a tick in front of lists, they would not
>> read back correctly:
>>
>> (read-string "'(1 2 3 4)")
>> => (quote (1 2 3 4)) < INCONSISTENT
>>
>
> I see the problem that token " ' " is already taken to be short hand for
> "quote" so to be truly consistent, I might be compelled to argue that
> (read-string "'(1 2 3 4)") should, seeing some hypothetical "list start"
> multi-char token " '( " just like set-start is " #{ ", be: => '(1 2 3
> 4).
>
> You'd need two single quotes: "''(1 2 3 4) to get "quote '(1 2 3 4)" ...
> Wheras (1 2 3 4) means "call 1 with ..."
>
> I'll have to reread the explanation about the repl phases, but maybe I'm
> wondering if things don't have to be quoted if lists had the syntax I
> describe, and requests for function invocation had a simple paren. Then you
> are not saying, "treat this as data, do not eval". You are just saying,
> "see my single quote paren token? That's for lists".
>
> Maybe it would be clearer if I proposed some other, lesser-used chars, like
> "%(1 2 3 4)" or even "<1 2 3 4>". That is, I'm not so much saying, "this
> needs to be treated as data and not eval'd" as I am simply saying, "this is
> the 'list' data structure as opposed to some other".
>
> Now, if you ever need to read in a program and treat it like "data", well,
> what structure would you like to put it in? A list? A vector? A string? This
> is, indeed, where I am fuzzy on lisps, but it seems like you parse it as
> desired and put it where/how you like it. Why is there an assumption that
> code as data means code as lists? Or is there?
>
>> Now to the R (Reader) part. If, as you suggest, the tick were part of the
>> reader syntax for lists, you could "fix" the inconsistency above:
>>
>> ;; hypothetical Clojure with '(...) list literals
>> (read-string "' '(1 2 3 4)")
>> => (1 2 3 4)
>>
>> Finally, consider the poor E (Evaluator) in this scenario. The evaluator
>> must (1) evaluate lists except (2) *not* evaluate lists that are protected
>> by quote. But now that the tick is part of the syntax you have two
>> challenges:
>>
>> (1) Since the tick no longer prevents evaluation, you have to spell out
>> the quote (and still use the tick!)
>>
>> ;; hypothetical literal list
>> (quote '(1 2 3))
>>
>> (2) Since the tick is required as part of list syntax, your programs have
>> to be written with ticks everywhere like this:
>>
>> '(defn hello-world
>> []
>> '(println "hello")
>>
>> You have to understand R, E and P as separate steps to understand the
>> REPL.
>>
>> As a side note, it is worth mentioning that the REPL is composed of three
>> simple parts, and that
Extending IFn
I'm experimenting with creating my own fn types. I was wondering if there was a better way of extending IFn than this: https://gist.github.com/1321330 Is there a more idiomatic way? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Clojure Conj extracurricular activities spreadsheet
Please sign me up for ClojureScript, Heroku Drinkup, and the Web and Clojure. Another thing I would be interested in hearing about and discussing is development techniques with Clojure and ClojureScript. What practices people are using and finding that work best for them. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Is there a String protocol?
Eh, I'm more interested in the int/long/double protocol, and was asking about the string one as a matter of completeness. NumberClass/parseNumber doesn't take a broad range of inputs, yadda yadda yadda... On Oct 25, 5:06 pm, Ben Smith-Mannschott wrote: > On Tue, Oct 25, 2011 at 14:45, Sean Devlin wrote: > > I was wondering if there was a common protocol to get a string > > representation of an object yet. Also, are there common protocols for > > ints, doubles, chars, etc? Having just spent a lot of time writing > > Python, having an int function that worked on both Strings and Ints > > was great. I'd love to be able to use a protocol for this. > > What do you need the string for? Just for presentation (like __str__), > or are you hoping to be able to parse it back in again (like > __repr__)? > > (pr-str x) will produce a string representation of x which you can > convert back to Clojure data using (read-string s) provided x was > composed only of things that are representable as Clojure literals > (lists, vectors, maps, sets, keywords, strings, symbols, numbers, > chars). > > The behavior of pr and friends is not defined in a protocol, as such, > but rather by the multimethods print-method and print-dup. I suppose > one could add behavior for ones own types, but this would be of > limited utility since read and friends won't know how to read these > representations back in. > > (str x) produces a string for presentation. This is not necessarily > something that can be read back in. > > This is not defined by a protocol, as such, but rather by overriding > the toString(), which all Java classes provide. > > // Ben -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
modern clojure summary
Hi, I took a look at clojure when it first came out. I never wrote many programs with it but spent a few nights reading docs and experimenting with the repl. In Rich's most recent talk, "Simple Made Easy," he mentioned that clojure for javascript was built from the ground up using protocols and other modern clojure constructs. Is there a resource which describes clojure using modern concepts, rather than introducing feature as they were added in a chronological order? I'm a Java programmer and am not looking to switch languages completely. I am, however, interested in understanding the essence of clojure and the software engineering ideas and biases contained within it (similar to how Rich, himself, probably studied Haskell to get good ideas). Thanks -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: modern clojure summary
You're probably best suited with "Clojure for Java programmers", it covers a lot of basic stuff & fundamental motivation. http://blip.tv/clojure/clojure-for-java-programmers-1-of-2-989128 On Oct 27, 9:10 pm, falcon wrote: > Hi, > I took a look at clojure when it first came out. I never wrote many > programs with it but spent a few nights reading docs and experimenting with > the repl. > > In Rich's most recent talk, "Simple Made Easy," he mentioned that clojure > for javascript was built from the ground up using protocols and other > modern clojure constructs. > > Is there a resource which describes clojure using modern concepts, rather > than introducing feature as they were added in a chronological order? > > I'm a Java programmer and am not looking to switch languages completely. I > am, however, interested in understanding the essence of clojure and the > software engineering ideas and biases contained within it (similar to how > Rich, himself, probably studied Haskell to get good ideas). > > Thanks -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: modern clojure summary
Looks like this video is from 2008. I remember going through all the videos back then. I'm not looking for a basic introduction to lisp like languages. I'm interested in a description and an explanation of clojure + modern features such as protocols. For example, Rich said that clojurescript doesn't implement some older features. If Rich thinks some newer features are more general/powerful than older features, then I'd like to learn the newer features. I'm basically interested in clojure as an amature programming language enthusiast. Ideally I'd like a two page summary of lambda calculus + clojure building blocks, but this is not lambda-the-ultimate.org :) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Literate programming
I'm a bit reluctant to get into this, because I'm new to clojure (and don't know the backstory of this post), but an old hand at literate programming (I recently did a podcast interview with Donald Knuth on LP). I'll be interested in the results of your survey. Larry On Wed, Oct 26, 2011 at 3:06 PM, wrote: > I see that my Literate Programming session is beginning to gain some > traction. I would encourage you to bring examples. We can discuss the > merits and possibly gain some new insights. If nothing else, please > sign up for the Literate Software session at Clojure-Conj. I promise > to keep it short. > > Literate programming can take various forms. I am working on a survey > of literate software. I came across an interesting non-latex example > worth sharing: > > http://jashkenas.github.com/coffee-script/documentation/docs/nodes.html > > Notice how well they have documented an apparently simple line as in: > > exports.Base = class Base > > The Base is an abstract base class for all nodes in the syntax tree. > Each subclass implements the compileNode method, which performs the > code generation for that node. To compile a node to JavaScript, call > compile on it, which wraps compileNode in some generic extra smarts, > to know when the generated code needs to be wrapping up in a > closure. An options hash is passed and cloned throughout, containing > information about the environment from higher in the tree (such as > if a returned value is being requested by the surrounding function), > information about the current scope, and indentation level. > > Notice how this is not only giving trivial information (e.g. Base is > an abstract base class) but WHY it exists (..as a base for all nodes in > the syntax tree). It gives operational information (to compile a node..) > as well as information about the effect (..which wraps...). It shows > how global information is used (An options hash..) and WHY (containing > information about the environment...) > > Code only tells you HOW something is done at the time it is done. > It's like having a recipe without an idea what you would make. > > If our standards of documentation were raised to this level then large > systems like Axiom, Clojure, and ClojureScript would be much easier to > maintain and modify in the long term. > > If you want your code to live beyond you, make it literate. > > Tim Daly > d...@literatesoftware.com > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- *Off the Beaten Path in Technology http://otbeatenpath.wordpress.com * -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Literate programming
Programming pearls: a literate program http://www.cs.tufts.edu/~nr/cs257/archive/don-knuth/pearls-1.pdf On Wed, Oct 26, 2011 at 10:49 PM, jaime wrote: > is there a place introducing (e.g. overview) more about Literate? have > no ideas about this stuff. > > On Oct 27, 3:06 am, d...@axiom-developer.org wrote: >> I see that my Literate Programming session is beginning to gain some >> traction. I would encourage you to bring examples. We can discuss the >> merits and possibly gain some new insights. If nothing else, please >> sign up for the Literate Software session at Clojure-Conj. I promise >> to keep it short. >> >> Literate programming can take various forms. I am working on a survey >> of literate software. I came across an interesting non-latex example >> worth sharing: >> >> http://jashkenas.github.com/coffee-script/documentation/docs/nodes.html >> >> Notice how well they have documented an apparently simple line as in: >> >> exports.Base = class Base >> >> The Base is an abstract base class for all nodes in the syntax tree. >> Each subclass implements the compileNode method, which performs the >> code generation for that node. To compile a node to JavaScript, call >> compile on it, which wraps compileNode in some generic extra smarts, >> to know when the generated code needs to be wrapping up in a >> closure. An options hash is passed and cloned throughout, containing >> information about the environment from higher in the tree (such as >> if a returned value is being requested by the surrounding function), >> information about the current scope, and indentation level. >> >> Notice how this is not only giving trivial information (e.g. Base is >> an abstract base class) but WHY it exists (..as a base for all nodes in >> the syntax tree). It gives operational information (to compile a node..) >> as well as information about the effect (..which wraps...). It shows >> how global information is used (An options hash..) and WHY (containing >> information about the environment...) >> >> Code only tells you HOW something is done at the time it is done. >> It's like having a recipe without an idea what you would make. >> >> If our standards of documentation were raised to this level then large >> systems like Axiom, Clojure, and ClojureScript would be much easier to >> maintain and modify in the long term. >> >> If you want your code to live beyond you, make it literate. >> >> Tim Daly >> d...@literatesoftware.com > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
clojurescript: generating the JavaScript on the fly?
Hi, Suppose there is a ajax request comes to the server. The server code process it and then send some JavaScript codes as the response. Could clojurescript be using in the case? For example, given a string representing the Clojurescript code, then build it into Javascript codes in the memeory, then the codes are send back to the client as the response. Thanks! Guofeng -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Literate programming
My two favorite articles on Literate Programming are both from Donald Knuth's book *Literate Programming*. One is "Computer Programming as an Art", and the other is "Literate Programming". When I was preparing to interview Knuth a bit over a year ago I re-read the entire book. I expected it to be a somewhat outdated description of WEB, TANGLE, and WEAVE. On the contrary it was wonderfully timeless. When I mentioned that to Knuth he sort of grumbled something to the effect of "Well, yes, some things in computer science have a long shelf life" (that's a paraphrase, but it was something like that). I haven't been working with it for awhile, but I did a somewhat primitive modification to the XML Docbook markup language (I just added a few appropriate tags for "tangling" the executable source code, and "weaving" the well formatted article documenting the code) which I used as the source language, then wrote a tangle and weave in perl. I got the idea from Norman Walsh's article Literate Programming in XML which can be found at http://nwalsh.com/docs/articles/xml2002/lp/paper.html The advantage of this was that given the array of tools for rendering Docbook "weaving" was a piece of cake, and perl had a good range of modules for doing the "tangle". As I stated, I'm very new to clojure, but I've always been fascinated with LP, and I'm very happy to see this discussion going on here. Larry On Wed, Oct 26, 2011 at 10:49 PM, jaime wrote: > is there a place introducing (e.g. overview) more about Literate? have > no ideas about this stuff. > > On Oct 27, 3:06 am, d...@axiom-developer.org wrote: > > I see that my Literate Programming session is beginning to gain some > > traction. I would encourage you to bring examples. We can discuss the > > merits and possibly gain some new insights. If nothing else, please > > sign up for the Literate Software session at Clojure-Conj. I promise > > to keep it short. > > > > Literate programming can take various forms. I am working on a survey > > of literate software. I came across an interesting non-latex example > > worth sharing: > > > > http://jashkenas.github.com/coffee-script/documentation/docs/nodes.html > > > > Notice how well they have documented an apparently simple line as in: > > > > exports.Base = class Base > > > > The Base is an abstract base class for all nodes in the syntax tree. > > Each subclass implements the compileNode method, which performs the > > code generation for that node. To compile a node to JavaScript, call > > compile on it, which wraps compileNode in some generic extra smarts, > > to know when the generated code needs to be wrapping up in a > > closure. An options hash is passed and cloned throughout, containing > > information about the environment from higher in the tree (such as > > if a returned value is being requested by the surrounding function), > > information about the current scope, and indentation level. > > > > Notice how this is not only giving trivial information (e.g. Base is > > an abstract base class) but WHY it exists (..as a base for all nodes in > > the syntax tree). It gives operational information (to compile a node..) > > as well as information about the effect (..which wraps...). It shows > > how global information is used (An options hash..) and WHY (containing > > information about the environment...) > > > > Code only tells you HOW something is done at the time it is done. > > It's like having a recipe without an idea what you would make. > > > > If our standards of documentation were raised to this level then large > > systems like Axiom, Clojure, and ClojureScript would be much easier to > > maintain and modify in the long term. > > > > If you want your code to live beyond you, make it literate. > > > > Tim Daly > > d...@literatesoftware.com > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- *Off the Beaten Path in Technology http://otbeatenpath.wordpress.com * -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Literate programming
On Thu, 2011-10-27 at 20:11 -0400, Larry Johnson wrote: > My two favorite articles on Literate Programming are both from Donald > Knuth's book Literate Programming. One is "Computer Programming as an > Art", and the other is "Literate Programming". When I was preparing > to interview Knuth a bit over a year ago I re-read the entire book. I > expected it to be a somewhat outdated description of WEB, TANGLE, and > WEAVE. On the contrary it was wonderfully timeless. When I mentioned > that to Knuth he sort of grumbled something to the effect of "Well, > yes, some things in computer science have a long shelf life" (that's a > paraphrase, but it was something like that). Knuth's invention of literate programming is one of the unrecognized pearls of computer science. I have yet to see a programming team that has an Editor-in-Chief who does patch-review for clarity, sentence structure, punctuation, relevance, location in the book, proper citations and index terms, etc. Maybe someday. > > I haven't been working with it for awhile, but I did a somewhat > primitive modification to the XML Docbook markup language (I just > added a few appropriate tags for "tangling" the executable source > code, and "weaving" the well formatted article documenting the code) > which I used as the source language, then wrote a tangle and weave in > perl. I got the idea from Norman Walsh's article Literate Programming > in XML which can be found at > http://nwalsh.com/docs/articles/xml2002/lp/paper.html > > The advantage of this was that given the array of tools for rendering > Docbook "weaving" was a piece of cake, and perl had a good range of > modules for doing the "tangle". Any means of publication can be the medium for literate programming. As I rule I prefer Latex but anything will do. All you need is a distinguished means of quoting and naming the chunks. In html this could be as simple as: your code and you need a program, often called "tangle", to extract the chunk tangle mywebpage.html somename >mysomename.file The machinery of literate programming is dirt simple. Poof! You're done. The hardest part of literate programming is the mindset. In order to do literate programming you need to change your focus from traditional programming to writing for humans and, as a side effect, writing for the machine. > > As I stated, I'm very new to clojure, but I've always been fascinated > with LP, and I'm very happy to see this discussion going on here. Java has taken the PDP 11/40 sand files to their logical extreme where we have wired the name of the tiny file to the name of the tiny object. We have packaged the automobile into a crate with labeled bags of screws, hoses, switches, etc. and are expected to understand the car. Clojure is a very early adoptive, open minded community willing to challenge old assumptions. It helps to highlight what those old assumptions are, as Rich has done for Lisp, since they can be difficult to see and hard to displace. I am hoping the community will disrupt the tiny-files, javadoc, IDE, code-for-the-machine, mindset and start communicating with humans. Rich has great ideas in Clojure and all we get is the dried bones of source code. We can do so much better. Tim Daly -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: Literate programming
I've found org-mode in emacs quite acceptable for literate programming in clojure. http://orgmode.org/ git://orgmode.org/org-mode.git Here are some things I've used it for: http://aurellem.com/abomination/html/no_parens.html http://aurellem.com/pokemon-types/html/lpsolve.html http://aurellem.com/thoughts/html/man-years.html It's possible to automatically monitor the org files in a project, regenerate the html and source code whenever they are changed, and get a very tight write-debug-test cycle. Try it out it's fun! sincerely, --Robert McIntyre On Thu, Oct 27, 2011 at 8:52 PM, daly wrote: > > > On Thu, 2011-10-27 at 20:11 -0400, Larry Johnson wrote: > > My two favorite articles on Literate Programming are both from Donald > > Knuth's book Literate Programming. One is "Computer Programming as an > > Art", and the other is "Literate Programming". When I was preparing > > to interview Knuth a bit over a year ago I re-read the entire book. I > > expected it to be a somewhat outdated description of WEB, TANGLE, and > > WEAVE. On the contrary it was wonderfully timeless. When I mentioned > > that to Knuth he sort of grumbled something to the effect of "Well, > > yes, some things in computer science have a long shelf life" (that's a > > paraphrase, but it was something like that). > > Knuth's invention of literate programming is one of the unrecognized > pearls of computer science. I have yet to see a programming team that > has an Editor-in-Chief who does patch-review for clarity, sentence > structure, punctuation, relevance, location in the book, proper > citations and index terms, etc. Maybe someday. > > > > > I haven't been working with it for awhile, but I did a somewhat > > primitive modification to the XML Docbook markup language (I just > > added a few appropriate tags for "tangling" the executable source > > code, and "weaving" the well formatted article documenting the code) > > which I used as the source language, then wrote a tangle and weave in > > perl. I got the idea from Norman Walsh's article Literate Programming > > in XML which can be found at > > http://nwalsh.com/docs/articles/xml2002/lp/paper.html > > > > The advantage of this was that given the array of tools for rendering > > Docbook "weaving" was a piece of cake, and perl had a good range of > > modules for doing the "tangle". > > Any means of publication can be the medium for literate programming. > As I rule I prefer Latex but anything will do. > > All you need is a distinguished means of quoting and naming the > chunks. In html this could be as simple as: > > your code > > and you need a program, often called "tangle", to extract the chunk > tangle mywebpage.html somename >mysomename.file > > The machinery of literate programming is dirt simple. > Poof! You're done. > > The hardest part of literate programming is the mindset. > > In order to do literate programming you need to change your focus > from traditional programming to writing for humans and, as a side > effect, writing for the machine. > > > > > As I stated, I'm very new to clojure, but I've always been fascinated > > with LP, and I'm very happy to see this discussion going on here. > > Java has taken the PDP 11/40 sand files to their logical extreme where > we have wired the name of the tiny file to the name of the tiny object. > We have packaged the automobile into a crate with labeled bags of > screws, hoses, switches, etc. and are expected to understand the car. > > Clojure is a very early adoptive, open minded community willing to > challenge old assumptions. It helps to highlight what those old > assumptions are, as Rich has done for Lisp, since they can be > difficult to see and hard to displace. I am hoping the community > will disrupt the tiny-files, javadoc, IDE, code-for-the-machine, > mindset and start communicating with humans. Rich has great ideas > in Clojure and all we get is the dried bones of source code. > > We can do so much better. > > Tim Daly > > > > > > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: repl output for list seems inconsistent and a holdover from yesteryear
On Thu, Oct 27, 2011 at 7:42 PM, Stephen C. Gilardi wrote: > > On Oct 26, 2011, at 7:08 PM, e wrote: > > > [1 2 3] is a vector that is not evaluated. Since there is no overload > with things that are, there's no need for a special mark. > > If you type [1 2 3] into the REPL it is evaluated. The E part of the REPL > always runs. Some expressions evaluate to themselves. In this case each > number evaluates to itself and the vector evaluates to itself: > > user> [1 2 3] > [1 2 3] > > If you have an expression as one of the items in the vector, it will be > evaluated: > > user> [1 (+ 1 1) 3] > [1 2 3] > > Putting a quote out front suppresses all evaluation: > > user> '[1 (+ 1 1) 3] > [1 (+ 1 1) 3] > > > '(1 2 3) is currently a way of say, "don't evaluate this list", > > More completely it says, "don't evaluate the entire expression that follows > including any and all sub-expressions" > > > but it could have been: > > > > '(1 2 3) is a list that is not evaluated. No loss of generality. it's a > special type of list. One that's not evaluated. as opposed to a special > indicator to the repl. > > Current behavior: > > user> '(1 (+ 1 1) 3) > (1 (+ 1 1) 3) > > The behavior you propose: user> '(1 (+ 1 1) 3) > (1 2 3) > > ^ excellent explanation right above. +1 > Currently 'x is equivalent to (quote x) for all values of x. With the > syntax you propose that's no longer true. > > clojure.main/repl allows you to replace the evaluator with any function of > one argument. If you bring up a repl with, say, lein repl, you can start a > nested repl with identity as the evaluator and see how things are read > (which can be interesting): > > % lein repl > REPL started; server listening on localhost port 46512 > user=> (clojure.main/repl :eval identity) > user=> (+ 1 2) > (+ 1 2) > user=> '(+ 1 2) > (quote (+ 1 2)) > user=> [1 2 3] > [1 2 3] > user=> [1 (+ 1 1) 3] > [1 (+ 1 1) 3] > user=> 'x > (quote x) > user=> x > x > user=> '[1 (+ 1 1) 3] > (quote [1 (+ 1 1) 3]) > user=> #(+ 3 %) > (fn* [p1__161#] (+ 3 p1__161#)) > > --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 > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
core.match 0.2.0-alpha6, breaking change for or patterns
The biggest change is the removal of the infix or pattern syntax. Feedback appreciated. Fixes * MATCH-34: no more infix or pattern syntax * MATCH-10: support maps with keys of heterogenous types * MATCH-30: throw if same binding name used in row * MATCH-33: fix readme typo Enhancements * supported flattened syntax for :when and :as * added Steve Miner's match-let -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
Re: repl output for list seems inconsistent and a holdover from yesteryear
On Thu, Oct 27, 2011 at 8:26 PM, Mark Rathwell wrote:
> > Maybe it would be clearer if I proposed some other, lesser-used chars,
> like
> > "%(1 2 3 4)" or even "<1 2 3 4>". That is, I'm not so much saying, "this
> > needs to be treated as data and not eval'd" as I am simply saying, "this
> is
> > the 'list' data structure as opposed to some other".
>
> A list data structure and a list code structure are the same.
why wasn't vector chosen for code?
> The
> only difference is that the programmer decides when one should not be
> evaluated. By creating separate syntax for a list data structure you
> are in essence creating a different structure for lists of data than
> lists of code, and you no longer have a straightforwardly homoiconic
> language.
>
This seems like a hugely important thing for me to grock, but it is easier
to grock in languages that, say, ONLY have lists. Otherwise it seems like
code is arbitrarily ONE of the data structures and, therefore is NOT
homoiconic with respect to any other data structure.
>
> > Why is there an assumption that
> > code as data means code as lists? Or is there?
>
> This is the key to everything. Code is data
yes, fine. but "data" doesn't always mean list in *my* mind. But I'm
starting to get that it was chosen to be the same thing in lisps.
> , data is code, they are
> the same structure. By treating a list of data (integers for example)
> differently than a list of code (function and args), you create a
> situation where code and data are no longer the same thing.
no. code and lists are no longer the same thing. I see "data" as a generic
concept . . .a superset, not a different set. code could be "data" that I
haven't picked a data structure for, yet.
> That
> trait is a fundamental trait of lisps, and makes things like macros
> much simpler.
I suspected this, too. ok.
> You don't have to call the structure a list, you can
> call it something else if you prefer, but whatever it is called, it
> must be the same structure that defines code and defines data.
But, again, there are plenty of structures that define "data" differently
then that which was chosen for code. So why not just have a "code
structure". Again, it already seems broken with respect to other
structures. Here's some "data". It's a vector. Here's *more* data. It's a
chunk of code. Ah but it was arbitrarily decided (more from history and
evolution) that *that* data is a list. Broken.
>
>
> On Thu, Oct 27, 2011 at 6:58 PM, e wrote:
> >
> > On Oct 26, 2011 7:15 PM, "Stuart Halloway"
> > wrote:
> >>>
> >>> checking out the "Try Clojure":
> >>>
> >>> if you type the following, you get output that matches what you typed
> >>> in every case except for lists.
> >>>
> >>> Vectors: --> [1 2 3 4]
> >>> [1 2 3 4]
> >>>
> >>> Maps: --> {:foo "bar" 3 4}
> >>> {:foo "bar" 3 4}
> >>>
> >>> Lists: --> '(1 2 3 4)
> >>> (1 2 3 4) <- *INCONSISTENT* why not render this as '(1 2 3 4) ...
> >>> this would make much more sense to newbies.
> >>>
> >>> Sets: --> #{1 2 3 4}
> >>> #{1 2 3 4}
> >>
> >>
> >> This is an interesting question. Consistency is important, but
> consistency
> >> with what? Your mental model for what happens at the REPL needs to keep
> the
> >> R, E, and P steps clearly separate.
> >>
> >> Working backward: the P (Print) prints things in a way that they can be
> >> read back, where possible:
> >>
> >> (read-string "[1 2 3 4]")
> >> => [1 2 3 4]
> >>
> >> (read-string "(1 2 3 4)")
> >> => (1 2 3 4)
> >>
> >> (read-string "#{1 2 3 4}")
> >> => #{1 2 3 4}
> >>
> >> (read-string "{1 2 3 4}")
> >> => {1 2, 3 4}
> >>
> >> If the P part of the REPL put a tick in front of lists, they would not
> >> read back correctly:
> >>
> >> (read-string "'(1 2 3 4)")
> >> => (quote (1 2 3 4))< INCONSISTENT
> >>
> >
> > I see the problem that token " ' " is already taken to be short hand for
> > "quote" so to be truly consistent, I might be compelled to argue that
> > (read-string "'(1 2 3 4)") should, seeing some hypothetical "list start"
> > multi-char token " '( " just like set-start is " #{ ", be: => '(1 2
> 3
> > 4).
> >
> > You'd need two single quotes: "''(1 2 3 4) to get "quote '(1 2 3 4)" ...
> > Wheras (1 2 3 4) means "call 1 with ..."
> >
> > I'll have to reread the explanation about the repl phases, but maybe I'm
> > wondering if things don't have to be quoted if lists had the syntax I
> > describe, and requests for function invocation had a simple paren. Then
> you
> > are not saying, "treat this as data, do not eval". You are just saying,
> > "see my single quote paren token? That's for lists".
> >
> > Maybe it would be clearer if I proposed some other, lesser-used chars,
> like
> > "%(1 2 3 4)" or even "<1 2 3 4>". That is, I'm not so much saying, "this
> > needs to be treated as data and not eval'd" as I am simply saying, "this
> is
> > the 'list' data structure as opposed to some other".
> >
> > Now, if you ever need to read in a program and t
Re: repl output for list seems inconsistent and a holdover from yesteryear
I think I understand more now though, everyone. Thanks. clojure chose
lists for the data structure for code so lists sort of have a special place
in the language.
Thanks again.
On Fri, Oct 28, 2011 at 1:13 AM, e wrote:
>
>
> On Thu, Oct 27, 2011 at 8:26 PM, Mark Rathwell wrote:
>
>> > Maybe it would be clearer if I proposed some other, lesser-used chars,
>> like
>> > "%(1 2 3 4)" or even "<1 2 3 4>". That is, I'm not so much saying,
>> "this
>> > needs to be treated as data and not eval'd" as I am simply saying, "this
>> is
>> > the 'list' data structure as opposed to some other".
>>
>> A list data structure and a list code structure are the same.
>
>
> why wasn't vector chosen for code?
>
>
>> The
>> only difference is that the programmer decides when one should not be
>> evaluated. By creating separate syntax for a list data structure you
>> are in essence creating a different structure for lists of data than
>> lists of code, and you no longer have a straightforwardly homoiconic
>> language.
>>
> This seems like a hugely important thing for me to grock, but it is easier
> to grock in languages that, say, ONLY have lists. Otherwise it seems like
> code is arbitrarily ONE of the data structures and, therefore is NOT
> homoiconic with respect to any other data structure.
>
>
>>
>> > Why is there an assumption that
>> > code as data means code as lists? Or is there?
>>
>> This is the key to everything. Code is data
>
> yes, fine. but "data" doesn't always mean list in *my* mind. But I'm
> starting to get that it was chosen to be the same thing in lisps.
>
>
>> , data is code, they are
>> the same structure. By treating a list of data (integers for example)
>> differently than a list of code (function and args), you create a
>> situation where code and data are no longer the same thing.
>
> no. code and lists are no longer the same thing. I see "data" as a generic
> concept . . .a superset, not a different set. code could be "data" that I
> haven't picked a data structure for, yet.
>
>
>> That
>> trait is a fundamental trait of lisps, and makes things like macros
>> much simpler.
>
> I suspected this, too. ok.
>
>
>
>> You don't have to call the structure a list, you can
>> call it something else if you prefer, but whatever it is called, it
>> must be the same structure that defines code and defines data.
>
> But, again, there are plenty of structures that define "data" differently
> then that which was chosen for code. So why not just have a "code
> structure". Again, it already seems broken with respect to other
> structures. Here's some "data". It's a vector. Here's *more* data. It's a
> chunk of code. Ah but it was arbitrarily decided (more from history and
> evolution) that *that* data is a list. Broken.
>
>
>
>>
>>
>> On Thu, Oct 27, 2011 at 6:58 PM, e wrote:
>> >
>> > On Oct 26, 2011 7:15 PM, "Stuart Halloway"
>> > wrote:
>> >>>
>> >>> checking out the "Try Clojure":
>> >>>
>> >>> if you type the following, you get output that matches what you typed
>> >>> in every case except for lists.
>> >>>
>> >>> Vectors: --> [1 2 3 4]
>> >>> [1 2 3 4]
>> >>>
>> >>> Maps: --> {:foo "bar" 3 4}
>> >>> {:foo "bar" 3 4}
>> >>>
>> >>> Lists: --> '(1 2 3 4)
>> >>> (1 2 3 4) <- *INCONSISTENT* why not render this as '(1 2 3 4) ...
>> >>> this would make much more sense to newbies.
>> >>>
>> >>> Sets: --> #{1 2 3 4}
>> >>> #{1 2 3 4}
>> >>
>> >>
>> >> This is an interesting question. Consistency is important, but
>> consistency
>> >> with what? Your mental model for what happens at the REPL needs to keep
>> the
>> >> R, E, and P steps clearly separate.
>> >>
>> >> Working backward: the P (Print) prints things in a way that they can
>> be
>> >> read back, where possible:
>> >>
>> >> (read-string "[1 2 3 4]")
>> >> => [1 2 3 4]
>> >>
>> >> (read-string "(1 2 3 4)")
>> >> => (1 2 3 4)
>> >>
>> >> (read-string "#{1 2 3 4}")
>> >> => #{1 2 3 4}
>> >>
>> >> (read-string "{1 2 3 4}")
>> >> => {1 2, 3 4}
>> >>
>> >> If the P part of the REPL put a tick in front of lists, they would not
>> >> read back correctly:
>> >>
>> >> (read-string "'(1 2 3 4)")
>> >> => (quote (1 2 3 4))< INCONSISTENT
>> >>
>> >
>> > I see the problem that token " ' " is already taken to be short hand for
>> > "quote" so to be truly consistent, I might be compelled to argue that
>> > (read-string "'(1 2 3 4)") should, seeing some hypothetical "list start"
>> > multi-char token " '( " just like set-start is " #{ ", be: => '(1 2
>> 3
>> > 4).
>> >
>> > You'd need two single quotes: "''(1 2 3 4) to get "quote '(1 2 3 4)" ...
>> > Wheras (1 2 3 4) means "call 1 with ..."
>> >
>> > I'll have to reread the explanation about the repl phases, but maybe I'm
>> > wondering if things don't have to be quoted if lists had the syntax I
>> > describe, and requests for function invocation had a simple paren. Then
>> you
>> > are not saying, "treat this as data, do not eval". You are just saying,
>> > "see my single quote
