Re: leiningen: RuntimeException: Unable to resolve symbol: doc in this context

2012-10-27 Thread AtKaaZ 
I believe I've hit this with 1.5.0-alpha6 or so(or maybe i was using the
master branch) in eclipse+ccw
after a while in repl: doc and source wouldn't work like you described and
I'd have to (use 'clojure.repl)
But in the same repl session worked a few minutes before.

Do you think this commit fixes it or is the one that made it happen in the
first place?

On Sat, Oct 27, 2012 at 10:43 PM, Marek Šrank wrote:

> Oh yes, I've found the commit
> https://github.com/clojure/clojure/commit/728972b026a323fc941a5d560b81d37453dc6cad.
>  I should look at the commits first
>
> Marek.
>
> On Saturday, October 27, 2012 10:26:22 PM UTC+2, Marek Šrank wrote:
>>
>> Please ignore that github link. I somehow got the feeling that it's about
>> a bug in leiningen (really don't know why :), but now I see that it's
>> (probably) totally unrelated :D
>> Marek
>>
>> On Saturday, October 27, 2012 10:20:34 PM UTC+2, Marek Šrank wrote:
>>>
>>> When using [org.clojure/clojure "1.5.0-beta1"] in my project.clj,
>>> calling: (doc function) gives me this exception:
>>>
>>> CompilerException java.lang.RuntimeException: Unable to resolve symbol:
>>> doc in this context, compiling:(NO_SOURCE_PATH:1:1)
>>>
>>> And similarly with find-doc, source, javadoc and clojuredocs.
>>>
>>> With clojure 1.5.0-alpha7 or below, it works normally like it always
>>> worked...
>>>
>>> Can this be a bug in a Clojure (or Leiningen)?
>>>
>>> I've found this 
>>> https://github.com/**trptcolin/reply/issues/17but
>>>  for me it works in 1.5.0-alpha7 or below and not in 1.5.0-beta1 so I
>>> conclude that it must be somehow connected with recent changes in Clojure
>>> itself...
>>>
>>> Marek
>>>
>>  --
> 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
>



-- 
I may be wrong or incomplete.
Please express any corrections / additions,
they are encouraged and appreciated.
At least one entity is bound to be transformed if you do ;)

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

Re: Bug in CLJS compiler?

2012-10-27 Thread David Nolen 
On Sat, Oct 27, 2012 at 8:19 AM, Tim  wrote:

> While playing around with a little test website I came across what, I
> believe to be a bug in the CLJS compiler.  It seems like the generation of
> symbols for use in macros (e.g. var#) is broken when compiled into certain
> JavaScript forms.
>

This has been fixed in master.

-- 
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: CLJS: println stopped working (r1514) ?

2012-10-27 Thread David Nolen 
On Tue, Oct 23, 2012 at 4:18 PM, Frank Siebenlist <
frank.siebenl...@gmail.com> wrote:

> Bump.
>
> Could someone please confirm that printing from the repl doesn't work
> anymore?
>
> Thanks, Frank.


I just checked browser REPL on CLJS master - it works fine for me.

David

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
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: leiningen: RuntimeException: Unable to resolve symbol: doc in this context

2012-10-27 Thread Marek Šrank 
Oh yes, I've found the commit 
https://github.com/clojure/clojure/commit/728972b026a323fc941a5d560b81d37453dc6cad
 
. I should look at the commits first

Marek.

On Saturday, October 27, 2012 10:26:22 PM UTC+2, Marek Šrank wrote:
>
> Please ignore that github link. I somehow got the feeling that it's about 
> a bug in leiningen (really don't know why :), but now I see that it's 
> (probably) totally unrelated :D
> Marek
>
> On Saturday, October 27, 2012 10:20:34 PM UTC+2, Marek Šrank wrote:
>>
>> When using [org.clojure/clojure "1.5.0-beta1"] in my project.clj, 
>> calling: (doc function) gives me this exception:
>>
>> CompilerException java.lang.RuntimeException: Unable to resolve symbol: 
>> doc in this context, compiling:(NO_SOURCE_PATH:1:1)
>>
>> And similarly with find-doc, source, javadoc and clojuredocs.
>>
>> With clojure 1.5.0-alpha7 or below, it works normally like it always 
>> worked...
>>
>> Can this be a bug in a Clojure (or Leiningen)?
>>
>> I've found this https://github.com/trptcolin/reply/issues/17 but for me 
>> it works in 1.5.0-alpha7 or below and not in 1.5.0-beta1 so I conclude that 
>> it must be somehow connected with recent changes in Clojure itself...
>>
>> Marek
>>
>

-- 
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: leiningen: RuntimeException: Unable to resolve symbol: doc in this context

2012-10-27 Thread Marek Šrank 
Please ignore that github link. I somehow got the feeling that it's about a 
bug in leiningen (really don't know why :), but now I see that it's 
(probably) totally unrelated :D
Marek

On Saturday, October 27, 2012 10:20:34 PM UTC+2, Marek Šrank wrote:
>
> When using [org.clojure/clojure "1.5.0-beta1"] in my project.clj, calling: 
> (doc function) gives me this exception:
>
> CompilerException java.lang.RuntimeException: Unable to resolve symbol: 
> doc in this context, compiling:(NO_SOURCE_PATH:1:1)
>
> And similarly with find-doc, source, javadoc and clojuredocs.
>
> With clojure 1.5.0-alpha7 or below, it works normally like it always 
> worked...
>
> Can this be a bug in a Clojure (or Leiningen)?
>
> I've found this https://github.com/trptcolin/reply/issues/17 but for me 
> it works in 1.5.0-alpha7 or below and not in 1.5.0-beta1 so I conclude that 
> it must be somehow connected with recent changes in Clojure itself...
>
> Marek
>

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

leiningen: RuntimeException: Unable to resolve symbol: doc in this context

2012-10-27 Thread Marek Šrank 
When using [org.clojure/clojure "1.5.0-beta1"] in my project.clj, calling: 
(doc function) gives me this exception:

CompilerException java.lang.RuntimeException: Unable to resolve symbol: doc 
in this context, compiling:(NO_SOURCE_PATH:1:1)

And similarly with find-doc, source, javadoc and clojuredocs.

With clojure 1.5.0-alpha7 or below, it works normally like it always 
worked...

Can this be a bug in a Clojure (or Leiningen)?

I've found this https://github.com/trptcolin/reply/issues/17 but for me it 
works in 1.5.0-alpha7 or below and not in 1.5.0-beta1 so I conclude that it 
must be somehow connected with recent changes in Clojure itself...

Marek

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

ANN: data.json 0.2.1 and tools.namespace 0.2.1

2012-10-27 Thread Stuart Sierra 
[org.clojure/data.json "0.2.1"]
  * restores deprecated API functions from 0.1.x releases
  * recommended over 0.2.0, which broke code that depended on the old API

[org.clojure/tools.namespace "0.2.1"]
  * minor bugfix
  * restores deprecated API functions from 0.1.x releases
  * recommended over 0.2.0, which broke code that depended on the old API
  * still may not work alongside other code-reloading tools, see 
 https://github.com/clojure/tools.namespace#warnings

-- 
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: with-open and line-seq

2012-10-27 Thread Devin Walters 
Yeah, `read-lines` is what I was referring to. 

-- 
Devin Walters


On Friday, October 26, 2012 at 9:10 PM, Andy Fingerhut wrote:

> Devin, did you mean read-line from the old clojure.contrib.io 
> (http://clojure.contrib.io)?
> 
> http://clojuredocs.org/clojure_contrib/clojure.contrib.io/read-lines
> 
> Click the "+" symbol next to "Source" to see source code, also available here:
> 
> https://github.com/richhickey/clojure-contrib/blob/061f3d5b45657a89faa335ffa2bb80819f2e6918/src/main/clojure/clojure/contrib/io.clj#L302
> 
> Andy
> 
> On Oct 26, 2012, at 5:23 PM, Devin Walters wrote:
> 
> > I usually wind up with the line-seq from old contrib. Could you be more 
> > clear about what isn't satisfying about that? For me it usually boils down 
> > to: it's unsatisfying that core line-seq doesn't do that by default.
> > 
> > '(Devin Walters)
> > 
> > On Oct 26, 2012, at 6:45 PM, Dave Ray  > (mailto:dave...@gmail.com)> wrote:
> > 
> > > Hi,
> > > 
> > > At work I've had a few conversations about treating files, especially
> > > large ones, as seqs of lines. In particular, the apparent conflict
> > > between using clojure.core/with-open to ensure a file is closed
> > > appropriately, and clojure.core/line-seq as a generic sequence of
> > > lines which may be consumed by code that has no idea it's coming from
> > > a file. I've been told [1] that C# solves this problem because the
> > > IEnumerator interface is disposable so it's possible to clean up the
> > > underlying file, even if it's been wrapped in several layers of
> > > enumerators... and that since Clojure doesn't do this, it's flawed :)
> > > 
> > > Thoughs? I'm aware of the "custom seq that closes the file when the
> > > end is reached" hack, but that doesn't seem very satisfying. How do
> > > others process large files in Clojure? Just make sure that the
> > > sequence is totally consumed within with-open? Just don't worry about
> > > closing files?
> > > 
> > > Cheers,
> > > 
> > > Dave
> > > 
> > > 
> > > [1] My C# experience is limited to a few days of writing example code
> > > for the C# bindings of a product's API. :)
> > > 
> > > -- 
> > > 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 
> > > (mailto: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 
> > > (mailto: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 
> > (mailto: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 
> > (mailto: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 
> (mailto: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 
> (mailto: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: monads

2012-10-27 Thread Armando Blancas 
I found these articles very valuable in understanding the original 
motivation for monads and their use for practical development.

Imperative Functional Programming
Simon Peyton Jones, Philip Wadler
http://research.microsoft.com/pubs/67066/imperative.ps.z

Monadic Parser Combinators
Graham Hutton
http://eprints.nottingham.ac.uk/237/1/monparsing.pdf

On Friday, October 26, 2012 9:06:59 AM UTC-7, Brian Craft wrote:
>
> I've read about four tutorials on monads so far, but it still escapes me.
>
> In fact, I'm still not sure what problem it solves. I'm familiar with the 
> problem of having, say, three functions like f(a) -> b, g(c) -> d, h(e) -> 
> f, which you'd like to chain like f(g(h(x))), but you can't because b is a 
> different type from c and d is a different type from e. The monad tutorials 
> all start with a problem like this, but I still can't tell if they're 
> actually providing a solution, because it appears every monad is specific 
> to a particular type. E.g. a sequence monad. So, great, I have something 
> that takes a scalar and returns a sequence. That might solve g(h(x)) if f 
> is a scalar and c is a sequence by letting me write g(s(h(x))), but it 
> doesn't solve the whole problem, since I still have f() to worry about.
>
> So, two specific questions. First, do monads provide a generic solution, 
> so I can apply f(g(h(x)))? Second, is it the whole point of monads to use 
> macros so you don't see the glue functions, like s(), in my example? I 
> mean, we can always write glue functions so we can compose functions with 
> different input/output types without using monads. What exactly are monads 
> adding?
>
> Oh, and one more. If I were to actually use a monad in a piece of 
> production code, what are the chances that the next person working on the 
> code would have the faintest idea how it worked? ;-p
>

-- 
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: core.logic and other types of solvers

2012-10-27 Thread David Nolen 
On Sat, Oct 27, 2012 at 12:11 AM, Brandon Bloom  wrote:

> I'd suspect the specialized solvers provide performance
> and predictability tuned to their particular use cases. It's worth noting
> is that both components must provide interactive performance. I wonder if
> there is some way to leverage the infrastructure of core.logic backed by
> different types of solvers.
>

It's a goal for core.logic to support CLP(X). Bring your own constraints
and your own solvers. The 0.8.0 is a big step towards that goal.

I'm also interested in getting the core.logic CLP framework fast enough
that the core doesn't slow down fast solvers. We'll see :)

David

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

Re: Bug in CLJS compiler?

2012-10-27 Thread David Nolen 
On Sat, Oct 27, 2012 at 8:19 AM, Tim  wrote:

> While playing around with a little test website I came across what, I
> believe to be a bug in the CLJS compiler.  It seems like the generation of
> symbols for use in macros (e.g. var#) is broken when compiled into certain
> JavaScript forms.
>
> This is a bit of a contrived example but it illustrates the point.
>
> This is my-website.macros file:
>
> (ns my-website.macros)
>
> (defmacro defalert [name n]
>   `(let [i# ~n]
>  (defn ~name []
>(js/alert i#
>

Top level lets are currently problematic. There's a already a ticket for
this issue in JIRA - http://dev.clojure.org/jira/browse/CLJS-401

David

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

Bug in CLJS compiler?

2012-10-27 Thread Tim 
While playing around with a little test website I came across what, I 
believe to be a bug in the CLJS compiler.  It seems like the generation of 
symbols for use in macros (e.g. var#) is broken when compiled into certain 
JavaScript forms.

This is a bit of a contrived example but it illustrates the point.

This is my-website.macros file:

(ns my-website.macros)

(defmacro defalert [name n]
  `(let [i# ~n]
 (defn ~name []
   (js/alert i#


This is my-website.test file:

(ns my-website.test
  (:require [jayq.core :as jq])
  (:use-macros [my-website.macros :only [defalert]])
  )

(defalert alert5 5)
(defalert alert9 9)

(alert5)
(alert9)

And this is (a portion of) the generated .js file:

var i__6378__auto__ = 5;
my_website.test.alert5 = function alert5() {
  return alert(i__6378__auto__)
};
var i__6378__auto__ = 9;
my_website.test.alert9 = function alert9() {
  return alert(i__6378__auto__)
};
my_website.test.alert5.call(null);
my_website.test.alert9.call(null);

When this is loaded into a webpage two alerts happen (as expected); 
however, both of the alerts are "9".  I believe the intention of the code 
is to alert 5 and then alert 9.   Inspecting the .js generated code it is 
pretty clear what is going on.  The compiler is generating the same symbol 
for i# in both expansions of defalert and that symbol is being overwritten 
in the global scope.

This seems like a bug to me, but I wanted to get other's opinions.

*Additional information*

My project.clj looks like:

(defproject my-website "0.1.0-SNAPSHOT"
  :description "Scaffold clojure website"
  :dependencies [[org.clojure/clojure "1.4.0"]
 [jayq "0.1.0-alpha4"]
 [noir "1.3.0-beta3"]]
  :plugins [[lein-cljsbuild "0.2.9"]] ; cljsbuild plugin
  :cljsbuild
  {
   :builds [{
 ;; The path to the top-level ClojureScript source directory:
 :source-path "src-cljs"
 ;; The standard ClojureScript compiler options:
 ;; (See the ClojureScript compiler documentation for details.)
 :compiler {
:output-to "resources/public/js/main.js"
:optimizations :whitespace
:pretty-print true}}]}



  :main my-website.server)


This example is not as academic as it might first seem. I came across this 
exact problem while using defpartial from the crate lib by Chris Granger.  
Here is the code that tripped me up:

(defpartial button1 []
  [:a.button1 {:href "#"} "Button 1"])

(defpartial button2 []
  [:a.button2 {:href "#"} "Button 2"])

(jq/on ($ :body) :click button1
   nil
   (fn [e]
 (.preventDefault e)
 (alert "button 1"))

(jq/on ($ :body) :click button2
   nil
   (fn [e]
 (.preventDefault e)
 (alert "button 2"))

My intention was to alert with "Button 1" when any button1 was clicked and 
to alert with "Button 2" when any button2 was clicked. In this case 
clicking on any button2 does indeed alert with "Button 2", but clicking on 
any button1 will also alert with "Button 2".  The fundamental problem is 
due the behavior that I describe in my contrived example.

By the way, the workaround here is very easy.  Simply replace the button1 and 
button2 functions in the on calls with the class names assigned to those 
elements (:.button1 and :.button2 respectively).

-- 
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: future with user specified ExecutorService

2012-10-27 Thread Max Penet 
Yes I know, but my membership approval is still pending on clojure-dev (CA 
on the way), and from what I have read, I am supposed to ask first on the 
ML before creating a JIRA ticket.

http://dev.clojure.org/display/design/JIRA+workflow

Slow process... 


Max

On Saturday, October 27, 2012 1:02:42 PM UTC+2, Casper Clausen wrote:
>
> +1 That would be nice. This may not be the right place for the suggestion 
> though.
>
> On Thursday, October 25, 2012 2:43:58 PM UTC+2, Max Penet wrote:
>>
>> wrong commit: 
>> https://github.com/mpenet/clojure/commit/9c6e47524dc21c6bdfaa9d0cc2a69377cc69cbf3
>>  
>>
>> On Thursday, October 25, 2012 2:35:01 PM UTC+2, Max Penet wrote:
>>>
>>> Another enhancement proposal, would it be possible to have a future-call 
>>> arity with an additional argument as the ExecutorService used. It seems to 
>>> be a trivial but useful modification, but I wanted to ask here before 
>>> creating a ticket for this. 
>>>
>>> Something like this maybe: 
>>> https://github.com/mpenet/clojure/commit/e5295ac1aa49036c98a3a4e18cba974cd72483d5
>>>
>>> Max
>>>
>>

-- 
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: future with user specified ExecutorService

2012-10-27 Thread Casper Clausen 
+1 That would be nice. This may not be the right place for the suggestion 
though.

On Thursday, October 25, 2012 2:43:58 PM UTC+2, Max Penet wrote:
>
> wrong commit: 
> https://github.com/mpenet/clojure/commit/9c6e47524dc21c6bdfaa9d0cc2a69377cc69cbf3
>  
>
> On Thursday, October 25, 2012 2:35:01 PM UTC+2, Max Penet wrote:
>>
>> Another enhancement proposal, would it be possible to have a future-call 
>> arity with an additional argument as the ExecutorService used. It seems to 
>> be a trivial but useful modification, but I wanted to ask here before 
>> creating a ticket for this. 
>>
>> Something like this maybe: 
>> https://github.com/mpenet/clojure/commit/e5295ac1aa49036c98a3a4e18cba974cd72483d5
>>
>> Max
>>
>

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

2012-10-27 Thread Stephen Compall 
On Fri, 2012-10-26 at 21:55 -0700, Ben Wolfson wrote:
> f :: a -> b
> g :: c -> d
> h :: e -> j [renamed from "f"]
> 
> and "you'd like to chain [them] like f(g(h(x))), but you can't because
> b is a different type from c and d is a different type from e.", how
> does m-chain help?
> 
> I would have expected, given the "b is a different type from c" thing,
> that the chaining would go h(g(f(x)), but it's not as if that helps,
> unless the types work out like:
> 
> b ~ m c
> d ~ m e

I assume that Brian's original example involved such constraints,
implicitly; i.e., a, b, c, d, e are metasyntactic variables in prose
referring to values, not type variables.

-- 
Stephen Compall
"^aCollection allSatisfy: [:each | aCondition]": less is better than


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