Alternative structures to arrays?

[Simon Holgate]

Hi,

I'm pretty new to functional languages but really love Clojure.

My work typically involves multi-dimensional arrays of data. I'm an
oceanographer and typically use things like sea surface height data
from satellite altimetry on 1/3 degree 2D grids with maybe 800 time
slices (=O(5E8 data points)). For this I use Fortran and R.

I realise that I can just use Java arrays, but is this the best
approach? I could implement lists of lists but I'm guessing that the
performance would be worse?

What other structures could I use? The arrays are typically 30% sparse
(since only 70% of the planet is ocean). This means arrays are
wasteful in many ways.

Similar issues must apply in image processing so are there ways of
handling such data in functional structures?

Thanks for any advice,

Simon

-- 
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: Alternative structures to arrays?

[Alex Robbins]

Hey Simon,

Incanter is a clojure data processing platform (R-like). http://incanter.org/
It wraps Parallel Colt, a Java matrix math/linear algebra library,
among other things. Parallel colt provides sparse matrices, and I
*guess* they are exposed in the clojure wrapper.
https://sites.google.com/site/piotrwendykier/software/parallelcolt

Alex

On Thu, Dec 22, 2011 at 4:11 AM, Simon Holgate  wrote:
> Hi,
>
> I'm pretty new to functional languages but really love Clojure.
>
> My work typically involves multi-dimensional arrays of data. I'm an
> oceanographer and typically use things like sea surface height data
> from satellite altimetry on 1/3 degree 2D grids with maybe 800 time
> slices (=O(5E8 data points)). For this I use Fortran and R.
>
> I realise that I can just use Java arrays, but is this the best
> approach? I could implement lists of lists but I'm guessing that the
> performance would be worse?
>
> What other structures could I use? The arrays are typically 30% sparse
> (since only 70% of the planet is ocean). This means arrays are
> wasteful in many ways.
>
> Similar issues must apply in image processing so are there ways of
> handling such data in functional structures?
>
> Thanks for any advice,
>
> Simon
>
> --
> 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: Alternative structures to arrays?

[Brian Hurt]

If I wasn't using Incanter (see Alex Robbin's reply), I'd probably just use
a vector of vectors.  If your matricies 70% dense, it's generally not worth
it to try and use some sort of sparse data structure- the extra overhead of
the sparse data structure will be greater than the savings of not
representing the unpopulated areas.  Vectors are actually a great
trade-off, giving you almost the same access and memory costs arrays do,
but with all the advantages of being immutable (multi-threaded goodness).

On Thu, Dec 22, 2011 at 5:11 AM, Simon Holgate wrote:

> Hi,
>
> I'm pretty new to functional languages but really love Clojure.
>
> My work typically involves multi-dimensional arrays of data. I'm an
> oceanographer and typically use things like sea surface height data
> from satellite altimetry on 1/3 degree 2D grids with maybe 800 time
> slices (=O(5E8 data points)). For this I use Fortran and R.
>
> I realise that I can just use Java arrays, but is this the best
> approach? I could implement lists of lists but I'm guessing that the
> performance would be worse?
>
> What other structures could I use? The arrays are typically 30% sparse
> (since only 70% of the planet is ocean). This means arrays are
> wasteful in many ways.
>
> Similar issues must apply in image processing so are there ways of
> handling such data in functional structures?
>
> Thanks for any advice,
>
> Simon
>
> --
> 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: Literate programming

[Adam Getchell]

On Fri, Oct 28, 2011 at 2:45 PM, Damion Junk  wrote:

> I have also been using Emacs/Org-mode/Babel/R lately, mostly as a way to
> have easily modifiable write up and source code for assignments in
> statistics courses. I suppose this is one valid use, but I'm using it less
> to communicate code meaning and more as a convenient way to perform
> analysis, look at the results, and talk about them all in the same place,
> and then to easily generate documentation of my efforts [LaTeX output].


I'm interested in how you're including LaTeX in your code, as I'm writing
models which require LaTeX to express what they're modelling.

BTW I looked at marginalia+leiningen, which seems to work for my purposes
except I'm unclear where to put the .tex files.

The combination of literate + TDD seems forbidding.

Damion
>

Adam
-- 
"Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu

-- 
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: Could be my favourite improvement in 1.4

[Julien Kirch]

for these cases wouldn't be simpler to paste the map in a string and to create 
a function that could parse such a json-compatible map into a clojure map ?

A.


On Dec 20, 2011, at 1:36 PM, Alex Baranosky wrote:

> For what it's worth, I think colon's as whitespace in maps adds confusion, 
> without, imo adding a ton of power or readability.  In terms of power, it 
> gives you the ability to paste JSON into a Clojure REPL; I wonder how often 
> that use case comes up?  In terms of readability, any benefit it gives you in 
> readability would be counterweighted by the additional syntax rules it adds.
> 
> The only way I could see this as worth it, would be if people wanted to paste 
> 'foreign' map data into a Clojure REPL a ton more frequently than I imagine 
> they do.
> 
> Alex
> 
> -- 
> 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: ClojureQL 1.0.3

[tscheibl]

Tamensi movetur! :)

What about integrating the "WITH RECURSIVE" CTE stuff you've put on
gist?
I've merged it into my (local) fork, modified it slightly to
autodetect the compiler and consider it quite conveniently to use.
I've also added a feature to be able to mark predicate elements as
'inline' to make them added to the SQL string without "?"
parameterization. This is useful when working with the H2 Database
which doesn't permit the start query in "WITH RECURSIVE" to be
parameterized (I don't know if this is also the case with other DBs).
I would push that to a public fork if someone is interested or publish
the patches on gist to not flood the github fork network
unnecessarily.

regards,
Tom

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

Re: Clojurescript and google closure library versions?

[Jordan Berg]

I changed the curl command in the bootstrap script locally to download
r1376 since the day google released it, and I haven't had a problem since.
 Not sure if there is an official reason for not switching over yet though.

Jordan

On Tue, Dec 20, 2011 at 9:42 AM, Dave Sann  wrote:

> Hi all,
>
> Does anyone know if there are any known issues with more recent versions
> of the google closure libraries ?
> Is there a plan to switch to the latest version,
> closure-library-2010-r1376.zip ?
> (found here http://code.google.com/p/closure-library/downloads/list)
>
> What is the view on being able to choose which version you want to compile
> against?
>
> Cheers
>
> Dave
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To 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

Strange compilation problem

[Pieter Laeremans]

Hello,

When I have a clojure file with the code as listed below , I get a
compilation error
when I run "lein compile" whenever the DATABASE_URL is not defined at
compile time.

However I would expect this would be evaluated at runtime.

Is this a bug, or more likely something I don't grasp, can someone
point it out for me?

(def db-url-re #".*://(.*):(.*)@(.*):(.*)/(.*)")

;; content store
;; we configureren onze database
(let [db-url (System/getenv "DATABASE_URL")
  dbm (zipmap [:user :password  :host :port :dbname] (next (first
(re-seq db-url-re db-url
  db-host (:host dbm)
  db-port (:port dbm)
  db-name (:dbname dbm)
  user (:user dbm)
  pwd  (:password dbm)]

  (def db   {:classname "org.postgresql.Driver" ; must be in
classpath
 :subprotocol "postgresql"
 :subname (str "//" db-host ":" db-port "/" db-name)
; Any additional keys are
passed to the driver
; as driver-specific
properties.
 :user user
 :password pwd
 }))


Thanks,

PIeter

-- 
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

Literate programming/TDD with Leiningen + midje + marginalia

[Adam Getchell]

Thanks for all the replies!

I'm trying midje first (keeping expectations in mind for later) as it seems
to support writing tests and then code (i.e. top down testing).

(This video  was
useful, thanks for making it!)

In generating documentation with marginalia (particularly useful for when I
figure out how to get LaTeX formulae in there), I note that marginalia
doesn't pickup files in /test but only /src. So it seems that I need to
embed tests directly in my code in order to self-document.

Is this a huge no-no, better ways to accomplish this?

P.S. (Newbie) what's the difference between (:use [clojure.test]) and (:use
midje.sweet)? Both seem to work.

-- 
"Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu

-- 
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: multiple return values

[Razvan Rotaru]

On Dec 14, 5:33 pm, Tom Faulhaber  wrote:
> Razvan,
>
> I believe that proxy actually only creates a new class per call site,
> not per instance. However, I can't completely swear to this.
>
> Anyone with more detailed knowledge than I have want to comment?
>
> Assuming I'm right,, you should be fine to have lots of instances.
>
> HTH,
>
> Tom

What do you mean by site?
For example, how is it when I'm creating my proxy inside a macro? (and
assuming this macro is called many times)

(defmacro [a-class]
(proxy (a-class) ))

Razvan

-- 
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: Alternative structures to arrays?

[Tassilo Horn]

Brian Hurt  writes:

Hi Brian,

> Vectors are actually a great trade-off, giving you almost the same
> access and memory costs arrays do, but with all the advantages of
> being immutable (multi-threaded goodness).

On the other hand, you can have arrays of primitives but no vector of
primitives.  That might make a difference for intensive numerical
computations.

Bye,
Tassilo

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

Re: Strange compilation problem

[Tassilo Horn]

Pieter Laeremans  writes:

Hi Pieter,

> when I run "lein compile" whenever the DATABASE_URL is not defined at
> compile time.
>
> However I would expect this would be evaluated at runtime.
>
> Is this a bug, or more likely something I don't grasp, can someone
> point it out for me?

The `let' in your code is top-level, so loading that file which is
clearly needed for compiling it, will execute that form.  It's quite
unusual to have anything except defs top-level.

BTW, it's equally uncommon to compile clojure code in advance.  It gets
JIT-compiled anyway as soon as the files are loaded.

Bye,
Tassilo

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

Re: Alternative structures to arrays?

[Daniel Janus]

On Thursday, December 22, 2011 3:35:35 PM UTC, Tassilo Horn wrote:
>
> Brian Hurt  writes:
>
> Hi Brian,
>
> > Vectors are actually a great trade-off, giving you almost the same
> > access and memory costs arrays do, but with all the advantages of
> > being immutable (multi-threaded goodness).
>
> On the other hand, you can have arrays of primitives but no vector of
> primitives.  
>
This is not quite correct: see vector-of.

Daniel

-- 
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: ClojureQL 1.0.3

[Herwig Hochleitner]

Vinzent: apparently, there is a CQL google group, but it seems not to be
public. We're investigating, otherwise creating a new one.

2011/12/21 tscheibl 

> What about integrating the "WITH RECURSIVE" CTE stuff you've put on
> gist?
>

It would certainly be welcome. Though, I'm not going to do it right away,
since my current focus is on factoring CQL and especially on introducing a
real AST representation.
I consider the current code base in maintenance mode.

I've merged it into my (local) fork, modified it slightly to
> autodetect the compiler and consider it quite conveniently to use.

I've also added a feature to be able to mark predicate elements as
> 'inline' to make them added to the SQL string without "?"
> parameterization. This is useful when working with the H2 Database
> which doesn't permit the start query in "WITH RECURSIVE" to be
> parameterized (I don't know if this is also the case with other DBs).
> I would push that to a public fork if someone is interested or publish
> the patches on gist to not flood the github fork network

unnecessarily.
>

Yes please push push those changes. Preferably into separate branches.
Could you also add a comment + link to the WITH RECURSIVE ticket, and
create a ticket for the inlined predicate elements.
Those are important points of reference for someone trying to whip the code
base into shape.

Esp. the inline pred thing is invaluable, since it contains the information
that H2 can't do prepared statements properly, therefore the integration
layer needs to be able to work around that.

kind regards
-- 
__
Herwig Hochleitner

P.S.: Tom: you have an austrian email address. Are you based in austria?

-- 
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

Sumo: A new clojure client for the Riak datastore

[Tim Robinson]

I'm not involved in the development of this client library - I'm just
glad to see it get started. Many thanks to the folks a basho for
considering a Clojure client worthy of being on their roadmap.

https://github.com/reiddraper/sumo

Tim

-Original Message-
From: "Reid Draper" 
Sent: Thursday, December 22, 2011 8:45am
To: riak-us...@lists.basho.com
Subject: sumo: a riak clojure client

___
riak-users mailing list
riak-us...@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
All,

A few of us [1] have been working on a Riak Clojure client, and I
figured
there is enough now to open source. There is currently basic key/value
functionality present. Check it out here: https://github.com/reiddraper/sumo

[1]: myself, *Brett Hoerner and *Justin Shoffstall

-- 
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: Alternative structures to arrays?

[Tassilo Horn]

Daniel Janus  writes:

Hi Daniel,

>> > Vectors are actually a great trade-off, giving you almost the same
>> > access and memory costs arrays do, but with all the advantages of
>> > being immutable (multi-threaded goodness).
>>
>> On the other hand, you can have arrays of primitives but no vector of
>> primitives.  
>>
> This is not quite correct: see vector-of.

Oh, indeed.  Thanks for proving me wrong.

Bye,
Tassilo

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

Re: Literate programming

[daly]

On Tue, 2011-12-20 at 00:26 -0800, Adam Getchell wrote:
> 
> 
> On Fri, Oct 28, 2011 at 2:45 PM, Damion Junk  wrote:
> I have also been using Emacs/Org-mode/Babel/R lately, mostly
> as a way to have easily modifiable write up and source code
> for assignments in statistics courses. I suppose this is one
> valid use, but I'm using it less to communicate code meaning
> and more as a convenient way to perform analysis, look at the
> results, and talk about them all in the same place, and then
> to easily generate documentation of my efforts [LaTeX output].
> 
> 
> I'm interested in how you're including LaTeX in your code, as I'm
> writing models which require LaTeX to express what they're modelling.
> 
> 
> BTW I looked at marginalia+leiningen, which seems to work for my
> purposes except I'm unclear where to put the .tex files. 

I'm not sure what this sentence means. The .tex files ARE the
literate program. By analogy, you seem to be asking something like
"I'm writing a book but I don't know where to put the text".

> 
> 
> The combination of literate + TDD seems forbidding.

Are you finding it hard to explain why you wrote a test?

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

[Larry Johnson]

On Thu, Dec 22, 2011 at 2:54 PM, daly  wrote:

>
> >
> > The combination of literate + TDD seems forbidding.
>
> Are you finding it hard to explain why you wrote a test?
>
> Tim Daly
>
>
I decided awhile back when trying to answer questions about literate
programming, that people get caught up in the moving parts, and not in what
the approach actually yields.  Your statement above puts it nicely and
succinctly, and hearkens back to Knuths original articles.  Lately I
emphasize the woven text (without inititially calling it that) and ask the
person I'm talking with to imagine writing an article or book about their
code, how it works, with proofs where appropriate.  That article should be
written as a work of literature.  Not all literature has to be Hugo or
Melville (or Jack Kerouac, or Gertrude Stein for that matter).  Some
programs are more appropriately Mickey Spillane or Terry Pratchett, or even
in the style of a manual for an electric razor.  The point is that it
should be satisfying to read and comprehensively informative.

Test code, and descriptions of external libraries are no different from any
other sections of the article or book.  The most important thing is to
introduce them into the work at point most conducive to the reader's
understanding.

I really believe that there's no programming or engineering methodology
which doesn't lend itself to literate programming.  If it can be described,
it can be presented in the form of an article.  If it can't be describe in
human language it's probably terrible code.

Larry

-- 
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

[daly]

On Thu, 2011-12-22 at 15:35 -0500, Larry Johnson wrote:
> 
> 
> On Thu, Dec 22, 2011 at 2:54 PM, daly 
> wrote:
> 
> >
> > The combination of literate + TDD seems forbidding.
> 
> 
> Are you finding it hard to explain why you wrote a test?
> 
> Tim Daly
> 
> 
> 
> I decided awhile back when trying to answer questions about literate
> programming, that people get caught up in the moving parts, and not in
> what the approach actually yields.  Your statement above puts it
> nicely and succinctly, and hearkens back to Knuths original articles.
> Lately I emphasize the woven text (without inititially calling it
> that)

Untangling woven text is trivial. It can be done in any language. See
http://axiom-developer.org/axiom-website/litprog.html

>  and ask the person I'm talking with to imagine writing an article or
> book about their code, how it works, with proofs where appropriate.
> That article should be written as a work of literature.  Not all
> literature has to be Hugo or Melville (or Jack Kerouac, or Gertrude
> Stein for that matter).  Some programs are more appropriately Mickey
> Spillane or Terry Pratchett, or even in the style of a manual for an
> electric razor.  The point is that it should be satisfying to read and
> comprehensively informative.
> 
> Test code, and descriptions of external libraries are no different
> from any other sections of the article or book.  The most important
> thing is to introduce them into the work at point most conducive to
> the reader's understanding.

If a test is testing something worthwhile, as opposed to the "blindly
testing that 3=3" mindset, then it probably only takes a couple lines
to motivate why you need the test. A test paragraph could contain the
details. So if you're writing a hash table implementation, the test
code of overflow chaining could explain what problems might occur (e.g.
what happens when the table is actually full? How do you detect that
the overflow chain has looped?, etc.)

So if you wrote the hash table implementation code in literate form
then each test could explain (and test) a particular boundary case or
issue that might arise. 

This has the effect of motivating tests that are detailed, based on 
real issues, and handle boundary cases clearly.

> 
> I really believe that there's no programming or engineering
> methodology which doesn't lend itself to literate programming.  If it
> can be described, it can be presented in the form of an article.  If
> it can't be describe in human language it's probably terrible code.

Test cases don't have to appear as "test cases". They appear in the
text as either example code (useful for the reader but also testing)
or as explanations of possible failures, misuse, misapplication, or
boundary cases.

This is especially powerful if you focus your tests on 
precondition/postcondition testing. See Hoare's paper 
"An Axiomatic Basis for Computer Programming"
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.116.2392

Using Hoare's ideas to focus the development of your test cases means
that your tests have a good theoretical basis. They check for the
conditions that should survive refactoring. Requiring precondition
postcondition tests, along with clearly written natural language
explanations, could be part of the peer code review prior to
accepting new or revised code into the main line.

Better yet, in a literate program, you can explain what the invariant
is, why it is important, and what breaks when you violate it. So
testing now has a good formal basis rather than random 3=3 tests.

We can be so much better programmers. 
Raise your game.
Be literate.

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

Why are body-macros more fashionable than thunks?

[Peter Danenberg]

Scheme, for instance, obeys the Law of Macro-Parsimony: "don't use
defmacro," namely, "where defn will suffice;" Clojure, on the other
hand, is macro-liberal.

In other words, everyone seems to prefer e.g. `(defmacro foo [vars &
body] `(do ... ~@body))' where `(defn foo [vars thunk] ... (thunk))' would
suffice; cases in point:

  with-bindings 
  with-bindings* 
  with-in-str 
  with-local-vars 
  with-open 
  with-out-str 
  with-precision 
  with-redefs 

Why?

-- 
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: Why are body-macros more fashionable than thunks?

[Cedric Greevey]

On Thu, Dec 22, 2011 at 4:54 PM, Peter Danenberg  wrote:
> Scheme, for instance, obeys the Law of Macro-Parsimony: "don't use
> defmacro," namely, "where defn will suffice;" Clojure, on the other
> hand, is macro-liberal.
>
> In other words, everyone seems to prefer e.g. `(defmacro foo [vars &
> body] `(do ... ~@body))' where `(defn foo [vars thunk] ... (thunk))' would
> suffice; cases in point:
>
>  with-bindings
>  with-bindings*
>  with-in-str
>  with-local-vars
>  with-open
>  with-out-str
>  with-precision
>  with-redefs
>
> Why?

Syntax convenience. Less need for #(...) lambdas cluttering the code.
Particularly helpful when nested, since the #(...) lambda syntax
doesn't nest and you'd start needing (fn [x y] ...)s as well.

Also, if the macro isn't implemented with a thunk passed to a helper
function under the hood, the macro saves a couple of stack frames, and
on the JVM stack can run out relatively easily. With chained lazy
functions (e.g. (map (filter (map (... (partition 3 some-seq)) and
recursion this becomes even more significant.

Lastly, in some cases avoiding function calls may save having to box
and unbox primitives, though less so with 1.3 than with previous
versions 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: Why are body-macros more fashionable than thunks?

[Kevin Downey]

On Thu, Dec 22, 2011 at 1:54 PM, Peter Danenberg  wrote:
> Scheme, for instance, obeys the Law of Macro-Parsimony: "don't use
> defmacro," namely, "where defn will suffice;" Clojure, on the other
> hand, is macro-liberal.
>
> In other words, everyone seems to prefer e.g. `(defmacro foo [vars &
> body] `(do ... ~@body))' where `(defn foo [vars thunk] ... (thunk))' would
> suffice; cases in point:
>
>  with-bindings
>  with-bindings*
>  with-in-str
>  with-local-vars
>  with-open
>  with-out-str
>  with-precision
>  with-redefs
>
> Why?
>

with-open is the only thing on the list I use regularly.

with-bindings* does actually take a thunk.

fns are not free. every (fn* …) in macroexpanded source results in a new class.

that being said I tend to take hairier macros and turn them into pairs
of functions that take a thunk and macros that wrap their bodies in a
thunk.

Why do you care?

> --
> 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



-- 
And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

-- 
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: Why are body-macros more fashionable than thunks?

[Peter Danenberg]

Thanks, Cedric: I suspected that convenience was a primary motivation
(and maybe analogy with `defn', etc.); and I realized that macros can
be more efficient than their equivalent function.

It hadn't occurred to me, though, that a shallow stack might come into
play; or {un,}boxing, of all things.

Quoth Cedric Greevey on Sweetmorn, the 64th of The Aftermath:
> On Thu, Dec 22, 2011 at 4:54 PM, Peter Danenberg  wrote:
> > Scheme, for instance, obeys the Law of Macro-Parsimony: "don't use
> > defmacro," namely, "where defn will suffice;" Clojure, on the other
> > hand, is macro-liberal.
> >
> > In other words, everyone seems to prefer e.g. `(defmacro foo [vars &
> > body] `(do ... ~@body))' where `(defn foo [vars thunk] ... (thunk))' would
> > suffice; cases in point:
> >
> >  with-bindings
> >  with-bindings*
> >  with-in-str
> >  with-local-vars
> >  with-open
> >  with-out-str
> >  with-precision
> >  with-redefs
> >
> > Why?
> 
> Syntax convenience. Less need for #(...) lambdas cluttering the code.
> Particularly helpful when nested, since the #(...) lambda syntax
> doesn't nest and you'd start needing (fn [x y] ...)s as well.
> 
> Also, if the macro isn't implemented with a thunk passed to a helper
> function under the hood, the macro saves a couple of stack frames, and
> on the JVM stack can run out relatively easily. With chained lazy
> functions (e.g. (map (filter (map (... (partition 3 some-seq)) and
> recursion this becomes even more significant.
> 
> Lastly, in some cases avoiding function calls may save having to box
> and unbox primitives, though less so with 1.3 than with previous
> versions 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
> 

-- 
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: Why are body-macros more fashionable than thunks?

[Peter Danenberg]

Quoth Kevin Downey on Sweetmorn, the 64th of The Aftermath:
> Why do you care?

SICP-forged neural pathways, basically; I'll end up writing e.g.:

  (defn with-input-from-file [file thunk] ...)

only to censor myself: "shit, we don't do thunks."

At that point, I'll bust out `defmacro' with reluctance.

-- 
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: Why are body-macros more fashionable than thunks?

[Meikel Brandmeyer]

Hi,

passing thunks and macros are not mutually exclusive. with-bindings and 
with-bindings* are an example you gave yourself. I often use this style with a 
convenience macro and a driver function. Benefits besides the named drawbacks 
are reduced code size (depending on number of calls vs. class size for the 
additional thunk) and - in my eyes very nice - you can easily reload the driver 
function and all call sites see the new function without recompilation. And 
still have the convenience of macros.

Which way to go with macros depends on the circumstances and the corresponding 
trade-offs.

Sincerely
Meikel

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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

Mechanism for escaping of predefined entities missing in clojure.xml

[Linus Ericsson]

Hi!

I have been in the wondrous world of XML-parsing last week and I've found a
missing mechanism in clojure.xml - the escaping the predefined entities:

Example:
(use 'clojure.xml)

(def xmlelem (parse (new org.xml.sax.InputSource (new java.io.StringReader
"" ;; parsing string 

xmlelem   ;; looks like this:
{:tag :tag, :attrs {:greet "Clojure&co"}, :content nil}

(emit-element xmlelem)


This output is not standard compliant and is not even re-parseable with the
code above. The problem is the sole ampersand (&).

Wikipedia [1] says

There are five *predefined entities*:

   - < represents "<"
   - > represents ">"
   - & represents "&"
   - ' represents '
   - " represents "


Would it be a good idea to make a small search-and-replace function to call
from emit-element and escape these chars in the string when nescessary?
Today there is no such mechanism in clojure.xml, but it would be simple to
implement.

The singlequote is easily changed in the emit-element function if needed -
is there anyone interested in options for this? The escaper for predefined
entities would be of general interest, I think.

Should I put this in Jira? Should I try to make a patch and send to
someone? This would be my first commit so I would be most grateful if
someone just gave an acknowledge of any kind so I'm not entirely off track.

[1] http://en.wikipedia.org/wiki/Xml

/Linus

-- 
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: Why are body-macros more fashionable than thunks?

[Alan Malloy]

with-open and with-local-vars couldn't be thunks - the whole point is
creating some lexical variables in the caller's scope. Instead of
(with-open [f (file)] (stuff f)) you could require (open-callback (fn
[f] (stuff f)) (file)): either could expand into something like ((fn
[f] (stuff f)) (file)), but at that point you're just transforming let
into fn for fun, and costing yourself efficiency in exchange.

On Dec 22, 1:54 pm, Peter Danenberg  wrote:
> Scheme, for instance, obeys the Law of Macro-Parsimony: "don't use
> defmacro," namely, "where defn will suffice;" Clojure, on the other
> hand, is macro-liberal.
>
> In other words, everyone seems to prefer e.g. `(defmacro foo [vars &
> body] `(do ... ~@body))' where `(defn foo [vars thunk] ... (thunk))' would
> suffice; cases in point:
>
>   with-bindings
>   with-bindings*
>   with-in-str
>   with-local-vars
>   with-open
>   with-out-str
>   with-precision
>   with-redefs
>
> Why?

-- 
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/TDD with Leiningen + midje + marginalia

[Alex Baranosky]

Hi Adam,

It seems like making it so that Marginalia allows you to specify which
directories to use would be the ideal case, instead of feeling a need to
lump all your tests in the src directory.

I wonder if Marginalia already supports this?

Alex

On Wed, Dec 21, 2011 at 11:25 PM, Adam Getchell wrote:

> Thanks for all the replies!
>
> I'm trying midje first (keeping expectations in mind for later) as it
> seems to support writing tests and then code (i.e. top down testing).
>
> (This video  was
> useful, thanks for making it!)
>
> In generating documentation with marginalia (particularly useful for when
> I figure out how to get LaTeX formulae in there), I note that marginalia
> doesn't pickup files in /test but only /src. So it seems that I need to
> embed tests directly in my code in order to self-document.
>
> Is this a huge no-no, better ways to accomplish this?
>
> P.S. (Newbie) what's the difference between (:use [clojure.test])
> and (:use midje.sweet)? Both seem to work.
>
> --
> "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu
>
> --
> 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: Why are body-macros more fashionable than thunks?

[Brian Hurt]

On Thu, Dec 22, 2011 at 5:10 PM, Kevin Downey  wrote:

>
> fns are not free. every (fn* …) in macroexpanded source results in a new
> class.
>
>
This is only a problem with respect to load times- clojure tends to make
java's already long load times even longer.

Actual function call costs are pretty low.  Doing a variable dereference is
somewhat expensive.

That being said, in defense of functions-
- You can pass them around, store them in data structures, etc.
- You can compose them.
- You can rebind variables, allowing you to wrap functions (for tracing,
memoization, etc), reload modules in working code, etc.
- The JVM has a limit of 64K instructions in a function.  I have hit cases
where too many macro expansions produced such huge functions.
- Many


> that being said I tend to take hairier macros and turn them into pairs
> of functions that take a thunk and macros that wrap their bodies in a
> thunk.
>
> Why do you care?
>
> > --
> > 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
>
>
>
> --
> And what is good, Phaedrus,
> And what is not good—
> Need we ask anyone to tell us these things?
>
> --
> 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: Why are body-macros more fashionable than thunks?

[Brian Hurt]

Gah, hit send before I meant to.

On Thu, Dec 22, 2011 at 7:03 PM, Brian Hurt  wrote:

>
> That being said, in defense of functions:
>

-Many JVMs don't optimize large functions, or optimize them less
aggressively.

So there are reasons to use functions, even functions called via
dereferencing variables, over macros.

Brian

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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: How to use *command-line-args* ?

[Kevin Lynagh]

If you need parsing that is any more complicated, check out

https://github.com/clojure/tools.cli

which handles flags, arguments, and generating --help banners.


On Dec 21, 7:52 pm, Antonio Recio  wrote:
> Solved:
> (read-write-image (nth *command-line-args* 0) (nth *command-line-args* 1))

-- 
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/TDD with Leiningen + midje + marginalia

[Linus Ericsson]

Yes, it does. I had problems with some midje-facts crashing the rendering
in marginalia, but was able to just give the files as consecutive arguments
as a work around.

lein marg src/app/core.clj src/app/another/file.clj

wildcards works fine as well.

This problem with midje-facts being incompatible with marginalia needs
further investigation from my side though.

btw - is there a possibility to hide comments in emacs/slime? Midje-mode
have this great feature of collapsing fact-clausules for reducing clutter.
Would love to have the same thing when I have pages and pages of comments.

/Linus

2011/12/23 Alex Baranosky 

> Hi Adam,
>
> It seems like making it so that Marginalia allows you to specify which
> directories to use would be the ideal case, instead of feeling a need to
> lump all your tests in the src directory.
>
> I wonder if Marginalia already supports this?
>
> Alex
>
>
> On Wed, Dec 21, 2011 at 11:25 PM, Adam Getchell 
> wrote:
>
>> Thanks for all the replies!
>>
>> I'm trying midje first (keeping expectations in mind for later) as it
>> seems to support writing tests and then code (i.e. top down testing).
>>
>> (This video  was
>> useful, thanks for making it!)
>>
>> In generating documentation with marginalia (particularly useful for when
>> I figure out how to get LaTeX formulae in there), I note that marginalia
>> doesn't pickup files in /test but only /src. So it seems that I need to
>> embed tests directly in my code in order to self-document.
>>
>> Is this a huge no-no, better ways to accomplish this?
>>
>> P.S. (Newbie) what's the difference between (:use [clojure.test])
>> and (:use midje.sweet)? Both seem to work.
>>
>> --
>> "Invincibility is in oneself, vulnerability in the opponent." -- Sun Tzu
>>
>> --
>> 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
>

-- 
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

[Larry Johnson]

Probably the most effective way to really hammer the benefits of literate
programming into the clojure community would be to take a manageable but
serious and well known clojure program, module, or library, and render it
into literate form.  As a clojure programmer, I'm not even there.  But as
someone to help with the literate part, I'd be thrilled to help out.

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

Re: multiple return values

[Brian Goslinga]

On Dec 22, 8:52 am, Razvan Rotaru  wrote:
> What do you mean by site?
> For example, how is it when I'm creating my proxy inside a macro? (and
> assuming this macro is called many times)
>
> (defmacro [a-class]
>     (proxy (a-class) ))
>
> Razvan
Once all code is macroexpanded, every use of proxy (actually what
proxy expands into) will result in a new class.

-- 
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

[nchurch]

Why should I write English in the first place?  Because it helps me to
think; and it helps me to "program" other people to think like me.
But I would never have learned English unless along the way it gave me
near-term results.  It should follow, then, that telling people to
write literate programs for the sake of posterity is never going to be
enough to change mindsets.  Taking an illiterate [sic] program and
making it literate as you are doing with Clojure will be a tour-de-
force, and an intimidating one at that.  I think that making literate
programming incrementally useful, however, is \inevitably going to
involve tooling.

Of two kinds, if you follow the logic above: social, and personal.
Firstly, there really needs to be something like a Github for literate
programming.  Why?  Because a literate program will be easier to
\understand, but also easier to \find (see example below).  Imagine a
sort of "function search engine"code liberated from namespaces and
leiningen projects, annotated and independently useable.  If there
were a community that actually \took \advantage of findability and
understandability, it would greatly speed coding (think of how much
time you have to spend hunting for documentation), and in the process
not only \promote literate programming but make it \advantageous.

On the personal side, writing English as part of coding has to be
maximally efficient for us humans: no retyping.  The identifiers we
use in English should flow into the code, and vice-versa.  Take the
following example:

To CAPITALIZE EVERY WORD in a STRING:
Split the STRING on SPACE into WORDS;
CAPITALIZE the first letter of every WORD, producing CAPITALIZED
WORDS.
Re-assemble[JOIN] the string on SPACE, to make the CAPITALIZED
STRING.

Using functions from clojure.string: split, join, capitalize; see
documentation:
http://docs.oracle.com/javase/1.5.0/docs/api/java/util/regex/Pattern.html
http://clojure.org/other_functions
http://www.fatvat.co.uk/2009/01/regular-expressions-in-clojure.html
http://clojure.github.com/clojure/clojure.string-api.html

(defn capitalize-every-word [m-string]
  (let [m-space " "
regex-space #"\s"
words (split m-string regex-space)
capitalized-words (map capitalize words)
capitalized-string (join m-space capitalized-words)]
capitalized-string))

(defn c-e-w [m-string]
  (join " " (map capitalize (split m-string #"\s"

Now there is actually not that much novel text here, and typing it out
was an enlightening exercise (to really see how enlightening, you'd
have to see the full example; but I've omitted it because the
Internets are already complaining about a long post not written in
their native Twitterese).  But it was  very cumbersome and time-
consuming to do it.  This cumbersomeness was incidental: because my
activities were split among editing, browsing, and coding, for one
thing; and also (not a complaint, Rich!) because our programming
languages do not incorporate basic English concepts like abbreviation
and definition-in-place.

(One of the big advantages of writing English along with code is that
you come up with sensible identifiers.  Without English, it's a
puzzling exercise done completely out of context.)

You can't tell me this isn't a problem for IDE's to handle.  At a
minimum, I want my IDE to link up the identifiers between code and
English.  If they do, look at what happens: the identifiers get
enriched by natural language context (notice, for instance, how JOIN
gets associated with 'assemble'), and if we push everything to our
social tool, the code ends up with more paths to be located by.

We don't yet have Google-level findability for code, of course; but I
would argue that this is not a technological defect, it is simply a
failure of description!  Once we have literate code, Google will build
a function search engine for us.


-- 
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: multiple return values

[Alan Malloy]

On Dec 22, 5:48 pm, Brian Goslinga  wrote:
> On Dec 22, 8:52 am, Razvan Rotaru  wrote:> What do 
> you mean by site?
> > For example, how is it when I'm creating my proxy inside a macro? (and
> > assuming this macro is called many times)
>
> > (defmacro [a-class]
> >     (proxy (a-class) ))
>
> > Razvan
>
> Once all code is macroexpanded, every use of proxy (actually what
> proxy expands into) will result in a new class.

It turns out even this is not true, because proxy uses some kind of
deep JVM magic called (appropriately) Proxy Classes. So every time you
write (proxy [Object] (...anything at all...)), you get an instance of
the same class, initialized with a different map of function pointers.
That is, for any superclass and set of interfaces, exactly one proxy
class exists (possibly one per namespace?), of which all such proxy
objects are instances.

-- 
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

Matching core.match's syntactic keywords

[Herwig Hochleitner]

Hi,

I want to match vectors of the form [(some expr) :as :label], but  #(match
[%] [[expr :as (label :when keyword)]] {:expr expr :label label}) throws a
compiler exception: Unable to resolve symbol expr

How do I do this?

kind regards
-- 
__
Herwig Hochleitner

-- 
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

[daly]

On Thu, 2011-12-22 at 17:53 -0800, nchurch wrote:
> Firstly, there really needs to be something like a Github for literate
> programming.  

What a great idea!
I'll see what I can do.

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

[nchurch]

I'll do everything I can to help.  I have tons of thoughts (as you
might guess); but I haven't demonstrated myself to be a great coder,
yet.  I feel like I'm a coder who needs something like literate
programming to be great, so it's kind of a chicken-and-egg problem.
I'm already partway there with the existence of Clojure, but although
it's the most intelligent language I've every come across (and it is
at least Lisp), it still isn't enough.

On Dec 22, 11:14 pm, daly  wrote:
> On Thu, 2011-12-22 at 17:53 -0800, nchurch wrote:
> > Firstly, there really needs to be something like a Github for literate
> > programming.
>
> What a great idea!
> I'll see what I can do.
>
> 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

[nchurch]

While we're on the topic of a literate Github, let me just point out
that we might want to go just a little beyond Github to the way we
write code itself.  Look again at the capitalize-every-word function I
defined above.  In my original unshortened commentary, I included also
this:

.
To split a string into words (in the simplest case):
Split the string on a separator, the canonical one being space, but
also including punctuation characters such as ",';:./(){}-+_|\
BUT: Re-assembling the string will not reproduce the old string in
general unless space is the only character that splits.  In order to
preserve this simple abstraction, we would need to rewrite split and
assemble.  We could also change the string in-place.

Ossia: To split a string into words:
Split the string on space.  Use clojure.string/split.
.

You can see that I am writing here not only about the current good-
enough implementation, but a \future implementation, should it ever be
needed.  In fact, I discovered a bug in my code before I ever wrote
the code; but the question is what to do about the bug!

What I really want you to notice is how we are faced with a choice:
either we improve the library code (presumably by making split
optionally return an array of separators matched by the regex for
later reassembly by join, perhaps in metadata of some sort), or we go
with a less felicitous abstraction.  There probably should be some
sort of formal analogue to this decision point in the natural language
text.

What does this mean for a Github?  It may meanand no doubt this
will be controversialthat once we have the capability of a
function search engine, we don't really worry about there being
canonical library code any more.  If I face this particular problem,
maybe I decide to re-write Join and Split to my own specifications.  I
then put them out there under my own namespace, and when someone needs
to use them they just type (use '[nchurch :only join split]) wherever
they are in their file, or whatever the exact incantation is (this is
one place I always need to go to the docs).  They have no trouble
browsing multiple alternatives, because they can see at a glance how
each one differs.

Now we have possibly multiple joins and splits; and so the community
no longer has a standard!  Well, it would seem to me this fits well
with Github's always-fork philosophy.  I do think there is only one
way to write a good library function, but it may be that there will
need to be a proliferation of alternativeseach making its own
argument and tradeoffs across various levels of abstraction, to return
to the theme of literate programmingbefore an optimal basis is
discovered.  (There must have been a time before phillips head vs.
regular.)  And when that happens, perhaps it goes into
clojure.string (modulo legalities about contributor agreements
something that might also be handled at the Github level, by the
way.).








On Dec 22, 11:19 pm, nchurch  wrote:
> I'll do everything I can to help.  I have tons of thoughts (as you
> might guess); but I haven't demonstrated myself to be a great coder,
> yet.  I feel like I'm a coder who needs something like literate
> programming to be great, so it's kind of a chicken-and-egg problem.
> I'm already partway there with the existence of Clojure, but although
> it's the most intelligent language I've every come across (and it is
> at least Lisp), it still isn't enough.
>
> On Dec 22, 11:14 pm, daly  wrote:
>
>
>
>
>
>
>
> > On Thu, 2011-12-22 at 17:53 -0800, nchurch wrote:
> > > Firstly, there really needs to be something like a Github for literate
> > > programming.
>
> > What a great idea!
> > I'll see what I can do.
>
> > 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

[Cedric Greevey]

On Thu, Dec 22, 2011 at 11:59 PM, nchurch  wrote:
> What I really want you to notice is how we are faced with a choice:
> either we improve the library code (presumably by making split
> optionally return an array of separators matched by the regex for
> later reassembly by join, perhaps in metadata of some sort), or we go
> with a less felicitous abstraction.  There probably should be some
> sort of formal analogue to this decision point in the natural language
> text.

Seems to me that the structure is this:

A string that's written language is some alternating form like

word separator word separator ...

where a "word" consists of consecutive alphanumeric characters and a
"separator" consists of consecutive nonalphanumeric characters. The
separators in this paragraph include " ", " \"", "\" ", ". ", and " \"
\", \" \\\"\", \"\\\" \", \". \", ", as well as one more that I can't
add here without generating one more still.

One tends sometimes to want to split a string in such a fashion,
transform the words only, and then reassemble.

This in turn suggests tools like:

(wordify string) -> a seq of strings starting with a separator and
alternating words and separators. The initial separator may be "".
Something like (map #(apply str %) (group-by alphanumeric? string))
with alphanumeric? testing a character, but if the first character of
the first string in the output seq is alphanumeric, a (cons "" %)
needs to be done on the output before returning it.

(map-words* f wordified-string) -> (interleave (take-nth 2
wordified-string) (map f (take-nth 2 (next wordified-string

(map-words f string) -> (apply str (map-words* f (wordify string)))

or similar.

-- 
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