Boxed math in transducers

[Peter Taoussanis]

Hi all,

Just noticed some use of boxed math in a couple of the Clojure 1.7 
transducers (e.g. `take`). Would there be interest in a PR to add some 
numerical type hints?

Cheers :-)

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A generalization of iterate

[Max Countryman]

I wonder if something like this is a little easier to read?

(defn generate
  ([f coll]
   (generate f coll (reverse coll)))
  ([f coll args]
   (let [next-val (apply f args)]
 (lazy-cat coll (generate f [next-val] (conj (butlast args) next-val))

 Where your Fibonacci example becomes:

(take 100 (generate +’ [1 1]))

As for your other questions, I can’t be of much help. But isn’t there 
nontrivial memory overhead to consider with this approach?


> On Sep 22, 2015, at 18:19, nchurch  wrote:
> 
> I was going through 4clojure (highly recommended!) and doing the Fibonacci 
> exercise.  It occurred to me that the iterate function could be generalized 
> in a reasonable way, so that the next value is generated by applying the 
> function to the last N items so far, where N is the number of initial 
> arguments beyond the function.  Thus:
> 
> (generate inc 1) 
> 
> works just like iterate, while
> 
> (generate + 1 1)
> 
> generates the Fibonacci sequence.
> 
> Here's the code:
> 
> (defn generate
>   [f & more]
>   (letfn [(recurse
> [coll args]
> (let [next-val (apply f args)]
>   (lazy-cat coll (recurse [next-val] (conj (butlast args) 
> next-val)]
> (recurse more (reverse more
> 
> Code is also on Github .
> 
> I see this as part of a larger class of generalized sequence functions: for 
> instance, extra arguments in a function given to reduce could refer to N 
> arguments back in the sequence (might be useful, for instance, in smoothing a 
> sequence of values using an average).
> 
> Questions: is there an existing home for this kind of functionality?  And 
> could the above code be improved?  (I just used the definition of iterate as 
> a starting point.)
> 
> 
> 
> 
> -- 
> 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 unsubscribe from this group and stop receiving emails from it, send an 
> email to clojure+unsubscr...@googlegroups.com 
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [:ann] cats 1.0.0

[Martin Raison]

Great work!

Le jeudi 17 septembre 2015 04:47:42 UTC-7, Alejandro Gómez a écrit :
>
> Hello everyone, 
>
> I'm glad to announce the 1.0.0 release of cats[1], a library with 
> category theory 
> and algebraic abstractions for Clojure(Script). This release packs a lot 
> of new 
> features and it also has breaking changes. We're happy with the API and 
> we've settled 
> it in this 1.0.0 release, the next steps[2] are better context 
> management and improvements 
> to monad transformers. 
>
> Here's a full changelog[3] and the updated documentation[4] and API 
> reference[5]. 
>
> As always, any feedback is very welcome. 
>
> Cheers, 
>
> Al 
>
> [1]: https://github.com/funcool/cats 
> [2]: https://github.com/funcool/cats/issues 
> [3]: 
> https://github.com/funcool/cats/blob/master/CHANGELOG.md#version-100 
> [4]: https://funcool.github.io/cats/latest/ 
> [5]: https://funcool.github.io/cats/latest/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
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

data.xml update

[Herwig Hochleitner]

Hello Everybody,

it took me about a year and multiple failed rewrites, to admit, that
keeping a compatibility mode for the current prefix-emitting hack in
clojure.data.xml, is just to much of a hassle and complexity nightmare for
it to be worth it.
So now, non-namespaced names are represented as plain keywords as before,
but namespaced names are represented as QNames, or shorthanded to a
prefixed keyword according to an aliasing mechanism, see updated
http://dev.clojure.org/display/DXML/Namespaced+XML

I'm pretty happy with the resulting rewrite (
https://github.com/bendlas/data.xml) and I think it's a great time now, to
try it out and help sand off the edges.
Please let me know, how well this approach could support your use case for
namespaced xml.

thanks

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

A generalization of iterate

[nchurch]

I was going through 4clojure (highly recommended!) and doing the Fibonacci 
exercise.  It occurred to me that the iterate function could be generalized 
in a reasonable way, so that the next value is generated by applying the 
function to the last N items so far, where N is the number of initial 
arguments beyond the function.  Thus:

(generate inc 1) 

works just like iterate, while

(generate + 1 1)

generates the Fibonacci sequence.

Here's the code:

(defn generate
  [f & more]
  (letfn [(recurse
[coll args]
(let [next-val (apply f args)]
  (lazy-cat coll (recurse [next-val] (conj (butlast args) 
next-val)]
(recurse more (reverse more


Code is also on Github .

I see this as part of a larger class of generalized sequence functions: for 
instance, extra arguments in a function given to *reduce* could refer to N 
arguments back in the sequence (might be useful, for instance, in smoothing a 
sequence of values using an average).

Questions: is there an existing home for this kind of functionality?  And could 
the above code be improved?  (I just used the definition of *iterate* as a 
starting point.)



-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Clojure performance on Android

[Ben Brinckerhoff]

On my team, we tried using RoboVM to compile Clojure to iOS. It worked fine 
once it booted, but startup time was a concern. We didn't spend a lot of 
time optimizing it though. We also found the compile/boot cycle to be quite 
long (over 50s to see a change). My understanding (perhaps mistaken) is 
RoboVM must compile all code before boot, so live-loading code via a REPL 
won't work.

We switched to using Clojurescript/React Native and it's been a net 
positive for us so far, even though we had to rewrite some internal 
libraries for CLJS. We had a REPL briefly (Ambly, although we've recently 
had to drop support for it due to breaking changes from React Native 
upgrades) and our compile/boot cycle is about 20s.

My coworker Chris Vermilion created these slides about our 
experience 
https://docs.google.com/viewer?a=v&pid=forums&srcid=MTUyOTIzOTE0MjU1MDA0MDI3NjQBMTExMTI3MjYwMjc1OTc4MDg3MzQBXzVfV0tNdUZDQUFKATAuMQEBdjI

Hope that helps,
Ben

On Tuesday, September 22, 2015 at 3:51:04 PM UTC-7, Roger Keays wrote:
>
> Hi all,
>
> Thanks for giving the world Clojure. It's already made my life better just 
> by applying the idioms to my Java code (e.g. 
> http://www.ninthavenue.com.au/java-with-no-design-patterns).
>
> I'm starting on a new project soon and would like to use Clojure, however 
> in my experiments so far performance seems to be a bit of a problem. Since 
> the project will target mobile devices performance is pretty important 
> (especially startup time).
>
> To be honest, even for the server I'm a little deterred by the stats I've 
> seen online of Clojure vs Java performance. I can always just write Java in 
> a functional style and embed beanshell for a REPL.
>
> So I guess it would be good to hear from the community how things have 
> worked out for them performance-wise, and especially on Android/iOS.
>
> Also, are there any known showstoppers compiling Clojure bytecode to iOS 
> using RoboVM?
>
> Thanks in advance,
>
> Roger
>
>
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using metadata to specify how calls to a macro should be indented

[Artur Malabarba]

You're right about indentation depending on the code being evaluated, but
that's still better than nothing. ☺

People who do a significant amount of coding without a live session can
still manually configure indentation like they currently do, and they're no
worse off.

The editor can even parse the metadata map present in the defn/defmacro, so
as to provide some "offline" support (though I don't foresee Cider doing
that).
On 22 Sep 2015 11:31 am, "Phillip Lord" 
wrote:

>
>
>
> Artur Malabarba  writes:
> > Over at CIDER we're adding a feature where the author of a macro (or
> > function) can specify how that macro should be indented by adding an
> :indent
> > metadata to its definition. This way the editor (and other tools, like
> > cljfmt) will know what's the proper way of indenting any macro (even
> those
> > custom-defined) without having to hardcode a bajillion names.
>
>
> One slight disadvantage with this approach is that the indentation can
> change depending on the evaluation status of the code. Consider this set
> of events inside emacs (I'll get back to Clojure -- it's a general
> problem not Emacs specific).
>
>  - I open the file lentic.el
>  - I type M-x indent-buffer
>
> Now, lentic.el depends on m-buffer.el which has some macros with
> "declare" forms (the elisp equivalent to the metadata you are talking
> off). And these are used in lentic.el.
>
> But I haven't loaded m-buffer.el yet. So the declare forms are not
> active, so the m-buffer macros indent according to normal rules. Now, I
> do
>
>  - M-x eval-buffer
>  - M-x indent-buffer
>
> This loads lentic.el which loads m-buffer.el including the macros. So,
> now I get different indentation patterns. Solution in Emacs space: force
> loading on m-buffer.el whenever lentic.el is *opened* rather than loaded.
>
> Using metadata in Clojure the same situation will arise, but will be
> somewhat worse. Indentation will be likely to behave differently
> depending on whether the REPL is open and the evaluation status of any
> macros. Given the slow start up time of the clojure REPL, this is
> perhaps a more significant issue. The interesting question then is what
> percentage of the time do Clojure developers work *without* a repl
> active.
>
> Just a thought.
>
> Phil
>
>

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

Re: ClojureScript vs. Elm for Multiplayer Web Game

[JvJ]

Also, I noticed that http-kit is being used in the zombie game tutorial.  
How does that stack up against node in terms of capability?

On Monday, 21 September 2015 21:22:51 UTC-7, JvJ wrote:

> Wow!  An unexpected number of resources on exactly what I'm looking for! 
>  Thanks!
>
> ... but I am somehow surprised that someone could mention both Clojure and 
> the Undead without using term "Macronomicon".
>
> On Monday, 21 September 2015 06:52:24 UTC-7, Gijs S. wrote:
>>
>> I have no experience with Elm, but I have made a card game with 
>> ClojureScript:
>>
>> http://thegeez.net/2012/03/20/racket_gin_clojurescript.html
>>
>> As well as a version with a Datomic back-end:
>> http://thegeez.net/2014/06/12/gin_datomic.html
>>
>>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Clojure performance on Android

[Roger Keays]

Hi all,

Thanks for giving the world Clojure. It's already made my life better just 
by applying the idioms to my Java code (e.g. 
http://www.ninthavenue.com.au/java-with-no-design-patterns).

I'm starting on a new project soon and would like to use Clojure, however 
in my experiments so far performance seems to be a bit of a problem. Since 
the project will target mobile devices performance is pretty important 
(especially startup time).

To be honest, even for the server I'm a little deterred by the stats I've 
seen online of Clojure vs Java performance. I can always just write Java in 
a functional style and embed beanshell for a REPL.

So I guess it would be good to hear from the community how things have 
worked out for them performance-wise, and especially on Android/iOS.

Also, are there any known showstoppers compiling Clojure bytecode to iOS 
using RoboVM?

Thanks in advance,

Roger


-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Release of pulley.cps 0.2.0

[Nathan Davis]

Thanks, Francesco.  I'll definitely take a look at those resources.

Nathan Davis

On Tuesday, September 22, 2015 at 4:31:07 PM UTC-5, Francesco Bellomi wrote:
>
> Thanks for taking the time to write such a detailed answer, I really 
> appreciated it.
>
> Delimited continuations are useful since they return a value, and thus may 
> be reused and composed, and used to build complex control mechanisms.
>
> In my opinion the coolest use of delimited continuations are Effects
>
> http://math.andrej.com/wp-content/uploads/2012/03/eff.pdf
>
> a way to separate pure computations and side effects that is more 
> intuitive and more composable than monads.
>
> Brandon Bloom has written a (prototype) implementation of effect handlers 
> for clojure, based on the core.async CPS machinery
>
> https://github.com/brandonbloom/cleff
>
> Francesco
>
>
>
>
> On Tue, Sep 22, 2015 at 10:19 PM, Nathan Davis <
> nda...@positronic-solutions.com > wrote:
>
>> On Tuesday, September 22, 2015 at 6:37:13 AM UTC-5, Francesco Bellomi 
>> wrote:
>>>
>>> Hi Nathan,
>>>
>>> I think it's an awesome project, thanks for sharing this.
>>>
>>>
>> Thanks.  I appreciate the feedback.
>>  
>>
>>> I see that currently only full continuations are supported. Would it be 
>>> possible/feasible/easy to support delimited continuations? (ie. with ranges 
>>> different from the outermost CPS context)
>>>
>>>
>> I haven't done much research into delimited continuations yet, so my 
>> understanding may be wrong.  However, here's my analysis of the current 
>> situation.
>>
>> As currently implemented, pulley.cps uses "sort of" full continuations.  
>> I say "sort of" because continuations are implicitly limited by the 
>> trampoline.  So anytime a new trampoline is introduced (i.e., you call CPS 
>> code from a non-CPS function), the continuation is limited to that 
>> trampoline.  However, there is currently no way to explicitly delimit the 
>> continuation.
>>
>> In light of the above, it seems to me that *reset(f)* could be 
>> implemented as simply as a non-CPS function that invokes the (presumably 
>> CPS'd) function *f*.  I don't think this would be the ideal 
>> implementation, but it does seem to suggest it is at least possible.
>>
>> I'd be interested in hearing from you (and others) what use-cases you see 
>> for delimited continuations.  The overviews of the topic I've seen so far 
>> seem to neglect this entirely or only address it abstractly.  A few 
>> concrete examples would be a useful "jump-start".
>>
>> Also, it would be interesting to have a comparison with core.async's CPS 
>>> machinery: is pulley.cps expected to be more efficient performance-wise? Is 
>>> it implemented using similar or comparable techniques?
>>>
>>>
>> core.async handles continuations as a state machine.  On the other hand, 
>> pulley.cps implements continuations via closures.  The two representations 
>> are isomorphic, so theoretically anything you can express in one you can 
>> express in the other.  However, state machines (at least as implemented in 
>> core.async) must be constructed with complete knowledge of all the possible 
>> states involved.  Since *go*-blocks are implemented via macro, and 
>> macros are limited to local transformations (and analysis), continuations 
>> (state transitions) within core.async are limited to the same *go*-block.
>>
>> In contrast, closures can come from different functions or even 
>> namespaces.  So continuations in pulley.cps can cross local boundaries.  
>> That is, even though pulley.cps transforms code blocks in isolation, 
>> closures allow these blocks to coordinate and participate in the CPS 
>> protocol.
>>
>> This has  some practical ramifications.  For example, you can't compose 
>> *go*-blocks the same way you compose regular functions.  In fact, you 
>> can't call a function in a *go*-block and, within that function, suspend 
>> the *go*-block.  You can of course compose core.async processes, but it 
>> has a distinct look and feel from function composition.
>>
>> On the other hand, functions transformed by pulley.cps compose just like 
>> regular functions — because they are functions.  In the examples directory, 
>> there is an implementation of a cooperative multitasking engine.  Unlike 
>> core.async, you can suspend tasks from pretty much any function.  There are 
>> still some limitations, but these are dynamic as opposed to static, and 
>> have to do with what I said previously about continuations being implicitly 
>> delimited.
>>
>> As far as performance goes, I haven't directly compared core.async to 
>> pulley.cps code yet, but I fully expect core.async to be a hands-down 
>> winner at this point.  core.async is more mature and has had more 
>> performance tuning than pulley.cps.  I have done some limited benchmarking 
>> against regular clojure code.  All I can say is that for compute-intensive 
>> code with tight loops in CPS code, pulley.cps performs pretty poorly.  You 
>> can expect a CPS versio

Re: Using metadata to specify how calls to a macro should be indented

[Phillip Lord]

Fluid Dynamics  writes:

> On Tuesday, September 22, 2015 at 6:31:34 AM UTC-4, Phillip Lord wrote:
>>
>> ... The interesting question then is what 
>> percentage of the time do Clojure developers work *without* a repl 
>> active.
>>
>
> Uhhh, zero? :) 

Some I am sure. I do, though. I often write and improve documentation
without a REPL, especially when I am using my old netbook. The REPL
shortens the battery live and isn't that useful when writing English.

Still, the problem is soluable in a number of ways, I guess, and I can't
think of a better alternative (to using metadata).

Phil

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

Re: [ANN] Release of pulley.cps 0.2.0

[Francesco Bellomi]

Thanks for taking the time to write such a detailed answer, I really
appreciated it.

Delimited continuations are useful since they return a value, and thus may
be reused and composed, and used to build complex control mechanisms.

In my opinion the coolest use of delimited continuations are Effects

http://math.andrej.com/wp-content/uploads/2012/03/eff.pdf

a way to separate pure computations and side effects that is more intuitive
and more composable than monads.

Brandon Bloom has written a (prototype) implementation of effect handlers
for clojure, based on the core.async CPS machinery

https://github.com/brandonbloom/cleff

Francesco




On Tue, Sep 22, 2015 at 10:19 PM, Nathan Davis <
nda...@positronic-solutions.com> wrote:

> On Tuesday, September 22, 2015 at 6:37:13 AM UTC-5, Francesco Bellomi
> wrote:
>>
>> Hi Nathan,
>>
>> I think it's an awesome project, thanks for sharing this.
>>
>>
> Thanks.  I appreciate the feedback.
>
>
>> I see that currently only full continuations are supported. Would it be
>> possible/feasible/easy to support delimited continuations? (ie. with ranges
>> different from the outermost CPS context)
>>
>>
> I haven't done much research into delimited continuations yet, so my
> understanding may be wrong.  However, here's my analysis of the current
> situation.
>
> As currently implemented, pulley.cps uses "sort of" full continuations.  I
> say "sort of" because continuations are implicitly limited by the
> trampoline.  So anytime a new trampoline is introduced (i.e., you call CPS
> code from a non-CPS function), the continuation is limited to that
> trampoline.  However, there is currently no way to explicitly delimit the
> continuation.
>
> In light of the above, it seems to me that *reset(f)* could be
> implemented as simply as a non-CPS function that invokes the (presumably
> CPS'd) function *f*.  I don't think this would be the ideal
> implementation, but it does seem to suggest it is at least possible.
>
> I'd be interested in hearing from you (and others) what use-cases you see
> for delimited continuations.  The overviews of the topic I've seen so far
> seem to neglect this entirely or only address it abstractly.  A few
> concrete examples would be a useful "jump-start".
>
> Also, it would be interesting to have a comparison with core.async's CPS
>> machinery: is pulley.cps expected to be more efficient performance-wise? Is
>> it implemented using similar or comparable techniques?
>>
>>
> core.async handles continuations as a state machine.  On the other hand,
> pulley.cps implements continuations via closures.  The two representations
> are isomorphic, so theoretically anything you can express in one you can
> express in the other.  However, state machines (at least as implemented in
> core.async) must be constructed with complete knowledge of all the possible
> states involved.  Since *go*-blocks are implemented via macro, and macros
> are limited to local transformations (and analysis), continuations (state
> transitions) within core.async are limited to the same *go*-block.
>
> In contrast, closures can come from different functions or even
> namespaces.  So continuations in pulley.cps can cross local boundaries.
> That is, even though pulley.cps transforms code blocks in isolation,
> closures allow these blocks to coordinate and participate in the CPS
> protocol.
>
> This has  some practical ramifications.  For example, you can't compose
> *go*-blocks the same way you compose regular functions.  In fact, you
> can't call a function in a *go*-block and, within that function, suspend
> the *go*-block.  You can of course compose core.async processes, but it
> has a distinct look and feel from function composition.
>
> On the other hand, functions transformed by pulley.cps compose just like
> regular functions — because they are functions.  In the examples directory,
> there is an implementation of a cooperative multitasking engine.  Unlike
> core.async, you can suspend tasks from pretty much any function.  There are
> still some limitations, but these are dynamic as opposed to static, and
> have to do with what I said previously about continuations being implicitly
> delimited.
>
> As far as performance goes, I haven't directly compared core.async to
> pulley.cps code yet, but I fully expect core.async to be a hands-down
> winner at this point.  core.async is more mature and has had more
> performance tuning than pulley.cps.  I have done some limited benchmarking
> against regular clojure code.  All I can say is that for compute-intensive
> code with tight loops in CPS code, pulley.cps performs pretty poorly.  You
> can expect a CPS version of such code to be 1 to 2 orders of magnitude
> slower than a non-CPS version.
>
> Interestingly, in included benchmark.clj (which benchmarks a few ways of
> computing the factorial function), one of the CPS implementations actually
> out-performed the non-CPS equivalent implemented via *loop* on OpenJDK 7
> for large n.  While f

Re: [ANN] Release of pulley.cps 0.2.0

[Nathan Davis]

On Tuesday, September 22, 2015 at 6:37:13 AM UTC-5, Francesco Bellomi wrote:
>
> Hi Nathan,
>
> I think it's an awesome project, thanks for sharing this.
>
>
Thanks.  I appreciate the feedback.
 

> I see that currently only full continuations are supported. Would it be 
> possible/feasible/easy to support delimited continuations? (ie. with ranges 
> different from the outermost CPS context)
>
>
I haven't done much research into delimited continuations yet, so my 
understanding may be wrong.  However, here's my analysis of the current 
situation.

As currently implemented, pulley.cps uses "sort of" full continuations.  I 
say "sort of" because continuations are implicitly limited by the 
trampoline.  So anytime a new trampoline is introduced (i.e., you call CPS 
code from a non-CPS function), the continuation is limited to that 
trampoline.  However, there is currently no way to explicitly delimit the 
continuation.

In light of the above, it seems to me that *reset(f)* could be implemented 
as simply as a non-CPS function that invokes the (presumably CPS'd) 
function *f*.  I don't think this would be the ideal implementation, but it 
does seem to suggest it is at least possible.

I'd be interested in hearing from you (and others) what use-cases you see 
for delimited continuations.  The overviews of the topic I've seen so far 
seem to neglect this entirely or only address it abstractly.  A few 
concrete examples would be a useful "jump-start".

Also, it would be interesting to have a comparison with core.async's CPS 
> machinery: is pulley.cps expected to be more efficient performance-wise? Is 
> it implemented using similar or comparable techniques?
>
>
core.async handles continuations as a state machine.  On the other hand, 
pulley.cps implements continuations via closures.  The two representations 
are isomorphic, so theoretically anything you can express in one you can 
express in the other.  However, state machines (at least as implemented in 
core.async) must be constructed with complete knowledge of all the possible 
states involved.  Since *go*-blocks are implemented via macro, and macros 
are limited to local transformations (and analysis), continuations (state 
transitions) within core.async are limited to the same *go*-block.

In contrast, closures can come from different functions or even 
namespaces.  So continuations in pulley.cps can cross local boundaries.  
That is, even though pulley.cps transforms code blocks in isolation, 
closures allow these blocks to coordinate and participate in the CPS 
protocol.

This has  some practical ramifications.  For example, you can't compose 
*go*-blocks 
the same way you compose regular functions.  In fact, you can't call a 
function in a *go*-block and, within that function, suspend the *go*-block.  
You can of course compose core.async processes, but it has a distinct look 
and feel from function composition.

On the other hand, functions transformed by pulley.cps compose just like 
regular functions — because they are functions.  In the examples directory, 
there is an implementation of a cooperative multitasking engine.  Unlike 
core.async, you can suspend tasks from pretty much any function.  There are 
still some limitations, but these are dynamic as opposed to static, and 
have to do with what I said previously about continuations being implicitly 
delimited.

As far as performance goes, I haven't directly compared core.async to 
pulley.cps code yet, but I fully expect core.async to be a hands-down 
winner at this point.  core.async is more mature and has had more 
performance tuning than pulley.cps.  I have done some limited benchmarking 
against regular clojure code.  All I can say is that for compute-intensive 
code with tight loops in CPS code, pulley.cps performs pretty poorly.  You 
can expect a CPS version of such code to be 1 to 2 orders of magnitude 
slower than a non-CPS version.

Interestingly, in included benchmark.clj (which benchmarks a few ways of 
computing the factorial function), one of the CPS implementations actually 
out-performed the non-CPS equivalent implemented via *loop* on OpenJDK 7 
for large n.  While for large n there is less time spent in CPS code and 
more time doing the actual multiplication, it is an interesting result 
because it means there was apparently some optimization it was able to 
perform on the CPS code that it wasn't able to do on the *loop* verion.  On 
OpenJDK 8, the CPS code is consistently slower in all cases (though, as 
expected, the slow-down decreases as n increases).
 

> thanks,
> Francesco
>
>
>
>
> On Monday, September 21, 2015 at 9:24:20 PM UTC+2, Nathan Davis wrote:
>>
>> I'm pleased to annouce the release of verion 0.2.0 of pulley.cps 
>> . pulley.cps is a 
>> macro-based source-to-source transforming compiler that transforms Clojure 
>> code into Continuation Passing Style (CPS), as well as a supporting 
>> run-time library. 
>>
>>
>>

Re: Using metadata to specify how calls to a macro should be indented

[Colin Yates]

Do you know about lein figwheel?
On 22 Sep 2015 21:05, "Gary Trakhman"  wrote:

> Sometimes more than 0% when I'm doing something small in clojurescript,
> can't be bothered with the setup, and browser refresh is good enough :-).
> On Tue, Sep 22, 2015 at 4:02 PM Fluid Dynamics  wrote:
>
>> On Tuesday, September 22, 2015 at 6:31:34 AM UTC-4, Phillip Lord wrote:
>>>
>>> ... The interesting question then is what
>>>
>> percentage of the time do Clojure developers work *without* a repl
>>> active.
>>>
>>
>> Uhhh, zero? :)
>>
>> --
>> 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 unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using metadata to specify how calls to a macro should be indented

[Gary Trakhman]

Sometimes more than 0% when I'm doing something small in clojurescript,
can't be bothered with the setup, and browser refresh is good enough :-).
On Tue, Sep 22, 2015 at 4:02 PM Fluid Dynamics  wrote:

> On Tuesday, September 22, 2015 at 6:31:34 AM UTC-4, Phillip Lord wrote:
>>
>> ... The interesting question then is what
>>
> percentage of the time do Clojure developers work *without* a repl
>> active.
>>
>
> Uhhh, zero? :)
>
> --
> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using metadata to specify how calls to a macro should be indented

[Fluid Dynamics]

On Tuesday, September 22, 2015 at 6:31:34 AM UTC-4, Phillip Lord wrote:
>
> ... The interesting question then is what 
> percentage of the time do Clojure developers work *without* a repl 
> active.
>

Uhhh, zero? :) 

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

scheduling with core.async?

[Leon Grapenthin]

Is it recommended to use core.asyncs timeout channel to wait on hour or 
even longer for light scheduling tasks?

High precision is a nongoal.

Kind regards,
 Leon.

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Release of pulley.cps 0.2.0

[Francesco Bellomi]

Hi Nathan,

I think it's an awesome project, thanks for sharing this.

I see that currently only full continuations are supported. Would it be 
possible/feasible/easy to support delimited continuations? (ie. with ranges 
different from the outermost CPS context)

Also, it would be interesting to have a comparison with core.async's CPS 
machinery: is pulley.cps expected to be more efficient performance-wise? Is 
it implemented using similar or comparable techniques?

thanks,
Francesco




On Monday, September 21, 2015 at 9:24:20 PM UTC+2, Nathan Davis wrote:
>
> I'm pleased to annouce the release of verion 0.2.0 of pulley.cps 
> . pulley.cps is a 
> macro-based source-to-source transforming compiler that transforms Clojure 
> code into Continuation Passing Style (CPS), as well as a supporting 
> run-time library. 
>
>
> The main feature of this release is the addition of exception support — 
> you can now use try, throw, and catch just like you would in regular 
> Clojure code. There are various other enhancements as well, mostly to 
> support the exception code, as documented in the changelog.
>
>
> Nathan Davis
>
>

-- 
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 unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Using metadata to specify how calls to a macro should be indented

[Phillip Lord]

Artur Malabarba  writes:
> Over at CIDER we're adding a feature where the author of a macro (or 
> function) can specify how that macro should be indented by adding an :indent 
> metadata to its definition. This way the editor (and other tools, like 
> cljfmt) will know what's the proper way of indenting any macro (even those 
> custom-defined) without having to hardcode a bajillion names.


One slight disadvantage with this approach is that the indentation can
change depending on the evaluation status of the code. Consider this set
of events inside emacs (I'll get back to Clojure -- it's a general
problem not Emacs specific).

 - I open the file lentic.el
 - I type M-x indent-buffer

Now, lentic.el depends on m-buffer.el which has some macros with
"declare" forms (the elisp equivalent to the metadata you are talking
off). And these are used in lentic.el.

But I haven't loaded m-buffer.el yet. So the declare forms are not
active, so the m-buffer macros indent according to normal rules. Now, I
do

 - M-x eval-buffer
 - M-x indent-buffer

This loads lentic.el which loads m-buffer.el including the macros. So,
now I get different indentation patterns. Solution in Emacs space: force
loading on m-buffer.el whenever lentic.el is *opened* rather than loaded.

Using metadata in Clojure the same situation will arise, but will be
somewhat worse. Indentation will be likely to behave differently
depending on whether the REPL is open and the evaluation status of any
macros. Given the slow start up time of the clojure REPL, this is
perhaps a more significant issue. The interesting question then is what
percentage of the time do Clojure developers work *without* a repl
active.

Just a thought.

Phil

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