Clojure Poll 09/2008
Rich Hickey
be a good time to conduct another poll:
What are you doing with Clojure?
What 3 features would you most like to see added next?
Thanks,
Rich
Allen Rohner
> What are you doing with Clojure?
clustering )
> What 3 features would you most like to see added next?
2. better stack traces (maybe a "clojure-only" mode that only prints
the lines in the stack trace that are clojure files (or non-clojure
compiler files). Then have a verbose setting that includes the path
through the compiler. When in verbose mode, not have java print
"here's some of the stack, and 100 other lines that I'm not going to
show you"
Finally, not that I'm asking you or anyone else to build this, I'm
just throwing this out there to see if anyone else is thinking along
the same lines as me :-). I think it would be really cool to build a
database in Clojure. SQL the language sucks, and the overhead of
sending SQL strings to a remote process and having it compile the
command sucks. Allow the database to live inside the user process (for
small datasets), and make the interface the same whether the DB is in-
processs or an external process.
Start out simple, with just a b-tree library and a serializing data
structures library. Clojure already supports transactions and thread
isolation. In the future, build a query language (lisp DSL of course!)
and add support for remote eval i.e. send an sexp over a socket to a
remote JVM.
Allen
Rastislav Kassak
>
> As we rapidly approach 500 members on the group (!) I thought it would
> be a good time to conduct another poll:
>
>
> What are you doing with Clojure?
Nothing ATM, not enough time. :)
>
>
> What 3 features would you most like to see added next?
1> Simple easy-to-use but powerfull instant web application framework
like rails back in 2005(?). One tarball with included web/app server,
shell scripts and default configuration.
2> Eye catching screencast intro showing fast blog/wiki/whatever
application build-up from scratch.
3> TextMate macros, maybe I'll finally buy it if it will have clojure
support. :)
I know, these are not clojure features but some framework build on
clojure, but in fact, (1) and (2) were the issues which introduced me
into ruby.
I knew there is some ruby and it's just another python/perl/etc. 10
min screencast changed my experience in programming languages, even I
didn't know the term "DSL".
And clojure is much more powerfull as ruby, IMHO.
Excuse me, if there are already such packages and screencasts for any
clojure based web framework out there.
I'm not able to read all mails in this list. :)
PS> It could be any other interesting domain, not just web framework.
Swing, data manipulation, distributed/concurrent computing, SOA
orchestration. Here especially I'm searching for lightweight ESB/BPEL
alternative instead of enterprise solutions.
It's just these web things are very popular now and easy to understand
for most people.
>
>
>
> Thanks,
>
> Rich
> >
>
Rastislav Kassak
was mentioning. :)
noahr
where I work, which is quite exciting. (Until my permission to do so
gets revoked, of course).
That's also why I'll no doubt be spamming the list with so many
questions :p
The application will be of the server-side message dispatch variety,
being the controller piece between a bunch of incoming and outgoing
messages and protocols that 'do things' (UI eents, payment processes,
turning on/off services, etc etc)
I haven't yet used the language enough for me to consider my own
'wishlist' of any merit, since I have so many newbie-obstacles to
overcome (but am just now getting to the point where I can actually
get stuff done). I will send some items later though as they occur to
me and seem decent. There is a real advantage to working on a real
project, in that it makes you need to do real things, whether the
tools are there or not.
Two things that do stand out to me still are:
1)
Lack of good 'newbie' information. (This isn't really what you asked
for, nor do I need it as much now as I did) This isn't a knock
against the language of course, but will hinder its general
acceptance. In particular I've found that while the learning curve
for understanding the basic ideas is low, the curve for actually doing
stuff in practice is steep. There are many subtle nuances that have to
be understood, and many things you initially try to do are the 'wrong
way' etc. And I was a lisp lover *before* I started. Once you make it
through this initial period it really starts to click, but I'm afraid
many would-be newcomers will quit after struggling to get parenthesis
just right or seeing a cryptic error.
2)
Any advances in the error handling / reporting would be greatly
beneficial. Sometimes you see in the nasty stacktrace the actual
'problem' or 'clojure line of text' that is the culprit, but many
times you do not. This can be kept in check with super-incremental
development, which is a good idea anyway, because you just know that
the last 'whatever u did' broke it, regardless of what it says. But I
would suggest in general better means to tie error messages to actual
errors in clojure text, though I realize that is probably quite
difficult to do.
Some *possibilities* for new language features (not necessarily my top
list):
1. Not a good way to READ from a string, I hit this as working on an
REPL loop that feeds from a stream. In particular this would be needed
if you wanted to do some string parsing / alteration BEFORE the EVAL
(for example, adding the parenthesis automatically to the edges). I
agree working with the data structures directly as opposed to strings
is better when possible, but when the data is dynamic and incoming you
dont have that option. But I realize this has been brought up before,
and also you could read from a reader from a string, etc. On a similar
note, I suspect being able to convert between data structures and
string representations of those structures, might allow for some neat
unanticipated tricks to be performed. This just seems to be a natural
& easy thing to provide since the language is already reflective and
dynamic by nature.
2.
Would there be any need for more reflective type operations? Like
'what file am I in' (which I would have already used, but just as a
reload-convenience feature), or perhaps 'what higher level functions
am I in', etc. I haven't really hit a need for these yet, and I
suspect the lispy nature of it all already mitigates this a bit, but
again seems like it might be easy to provide.
3.
I'm curious about several of the cool lispy things that did NOT make
it in, though I understand some of these have been discussed already,
and there are good reasons or jvm obstacles for it. In particular I am
thinking of the lisp error handling retry stuff, and continuations (we
dont have those, right?). I have personal experience with neither,
however, so can't comment much. Also, aren't there several types of
macros in lisp, reader macros, and others? You said something about
the read table not being accessible in the api docs, so naturally that
made me wonder what cool things could be done if it were..
4.
I also wonder if there will be language problems as applications scale
larger, with many different files and namespaces. I've noticed
functions can only refer to those previously defined, so you couldnt
have 2 that depend on one another. Again, unsure if this is needed,
but it stood out to me. Also it seems I need to specifically load each
file from other files, as opposed to some sort of directory / package
mechanism. I'm wondering how that will scale on a large project, and
what about the case where multiple files each have the same dependent,
etc, like C++ includes.
5.
On a minor note, and in a recent thread posting, I hit the case of
needing to specifically bind and re-set the namespace because i was
doing an EVAL in a separate thread. It seems a default of retaining
the default namespace that the EVAL and thread expressions are in
would be more convenient. Afterall, I never explicitly changed my
namespace, and was writing functions in a file that specified a given
namespace. I was quite surprised that by simply 'adding a thread'
stuff quit working. Of course I decided I did really want the separate
thread eval to be a different namespace afterall, so maybe it's not a
big deal. You could add a namespace argument (maybe defaulting to
current) to EVAL, in fact I wrote a function for my application is
essentially that.
Hope some of this helps
--n
Raoul Duke
> be understood, and many things you initially try to do are the 'wrong
> way' etc.
request-to-all from this newbie: pretty please add even succinct notes
about those things to the wiki. somewhere consistent, so other newbies
can find them.
> 2)
> Any advances in the error handling / reporting would be greatly
> beneficial. Sometimes you see in the nasty stacktrace the actual
> 'problem' or 'clojure line of text' that is the culprit, but many
> times you do not. This can be kept in check with super-incremental
word!
sincerely.
Tom Emerson
Michael Reid
On Wed, Sep 10, 2008 at 2:40 PM, Rich Hickey <richh...@gmail.com> wrote:
> What are you doing with Clojure?
>
Currently I'm working on writing extensions to JSF (JavaServer Faces)
that allow seamless use from Clojure.
One offshoot of this is to experiment with a browser-based Clojure IDE.
>
> What 3 features would you most like to see added next?
>
1. I'll have to echo the request for better errors. In particular it
seems there are a number of cases where we get a
clojure.lang.Compiler$CompilerException but no message about why it
was thrown.
2. Is it possible for the Clojure map types to implement
java.util.Map? Obviously the mutable parts of the interface wouldn't
work, but those are all defined as optional operations.
Beyond that it is hard for me to think of language features that are
missing. It already has a fantastic set of data structures which
provides a very solid foundation I am at a loss for specific features
to ask for.
/mike.
.Bill Smith
Bill
PJ Durai
>
> As we rapidly approach 500 members on the group (!) I thought it would
> be a good time to conduct another poll:
>
>
> What are you doing with Clojure?
For now, java scripting.
I love Clojure and LFE (Lisp Flavoured Erlang) for the same reason.
Both give a Lisp front end to great VMs whose native languages are a
bit lacking.
> What 3 features would you most like to see added next?
Can't think of anything in Clojure per se.
There ought to be more examples (cookbook like snippets) though.
Randall R Schulz
> As we rapidly approach 500 members on the group (!) I thought it
> would be a good time to conduct another poll:
>
>
> What are you doing with Clojure?
Tinkering. Contemplating an extensibility mechanism for my theorem
prover.
> What 3 features would you most like to see added next?
The only thing that would really help unblock me is:
1) Programmable reader macros á là Common Lisp.
> Thanks,
>
> Rich
Randall Schulz
Meikel Brandmeyer
Am 10.09.2008 um 20:40 schrieb Rich Hickey:
> What are you doing with Clojure?
At home mostly pet projects to learn different aspects of programming:
- lazy-map started as closure became a proxy and will finally end up in
Java. => Java to Clojure Interface
- parser (parser combinator library) to experiment with functional
programming. (this also goes somehow into the DSL direction)
- (planned) a simple pop3 server to work with multiple threads
At work:
- a DSL which "compiles" to Excel and Powerpoint to get rid of Office
- a GUI for previously mentioned DSL
> What 3 features would you most like to see added next?
1. More informative error messages. From .clj files it's relatively easy
to get the line of the failure and start guessing. But from the Repl
it's pretty hard to figure out sometimes, what the problem in
Compiler$AnalyzeSeq: bla blub is.
2. A compiler. :)
3. Whatever you do: Keep Clojure simple and clean.
(4. clojure.contrib.lib is already contained. :))
You do a really good job here! :) Thank you.
Also chapeau for the Clojure community! It's very helpful and newbie
friendly. It's really fun to be around here in these exciting times.
One doesn't get the chance to experience the development of such a nice
language from the very beginning that often.
Sincerely
Meikel
Jamie Brandon
(read (PushbackReader. (StringReader. my-string)))
> I've noticed functions can only refer to those previously defined, so you couldnt have 2 that depend on one another
This is because symbols are looked up at compile time. So what you can do is
(def f)
(defn g [x] (+ 1 (f x)))
(defn f [x]
(if (= x 0)
0
(g (- x 1)))
(g 4) => 4
It would be fairly easy to whip up a macro that handles this more neatly:
(def-rec f g
(defn g [x] (+ 1 (f x)))
(defn f [x] (* x x)))
> What are you doing with Clojure?
Writing a scriptable notetaking app for my tablet, as all the existing
apps turn it into a very expensive pad of paper.
mzscheme has a neat module system (
http://docs.plt-scheme.org/guide/units.html ) that handles mutual and
cyclic dependencies between modules. I'm slowly porting this to
clojure, the only real difficulty being fitting it in neatly with the
namespace system.
> What 3 features would you most like to see added next?
I'll echo better compiler errors. The runtime error reporting is
pretty good but the compile time errors are useless.
I'd also like to control how my datastructures are printed, maybe by
making print a multimethod dispatching on something like (or (:type
^obj) (class obj)). I think thats fairly vital for building new
abstractions on top of the existing types.
And eventually I would like a contract library, to help me get off the
static typing crack. I may have a shot at it when I've finished my
current side project.
John Hodge
What are you doing with Clojure?
What 3 features would you most like to see added next?
Raoul Duke
if chances come up to speed-up the compiler (e.g. would something like
Scala's fsc be something one could create for Clojure?), i'd never say
no to such changes. :-)
Ozzi Lee
What 3 features would you most like to see added next?
2. Better error messages.
3. Better error messages :-)
Shawn Hoover
As we rapidly approach 500 members on the group (!) I thought it would
be a good time to conduct another poll:
What are you doing with Clojure?
What 3 features would you most like to see added next?
- A native executable would be preferred to launching with java or a batch file (on Windows, especially, where you're always left with an extra Y/N prompt after you Ctrl-c out of the REPL).
- Documented canonical approaches to dealing with the classpath for loading other Java and Clojure code. If someone posts a .clj file on the web and you just want to try it, what's the best move? If you want to package and use clojure.contrib in an app you deploy, how does that affect your directory structure, namespace declarations, and installer?
- Any creative options for those not already on the Java platform to integrate with Clojure. Maybe this is a non-goal since the tight integration is one of Clojure's strengths, and maybe Clojure is best for those on Java or starting from scratch, but the language is useful enough I'd like to consider how to integrate with existing code in other environments. IKVM.NET does work, but the 8 second startup time is prohibitive for interactive command line use.
Randall R Schulz
> ...
>
> 1. A native executable would be preferred to launching with java
> or a batch file (on Windows, especially, where you're always left
> with an extra Y/N prompt after you Ctrl-c out of the REPL).
Explore the difference between the "java.exe" and "javap.exe" launchers
for the Windows JVM.
And, of course, if you want a proper interactive environment on Windows,
Cygwin is scarcely optional. The rough edges between its POSIX
environment and the native Windows one are minor, mostly a matter of
the file name and PATH (-like) variable syntaxes. Those can be papered
over (even generically) with BASH or other shell scripting.
> ...
>
> --Shawn
Randall Schulz
jim
Learning functional programming concepts (monads, monad transformers,
arrows)
Learning logic programming concepts.
Implementing state machine, parsing and relational algebra/calculus
libraries.
HTML, Javascript and CSS generators.
Writing a net server framework; have an HTTP server and most of an
SMTP.
What I'd like to see?
A package repository like CPAN coupled with something like ASDF.
Jim
budu
with it after trying so many times with other frameworks. ;-)
A small parser combinators library. I've put it on hold for now as I'm
trying to figure out a better way to work with monads in Clojure. I
was having some difficulties with a technique I've taken from a scheme
version of parser combinators.
A naive port of Clojure to C#, it's more about forcing myself to read
the Java code and learn Clojure's internals than a serious porting
effort, though. I've not thought about how to do the code generation
yet, porting the ASM library look quite hard. I'll make some unit
tests to see if thing are working afterward (yeah, bad TDD) and if
thing aren't too broken I'll put it on Google Code or something. I've
learned lots of stuff about C# and Java concurrency while doing that.
> What 3 features would you most like to see added next?
messages and stack traces, I'm even ready to give some help if you
need some.
Adding a simple pattern matching operation like Ocaml's match
construct, or structural switch statement like you call it :), most of
the functionality is already there with destructuring. I've tried
implementing it with a macro but there were some limitations.
Can't think of anything else right now!
P.S.: I'm not sure about the structural switch statement thing. I've
searched Google for it and there were no result, but I think that's
what you meant in your post entitled "Abstract structural binding".
Correct me if I'm wrong.
Parth Malwankar
On Sep 10, 11:40 pm, Rich Hickey <richhic...@gmail.com> wrote:
> As we rapidly approach 500 members on the group (!) I thought it would
> be a good time to conduct another poll:
>
> What are you doing with Clojure?
>
Creating a processor simulator in my free time.
> What 3 features would you most like to see added next?
possibly clj sub-expression etc.). It would make debugging much
easier.
I think the errors today talk quite a bit about the
compiler internals and such and as a user I am just
wearing a Clojure hat and don't know Java. There could
possibly be a verbosity flag which filters out the
clojure internal related stuff and talks only in terms
of what I did wrong in the my clojure code.
Maybe there could be clojure error codes, E124, E832
etc along with the error messages that could be used
to refer to docs on that specific error as the docs
improve. Or better still, (doc E124) or something similar
could work.
2. Some introspection capabilities for clojure first class
objects like functions (maybe based on metadata).
This would help easily create decorators and such.
Use case was briefly discussed on this thread and on IRC:
http://groups.google.com/group/clojure/msg/cb7a45124bbf92f5
http://clojure-log.n01se.net/date/2008-09-02.html#8:05
The only solution we could come up with was to use the
compiled function mame e.g user.foo__2372@5388b5 and use
regex or similar such mechanism, but that doesn't scale to
line number and such. Have introspection support
(possibly built on top of metadata so that the user could
extend it would be nice) would make the code for use
cases like decorators cleaner IMHO.
3. These are some minor items that would be nice to have,
if you feel these are not *general* enough for inclusion
into Clojure don't bother with these.
a. Possibly a "get-classpath" or similar to complement
"add-classpath" and to aid debugging. This can be
confusing to someone who doesn't know Java much
and doesn't know Clojure internals.
http://clojure-log.n01se.net/date/2008-09-07.html
b. A way of having a defining a defmethod for a set
of values. Something like the "defmethod-in" discussed
in this thread:
http://groups.google.com/group/clojure/msg/bf7c299a08c39688
I suspect this may be a general enough requirement and
would make the code cleaner.
Like I said these are fairly minor and can easily be done
in the user programs as utils or something, but it would be
nice for something like this to be available out of the box in
case the community considers it a common enough requirement.
4. A package repository like CPAN would be nice apart from formal
clojure-contribs. This can be a test bed for clojure packages and
those that are robust and used a lot could possibly be considered
for inclusion into Clojure. It would keep people from reinventing
the
wheel and also serve as reference code for new users.
Thanks for Clojure Rich. I am having a fantastic time with Clojure.
Parth
>
> Thanks,
>
> Rich
Apurva Sharan
Still learning the language in my spare time :)
> What 3 features would you most like to see added next?
1) Like most people, more specific error messages. Error messages that point out
the faulty sub-expression would be helpful.
2) Packaging infrastructure similar to ASDF.
3) Equivalent of 'format' macro. This would be really helpful in debugging.
Regards,
Apurva
----- Original Message -----
From: "Rich Hickey" <richh...@gmail.com>
To: "Clojure" <clo...@googlegroups.com>
Sent: Thursday, September 11, 2008 12:10:05 AM GMT +05:30 Chennai, Kolkata, Mumbai, New Delhi
Subject: Clojure Poll 09/2008
As we rapidly approach 500 members on the group (!) I thought it would
be a good time to conduct another poll:
What are you doing with Clojure?
What 3 features would you most like to see added next?
Thanks,
Rich
Rastislav Kassak
>
> What I'm doing?
>
> Learning functional programming concepts (monads, monad transformers,
> arrows)
> Learning logic programming concepts.
> Implementing state machine, parsing and relational algebra/calculus
> libraries.
> HTML, Javascript and CSS generators.
> Writing a net server framework; have an HTTP server and most of an
> SMTP.
>
> What I'd like to see?
>
> A package repository like CPAN coupled with something like ASDF.
Yes, this is another great feature in ruby - gems. I'm not sure about
ASDF, just know it's something similar for CL. IMHO, it's really
important to have packaging system.
hoeck
On 10 Sep., 21:28, Allen Rohner <aroh...@gmail.com> wrote:
> Finally, not that I'm asking you or anyone else to build this, I'm
> just throwing this out there to see if anyone else is thinking along
> the same lines as me :-). I think it would be really cool to build a
> database in Clojure. SQL the language sucks, and the overhead of
> sending SQL strings to a remote process and having it compile the
> command sucks.
relational algebra in clojure. I'm using clojures hashmaps for indexes
and vectors to represent the tuples. For conditions, I am using
functions returning true on matching vectors and for creating
conditions i use a macro. It's fun but hard to get right.
FabienT
with Clojure, I am at the moment porting from Java a simple constraint
solver for linear integer programming that I intend to parallelize
using Clojure specific approach to concurrent programming.
> What 3 features would you most like to see added next?
conditional pattern matching is of tremendous importance, even in the
case of untyped languages where algebraic datatypes are not available
per se. Conditional pattern matchin à la Erlang would be great, and
even greater using Clojure's powerful destructuring mechanisms.
Fabien
Timothy Pratley
> What 3 features would you most like to see added next?
improved. It is a real pleasure to use.
So I've defaulted to community and tools items even though perhaps
they are off topic:
1) Cells http://common-lisp.net/project/cells/
Really cool project for GUI and other applications. Clojure obviously
is targeting java as *the* GUI delievery method. Clojure-Cells using
java GUI primatives would be a really big selling point in making
Clojure appealing to developers. This is a community question though
(Should Cells support Clojure? Should its core be ported and the GUI
wrapper parts re-written? And does anyone actually want to build it?).
2) A pre-compiler, to achieve
- just in time scoped variables
- auto type tipping
- infix
- non enclosed forms
Precompiler translates to s-expressions,
records all transforms in some sort of diff notation,
hands to Clojure,
gets an exception error,
untransforms the line number,
either attempts to untransform the error string,
or shows both a transform code block and non-transform code block
I don't think Clojure requires any changes to support this, so I'm
going to have a crack at building a simple pre-compiler myself. Just
sharing my thoughts and wondering if its a "good thing" to do or if
I'm headed for heartbreak.
Regards,
Tim.
Chouser
>
> Funny, had this idea too and know playing with an implementation of
> relational algebra in clojure. I'm using clojures hashmaps for indexes
> and vectors to represent the tuples. For conditions, I am using
> functions returning true on matching vectors and for creating
> conditions i use a macro. It's fun but hard to get right.
Sounds similar to clojure.set:
(doseq [n v] (ns-publics (find-ns 'clojure.set)) (print-doc v))
--Chouser
noahr
Have some prefix-character to allow you to have the argument to a
macro be evaluated (sorta like a function), and its resulting data
structure given to the macro instead. I realize the whole point of
macros is that the arguments ARENT evaluated, but would it be useful
to selectively turn that off for specific arguments in specific calls
to the macro??
Paul Stadig
way we can get the reader to not have problems with
"#!/usr/bin/clojure" as the first line?
This would allow simple and standard use of Clojure in a script file.
Or perhaps a solution (other than mucking with the reader) is to have
clojure.lang.Script ignore the first line if it is the shebang?
I mean this is cool (in a really geeky way)
#^:shebang '[
exec java -cp "$HOME/src/clj/clojure/clojure.jar" clojure.lang.Script
"$0" -- "$@"
]
But its not standard, nor is it simple to remember, and if you have a
bin script that does stuff like read a Clojure rc file, or set the
classpath, or something you either lose that functionality, or you
have to basically try to duplicate the bin script at the top of every
clojure script. Additionally, if you want to hard code the path for
security like so
#^:shebang '[
exec /usr/bin/java -cp "$HOME/src/clj/clojure/clojure.jar"
clojure.lang.Script "$0" -- "$@"
]
Clojure has issues with it.
Low priority, but still useful.
Paul
Stuart Sierra
> 3) Equivalent of 'format' macro. This would be really helpful in debugging.
-Stuart
MikeM
> What are you doing with Clojure?
used Beanshell. I have a very simple framework (really not enough to
justify the use of the term framework), with a ServletContextListener
to run start-up and shutdown scripts, a REPL servlet and a dispatch
servlet to handle request routing to Clojure functions.
I'm currently running a Clojure-based webapp that extracts from a
database, transforms and loads into another database. Clojure is the
most pleasant way I've found yet to work with JDBC. I'm currently
developing another webapp to automate some statistical analysis and
present charts (using Flot, with json data from Clojure).
> What 3 features would you most like to see added next?
requested better error messages, and I think this would be a good area
for enhancements. I have read that a Prolog-type of capability is in
the works, and I'm eager to see what this will look like.
Stuart Sierra
engine -- http://altlaw.org/
> What 3 features would you most like to see added next?
2. Streamlined gen-and-save-class with method definitions in a single
file,
3. A dependency-resolution library, a la make or ant.
-Stuart
Allen Rohner
On Sep 11, 8:32 am, "Paul Stadig" <p...@stadig.name> wrote:
> I have a stupid idea as well (related to reader macros). Is there any
> way we can get the reader to not have problems with
> "#!/usr/bin/clojure" as the first line?
>
> This would allow simple and standard use of Clojure in a script file.
> Or perhaps a solution (other than mucking with the reader) is to have
> clojure.lang.Script ignore the first line if it is the shebang?
>
> I mean this is cool (in a really geeky way)
>
> #^:shebang '[
> exec java -cp "$HOME/src/clj/clojure/clojure.jar" clojure.lang.Script
> "$0" -- "$@"
> ]
>
> But its not standard, nor is it simple to remember, and if you have a
> bin script that does stuff like read a Clojure rc file, or set the
> classpath, or something you either lose that functionality, or you
> have to basically try to duplicate the bin script at the top of every
> clojure script. Additionally, if you want to hard code the path for
> security like so
>
> #^:shebang '[
> exec /usr/bin/java -cp "$HOME/src/clj/clojure/clojure.jar"
> clojure.lang.Script "$0" -- "$@"
> ]
>
> Clojure has issues with it.
>
clojure scripts from a command line would be very useful.
Allen
AlamedaMike
> What 3 features would you most like to see added next?
Annotated code samples for the more unusual parts of the language
would be helpful.
At some point, I'd love to see a "Rationale for the design of the
Clojure language" doc. It's such a wonderful mix of features. As an
inducement, I'd guess that writing this would help you clarify future
language design issues. This would greatly help learning, as well.
Tom Emerson
> I already voted, but I agree with this. Having a standard way to run
> clojure scripts from a command line would be very useful.
One could trivially take the command-line generated by the shell
magick and put it into a simple shell script that lets you invoke
Clojure on the named script and arguments, couldn't you?
% clojure foo.clj bar baz qux
would run foo.clj and pass the arguments. Seems to me this is easier
(and cleaner) than coming up with some way of support shebang.
-tree
--
Tom Emerson
trem...@gmail.com
http://www.dreamersrealm.net/~tree
Apurva Sharan
The full mini-language provided by format is much more powerful ...
[1]> (format nil "~{[~{~a~^:~}]~^~&~}" '((1 2 3)(7 8 9)))
"[1:2:3]
[7:8:9]"
[2]> (format nil "~r" 123456)
"one hundred and twenty-three thousand, four hundred and fifty-six"
[3]>
But, this is really just a 'nice to have' ...
Regards,
Apurva
----- Original Message -----
From: "Stuart Sierra" <the.stua...@gmail.com>
To: "Clojure" <clo...@googlegroups.com>
Chas Emerick
(for lack of a better term, given that the tools aren't yet public).
In the process, we're touching a ton of different Java libraries
(including our own), as well as building implementations of new APIs
in Clojure with the help of gen-class. We're extraordinarily happy
overall.
My top 3 would be:
- AOT compilation to classfiles -- which would vastly simplify
deployment in various scenarios, and make Clojure applications
amenable to all sorts of other tools in the Java space: direct ikvmc
cross-compilation, gcj-built native executables, obfuscation tools,
test coverage tools, etc. etc. etc.
- Some pattern-matching facilities baked into the stdlib or contrib.
There have been a couple of implementations batted around on the
group, but I'd like to not pick up someone's implementation when a
canonical one may yet emerge. Rich, I know you're either skeptical of
(or maybe downright opposed to?) pattern matching, but it's an
absolutely fantastic tool for concisely implementing various
algorithms within a narrow context. It's probably at least half due
to my suckage, but unrolling data structure impls presented in (for
example) Okasaki is harder than it needs to be right now.
- Tools, tools, tools. This is obviously more related to enclojure,
but as clojure matures, it'd be great to see first-class debugging,
profiling, remote clojure instance mgmt, etc. I know Eric is plowing
ahead in this department, so I'm sure this will fall into place in
good time.
Thank you for Clojure, Rich, and thanks also to all of the contrib
authors and everyone that has made the community around it so
pleasant.
- Chas
> be a good time to conduct another poll:
>
>
>
>
> Rich
Chas Emerick
On Sep 11, 9:59 am, Stuart Sierra <the.stuart.sie...@gmail.com> wrote:
> On Sep 10, 2:40 pm, Rich Hickey <richhic...@gmail.com> wrote:
>
> > What are you doing with Clojure?
>
> file,
accompanying method definitions. Doing so only requires a macro that
emits the gen-and-save-class form only when an output directory is
bound (which can be taken care of by a compilation script, for
example). The macro we use was included in the code attached to this
post:
http://groups.google.com/group/clojure/browse_frm/thread/7849606b989a1f70
An ant plugin that formalized a process like this would be handy. Yet
another thing I may or may not fiddle with some weekend...
- Chas
James Reeves
applications.
> What 3 features would you most like to see added next?
myself writing constructor functions for structs:
(defstruct revision
:content
:timestamp)
(defn create-revision
[content]
(struct revision content (new java.util.Date)))
But there isn't a standard naming convention for what to call the
constructor, so users wouldn't know whether it was new-revision,
construct-revision, create-revision or whatever. It would be nice if
there was a multimethod with a standard name that could be overridden.
Maybe something like:
(defmulti create #(first %&))
(defmethod create revision
[type content]
(struct type content (new java.util.Date)))
2. Clojure's inbuilt data structure syntax for vectors, sets and hash-
maps is very useful, but the disadvantage to this extra syntax is that
it is currently very difficult to manipulate blocks of Clojure code
without altering the containing data type. Traditional lisps that only
use S-exprs do not have this problem.
For instance, I can easily create a small function to transform a tree
of sequences so that the contents of each sequence are reversed:
(defn postfix
[code]
(if (seq? code)
(map postfix (reverse code))
code))
But once you start trying to parse sequences within maps and vectors,
you run into problems. When you apply "map" to a vector, your vector
gets turned into a sequence, so your code is no longer valid. It would
be nice if there were a function that would enable you to iterate over
the items in a tree of Clojure code, without affecting the data type
of lists and hash-maps and so forth.
3. Persistent refs for Clojure data types would be rather nice, but I
suspect rather tricky to implement! Still, it would be very cool to be
able to write:
(def users
(persistent-ref "users.dat" {}))
(dosync
(commute users assoc "fred" {:age 45, :job "developer"}))
And have the users ref automatically and efficiently save its data to
a file as it is altered.
- James
Jamie Brandon
> Really cool project for GUI and other applications. Clojure obviously
> is targeting java as *the* GUI delievery method. Clojure-Cells using
> java GUI primatives would be a really big selling point in making
> Clojure appealing to developers. This is a community question though
> (Should Cells support Clojure? Should its core be ported and the GUI
> wrapper parts re-written? And does anyone actually want to build it?).
I've written a small cells module for clojure and qt.
http://paste.lisp.org/display/66688
http://paste.lisp.org/display/66689
Tested with qt jambi 4.4.1
Wont work well with swing of course, but it shouldnt be too hard to modify.
Paul Drummond
Python/Django as I felt I needed to learn about a popular existing web
framework before attempting to experiment with new ideas in Clojure.
As such I haven't been working with Clojure directly for some time but
I hope to return to it very soon!
Cheers,
Paul Drummond
Rich Hickey
(defn map-same [f coll]
(into (empty coll) (map f coll)))
(map-same inc [1 2 3 4])
-> [2 3 4 5]
(map-same (fn [[k v]] [k (inc v)]) {:a 1 :b 2 :c 3 :d 4})
-> {:c 4, :d 5, :a 2, :b 3
Rich
peg
> What are you doing with Clojure?
trying some java library integration
(jboss-JBPM, jboss-drools, apache Camel, Restlet, Freemind)
> What 3 features would you most like to see added next?
2) JSON reader form (very close to clojure 's map and array)
for easy Apache Sling or Apache CouchDB interactions
radu.floricica
> What 3 features would you most like to see added next?
of what is available is nowhere to be found (or at least not easy
enough). I _knew_ something like html-format had to exist, but it took
me a bit too much googling to find it. (Maybe in the wiki?)
Also, like someone said above, there is a big increase in learning
curve steepness when you go from learning the language to actually
using it. Clojure.org is very good for learning, but I'd like to see
some more advanced tutorials around. The wiki is great, but more is
better.
The third wish is an aye for better error messages.
Dmitri P
company projects
Would like:
1) up to date documentation. Online docs are so far behind SVN it's
not funny. Yes yes, SVN is not release, but in the beginning stages of
the project as it is things happen very fast and sticking with release
is shooting yourself in the foot.
2) more examples in online docs, especially where there are no
examples at all.
3) more syntax tricks, like defining partials with arbitrary argument
positions.
Otherwise, clojure is already good, because it's lispy, does macros
and talks with java.
On Sep 10, 2:40 pm, Rich Hickey <richhic...@gmail.com> wrote:
> As we rapidly approach 500 members on the group (!) I thought it would
> be a good time to conduct another poll:
>
>
>
>
> Rich
Mike Hinchey
I'm also looking to so some semantic web and rdf work, so I'm hoping
to hear from others that have already started this type of work with
clojure.
> What 3 features would you most like to see added next?
evaluate an expression before macroexpansion. (But not a dot.)
Just an idea, but it could be useful to have the STM and a DB
transaction tied together so they commit atomically.
Line and position for compile errors, including in the repl.
-Mike
Chouser
> Line and position for compile errors, including in the repl.
Like this?
user=> (def foo yoink)
java.lang.Exception: Unable to resolve symbol: yoink in this context
clojure.lang.Compiler$CompilerException: NO_SOURCE_FILE:97: Unable to
resolve symbol: yoink in this context
The key part being: NO_SOURCE_FILE:97
Obviously there's no source file at the repl, but this was apparently
the 97th line I've entered in this repl.
--Chouser
Matt Revelle
On Sep 10, 2008, at 2:40 PM, Rich Hickey wrote:
>
> As we rapidly approach 500 members on the group (!) I thought it would
> be a good time to conduct another poll:
>
> What are you doing with Clojure?
>
Building a system for defining and manipulating movement of rigid
limbs. That involves various geometry and algebra sorts of things.
Starting to look at options for simple 3d visualization (similar to
Matlab) from the REPL.
Also planning on using Clojure for the next version of a data
organization app involving link analysis and machine learning.
>
> What 3 features would you most like to see added next?
>
There are various tools and resources that I'd like, but the only
language feature is user-defined reader macros.
Thanks for Clojure.
>
>
> Thanks,
>
> Rich
> >
kyle smith
partial success). Users will be able to compose complex properties
from basic info such as bond lengths/angles, position, velocity, etc.
I'd like to add regression and integrate it with a 3d viewer
eventually. With some modification, this could allow users to
generate coordinates for complex structures (i.e. bio stuff like dna).
Craig McDaniel
wouldn't approve of my using a language in an alpha state, much less a
variant of Lisp! But since I love the language and the interactive
environment with Emacs, I decided it's easier to beg forgiveness than
ask permission.
1. Wrote a Clojure service that runs on remote thin clients. It
receives Clojure forms that instruct it to download and cache PDF
templates, dynamically fill in form data, overlay logos, etc.., then
print the resulting PDF.
2. I also use it for prototyping and experimentation.
> What 3 features would you most like to see added next?
Not really features, but...
2. More thorough documentation and examples: For instance: how to
profile your code and decide where you should use type hints.
3. Can't think of #3.
Moxley Stratton
On Sep 10, 2008, at 11:40 AM, Rich Hickey wrote:
>
> What are you doing with Clojure?
Nothing at the moment. I wrote a knowledgebase engine inspired by the
Cyc project, and I also wrote part of a web application in Compojure
that lets users create web forms.
> What 3 features would you most like to see added next?
1. I love the language. Nothing to add there.
2. Like many others said, better error reporting.
3. The documentation is not well suited for the masses who are not
well-versed in Lisp dialects or functional programming. It's more like
marketing material for those who have already spent a some quality
time in that world, and are curious to see how this new kid on the
block compares. I think it does a great job at selling the language to
those people, but the newbies are left behind. To help newbies, the
documentation needs to be reorganized, more introductory text needs to
be written, many more examples need to be shown.
Moxley
Chas Emerick
this item can replace my tools, tools, tools item): It would be
really fantastic if a method were available to compile interdependent
Java and Clojure codebases. Existing best practices generally make
such interdependencies unnecessary, but when they are necessary,
they're *really* necessary, and the workaround can get very ugly.
Specifically, I suspect a solution would require a Clojure-driven
compile process that resolves the dependency chains/cycles, and then
uses javac on the side to weave together the Java and Clojure
compilation process as necessary so as to keep javac happy.
- Chas
James Reeves
> This can be done generically using empty, like this:
>
> (defn map-same [f coll]
> (into (empty coll) (map f coll)))
>
> (map-same inc [1 2 3 4])
> -> [2 3 4 5]
>
> (map-same (fn [[k v]] [k (inc v)]) {:a 1 :b 2 :c 3 :d 4})
> -> {:c 4, :d 5, :a 2, :b 3
- James
Alexander Kjeldaas
On Sep 10, 8:40 pm, Rich Hickey <richhic...@gmail.com> wrote:
> As we rapidly approach 500 members on the group (!) I thought it would
> be a good time to conduct another poll:
>
> What are you doing with Clojure?
>
> What 3 features would you most like to see added next?
>
1. Better error messages with helpful suggestions and a pointer to a
"wiki" for each error. The wiki should have a reddit-system with the
most "popular" problems related to an error. A snapshot of the error-
wiki could be included in Clojure.
2. Clojure states that it has good support for list comprehensions.
Maybe I'm misunderstanding list comprehensions, but I'm not completely
happy. I want a way to have destructuring work on the sequence, not
on the individual element. In CL you have (loop for i in '(1 2 3) ...)
as well as (loop for i on '(1 2 3) ...). How is the one-liner to
create a lazy sliding window over a sequence in Clojure?
3. The Clojure coding style sets a bad precedent wrt commenting.
Using Clojure professionally means you need comments. The
(comment ...) form, although theoretically elegant just doesn't look
good. There is not a single comment in boot.clj. Is this a
coincidence?
4. Preconditions/postconditions/invariants. I like them, and I don't
see them in Clojure.
5. Please document that "everybody" is using the svn/git versions of
the code and that you are wasting your time if you download the
distribution and try to get it to work in emacs. People using Clojure
will have no problems using the svn version, but it is annoying to
have to figure it out by searching through Google Groups.
Alexander
Chouser
<alexander...@gmail.com> wrote:
>
> 2. Clojure states that it has good support for list comprehensions.
> Maybe I'm misunderstanding list comprehensions, but I'm not completely
> happy. I want a way to have destructuring work on the sequence, not
> on the individual element. In CL you have (loop for i in '(1 2 3) ...)
> as well as (loop for i on '(1 2 3) ...). How is the one-liner to
> create a lazy sliding window over a sequence in Clojure?
There are many functions that operate on sequences which are not built
into Clojure's "for" macro. Perhaps you want partition:
user=> (partition 3 1 (range 5))
((0 1 2) (1 2 3) (2 3 4))
This could then be destructured with for if you want:
user=> (for [[a b c] (partition 3 1 (range 5))] (- c a))
(2 2 2)
> 3. The Clojure coding style sets a bad precedent wrt commenting.
> Using Clojure professionally means you need comments. The
> (comment ...) form, although theoretically elegant just doesn't look
> good. There is not a single comment in boot.clj. Is this a
> coincidence?
Besides (comment ...) there is also ; and documentation strings stored
as meta-data attached to function vars. boot.clj has all but the
first of these.
--Chouser
Randall R Schulz
> On Wednesday 10 September 2008 11:40, Rich Hickey wrote:
> > As we rapidly approach 500 members on the group (!) I thought it
> > would be a good time to conduct another poll:
> >
> >
> > What are you doing with Clojure?
>
> prover.
>
> > What 3 features would you most like to see added next?
>
>
> 1) Programmable reader macros á là Common Lisp.
I'd like to add:
2) Balanced-boundary (non-EOL-terminated) comments. Whether the syntax
is #| ... |# (á là Common Lisp) or /* ... */ (C- and Java-like) or
something else, I don't much care, but I think both line-terminated and
balanced comments are called for. Likewise, whether balanced-boundary
comments nest or not is not a key concern of mine, though it might be
nice if they did, for a change.
Randall Schulz
J. McConnell
I'd like to add:
2) Balanced-boundary (non-EOL-terminated) comments. Whether the syntax
is #| ... |# (á là Common Lisp) or /* ... */ (C- and Java-like) or
something else, I don't much care, but I think both line-terminated and
balanced comments are called for. Likewise, whether balanced-boundary
comments nest or not is not a key concern of mine, though it might be
nice if they did, for a change.
Allen Rohner
> > 2) Balanced-boundary (non-EOL-terminated) comments. Whether the syntax
> > is #| ... |# (á là Common Lisp) or /* ... */ (C- and Java-like) or
> > something else, I don't much care, but I think both line-terminated and
> > balanced comments are called for. Likewise, whether balanced-boundary
> > comments nest or not is not a key concern of mine, though it might be
> > nice if they did, for a change.
>
> Are you aware of the (comment ...) macro? Is there any benefit to balanced
> comments that the macro doesn't provide?
happy with the body of the comment. Including things like # in the
comment body can upset the reader and cause your file to not compile.
Allen
J. McConnell
There is one weakness with the comment macro; the Reader has to be
happy with the body of the comment. Including things like # in the
comment body can upset the reader and cause your file to not compile.
Alexander Kjeldaas
There are many functions that operate on sequences which are not built
On Tue, Sep 16, 2008 at 4:49 AM, Alexander Kjeldaas
<alexander...@gmail.com> wrote:
>
> 2. Clojure states that it has good support for list comprehensions.
> Maybe I'm misunderstanding list comprehensions, but I'm not completely
> happy. I want a way to have destructuring work on the sequence, not
> on the individual element. In CL you have (loop for i in '(1 2 3) ...)
> as well as (loop for i on '(1 2 3) ...). How is the one-liner to
> create a lazy sliding window over a sequence in Clojure?
into Clojure's "for" macro. Perhaps you want partition:
user=> (partition 3 1 (range 5))
((0 1 2) (1 2 3) (2 3 4))
This could then be destructured with for if you want:
user=> (for [[a b c] (partition 3 1 (range 5))] (- c a))
(2 2 2)
Besides (comment ...) there is also ; and documentation strings stored
> 3. The Clojure coding style sets a bad precedent wrt commenting.
> Using Clojure professionally means you need comments. The
> (comment ...) form, although theoretically elegant just doesn't look
> good. There is not a single comment in boot.clj. Is this a
> coincidence?
as meta-data attached to function vars. boot.clj has all but the
first of these.
Tom Emerson
> What are you doing with Clojure?
1. Using it as a prototyping language for information extraction and
NLP applications.
2. Using it to replace Python for data munging.
3. Using it to provide a REPL into a large IE system that is written in Java.
My hope is to, in the future, use it as an implementation language in
the apps we're working on, in addition to Java. Unfortunately only a
few of us speak Lisp, so wide adoption is difficult (we have enough
problems finding competent Java developers!)
> What 3 features would you most like to see added next?
Better error messages, if possible. However, I have yet to come across
a case where I could suss what was going wrong from the messages the
current release emits.
The documentation is pretty good, but I've found myself digging around
for things and trying to look things up when reading other people's
code but not having luck picking apart some of the reader shortcuts.
-tree
--
Tom Emerson
trem...@gmail.com
http://www.dreamersrealm.net/~tree