Re: Macro usage within Clojure community and naming functions which perform actions under certain conditions

[Ray Miller]

On 25 April 2016 at 21:03, Rafał Cieślak  wrote:

> Hi,
>
> I'm writing a turn-based game and one of the biggest functions is the one
> which handles player moves. It receives the current game state (a map) and
> the index of the cell that the player clicked on (an integer).
>
> It has to make a couple of decisions based on the game state. So far I
> just used -> and cond->. The code looks more or less like this, I removed
> a bunch of function calls for brevity.
>
> (-> game-state
> ; This stuff happens on each move.
> (reveal-cell cell-index)
> ; And this stuff happens only under certain conditions.
> (cond->
>   (zero? (:surrounding-power cell))
>   (reveal-safe-cells cell-index)))
>
> The code looks clear IMHO. But then I wanted to add another feature which
> requires me to make decisions based on the updated value of game-state
> (the one that is being threaded inside cond->).
>
> I thought about cond-> a bit and came to the conclusion that the reason
> you can't access the currently threaded value is to keep you from writing
> order-dependent statements. But in my case, I sometimes do want to write
> order-dependent code. For example, I want to give player exp for killing a
> monster and then if the exp is above certain threshold, I want to level up
> his character.
>
> So the problem is that I have to check the current value being threaded,
> but cond-> doesn't allow me to do that.
>
>
You don't need a macro for this sort of thing, and can get some way with
reduce. For example:

(defn apply-conditional-actions
  [game-state & pred-actions]
  (reduce (fn [game-state [pred action]]
(if (pred game-state)
  (action game-state)
  game-state))
  game-state
  (partition 2 pred-actions)))

Then call this function with the game-state and a list of pred/action pairs:

(apply-conditional-actions game-state
   safe-cell? reveal-safe-cells
   monster-killed? inc-exp-points)

-- 
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: Porting Clojure to Native Platforms

[Niels van Klaveren]

The only conclusion I can draw from these benchmarks over the years is that 
the speed of Clojure is inversely proportional to it's idiomaticity

On Tuesday, April 26, 2016 at 7:23:48 AM UTC+2, Mars0i wrote:
>
> On Tuesday, April 26, 2016 at 12:19:23 AM UTC-5, Mars0i wrote:
>>
>> I was going to say that I'd be surprised if Clojure were as fast as SBCL 
>> (overall, on average, depends on your application, depends on how you code 
>> it, ymmv, etc. ...).  Then I stopped back to check the little benchmarks on 
>> the Computer Language Benchmarks Game 
>> 
>>  
>> .  Whatever it is that those comparisons do, or don't prove, I would no 
>> longer be surprised.
>>
>
> I forgot how much faster Clojure got in 1.7 and 1.8.  I remember Java 
> wiping the floor with Clojure on most of those benchmarks a couple of years 
> ago, but now it's just a little bit faster on average 
>  on those 
> benchmarks.
>

-- 
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: Porting Clojure to Native Platforms

[Colin Fleming]

This is true of a lot of those benchmarks, especially for functional
languages. I haven't looked recently, but back in the day Haskell seemed
very fast on the shootout game. However the code that actually runs that
fast is very very far from idiomatic. Again, I haven't looked at the
Clojure versions recently but I recall several of them being basically Java
written in Clojure form, i.e. lots of interop and not a lot of the sort of
higher-order code that makes Clojure such a pleasure to program. The rules
around functions accepting and returning primitives are way into
expert-level territory.



On 26 April 2016 at 20:15, Niels van Klaveren 
wrote:

> The only conclusion I can draw from these benchmarks over the years is
> that the speed of Clojure is inversely proportional to it's idiomaticity
>
>
> On Tuesday, April 26, 2016 at 7:23:48 AM UTC+2, Mars0i wrote:
>>
>> On Tuesday, April 26, 2016 at 12:19:23 AM UTC-5, Mars0i wrote:
>>>
>>> I was going to say that I'd be surprised if Clojure were as fast as SBCL
>>> (overall, on average, depends on your application, depends on how you code
>>> it, ymmv, etc. ...).  Then I stopped back to check the little benchmarks on
>>> the Computer Language Benchmarks Game
>>> 
>>> .  Whatever it is that those comparisons do, or don't prove, I would no
>>> longer be surprised.
>>>
>>
>> I forgot how much faster Clojure got in 1.7 and 1.8.  I remember Java
>> wiping the floor with Clojure on most of those benchmarks a couple of years
>> ago, but now it's just a little bit faster on average
>>  on those
>> benchmarks.
>>
> --
> 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: Porting Clojure to Native Platforms

[Mikera]

I would definitely second Tim's points. The JVM is very hard to beat once 
you factor in the GC and JIT requirements.

Worth noting that persistent data structures with structural sharing are 
used pretty much ubiquitously in Clojure and that these are *exactly* the 
kinds of data structures that benefit most from GC. 

An alternative scheme such as reference counting would perform extremely 
badly in comparison because structural sharing implies a *lot* of reference 
count updates, and writes to reference counts scattered across memory are 
expensive on modern machines (especially in concurrent situations). 

On Tuesday, 26 April 2016 04:50:45 UTC+8, tbc++ wrote:
>
> As someone who has spent a fair amount of time playing around with such 
> things, I'd have to say people vastly misjudge the raw speed you get from 
> the JVM's JIT and GC. In fact, I'd challenge someone to come up with a 
> general use, dynamic language that is not based on the JVM and comes even 
> close to the speed of Clojure. 
>
> A LLVM/C++/RPython based version of Clojure would on a good day come in at 
> about 1/10 the speed of Clojure on the JVM for general use cases. 
>
>
> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke  > wrote:
>
>> > The main motivation would be performance gains.
>>
>> blah? so many impedance mismatches and layers of indirection that i
>> don't think it will gain much? i mean, it would probably be better to
>> spend time tuning gc parameters or something. just a rant / guess.
>> e.g. robovm is for some use cases perfectly fine performance wise
>> believe it or not.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

-- 
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: Porting Clojure to Native Platforms

[Dragan Djuric]

 
On Tuesday, April 26, 2016 at 5:53:42 AM UTC+2, puzzler wrote:
>
> On Mon, Apr 25, 2016 at 1:50 PM, Timothy Baldridge  > wrote:
>
>> As someone who has spent a fair amount of time playing around with such 
>> things, I'd have to say people vastly misjudge the raw speed you get from 
>> the JVM's JIT and GC. In fact, I'd challenge someone to come up with a 
>> general use, dynamic language that is not based on the JVM and comes even 
>> close to the speed of Clojure. 
>>
>>
> Julia reportedly outperforms Clojure (I haven't benchmarked it myself).  
> Julia is designed primarily for numeric computation, but unlike a lot of 
> other "math languages" like Octave, R, and Matlab whose general programming 
> constructs are horribly slow, the overall general-purpose machinery of 
> Julia (function calls, looping, data structures, dispatch, etc.) is said to 
> be quite fast.  
>
> Speaking of numeric computation, it is, in my opinion, a real weak point 
> of Clojure.  There is a huge perf. penalty for boxed numbers, and since 
> anything in a Clojure data structure gets boxed, it's rather difficult to 
> work around Clojure's poor numeric performance for anything more 
> algorithmically complicated than a super-simple loop.  A number of dynamic 
> languages use tagged numbers (primitive types with a couple bits set aside 
> to mark the type of the number), and these are going to do much better than 
> Clojure for a wide variety of math-oriented computational tasks.  I've 
> benchmarked some specific programs in Clojure vs Racket and Racket tended 
> to come out ahead when there was a lot of arithmetic. 
>

On the other hand, Julia relies on external native libraries for 
performance (BLAS, GPU, whatever). The speed of those libraries is not due 
to the language (usually C or ASM) but to the fact that they use algorithms 
that are heavily optimized for each hardware architecture. If you'd write 
vector and matrix functions in plain everyday C, you'd get the same speed 
as with Java arrays in Clojure or Java, sometimes even slower. In Cloure 
and Java, you can link to those same libraries that Julia links to, with 
the same tradeoffs.

-- 
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: Porting Clojure to Native Platforms

[Aleksander Sumowski]

A scala native port is due to be announced soon. It would be interesting to
see whats their approach and performance characteristics are:

http://www.scala-native.org/

Cheers,
Aleksander

On 26 April 2016 at 09:47, Mikera  wrote:

> I would definitely second Tim's points. The JVM is very hard to beat once
> you factor in the GC and JIT requirements.
>
> Worth noting that persistent data structures with structural sharing are
> used pretty much ubiquitously in Clojure and that these are *exactly* the
> kinds of data structures that benefit most from GC.
>
> An alternative scheme such as reference counting would perform extremely
> badly in comparison because structural sharing implies a *lot* of reference
> count updates, and writes to reference counts scattered across memory are
> expensive on modern machines (especially in concurrent situations).
>
> On Tuesday, 26 April 2016 04:50:45 UTC+8, tbc++ wrote:
>>
>> As someone who has spent a fair amount of time playing around with such
>> things, I'd have to say people vastly misjudge the raw speed you get from
>> the JVM's JIT and GC. In fact, I'd challenge someone to come up with a
>> general use, dynamic language that is not based on the JVM and comes even
>> close to the speed of Clojure.
>>
>> A LLVM/C++/RPython based version of Clojure would on a good day come in
>> at about 1/10 the speed of Clojure on the JVM for general use cases.
>>
>>
>> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke  wrote:
>>
>>> > The main motivation would be performance gains.
>>>
>>> blah? so many impedance mismatches and layers of indirection that i
>>> don't think it will gain much? i mean, it would probably be better to
>>> spend time tuning gc parameters or something. just a rant / guess.
>>> e.g. robovm is for some use cases perfectly fine performance wise
>>> believe it or not.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
> --
> 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.
>

-- 
*uSwitch is a trading name of uSwitch Ltd. Registered in **England and 
Wales **(Company No. 03612689). Registered Address: **Notcutt House, 36 
Southwark Bridge Road, London, SE1 9EU*

*This communication and any attachments contains information which is 
confidential and may be subject to legal privilege. It is for intended 
recipients only. If you are not the intended recipient you must not copy, 
distribute, publish, rely on or otherwise use it without our consent. Some 
of our communications may contain confidential information which it could 
be a criminal offence for you to disclose or use without authority. If you 
have received this email in error please notify the sender immediately and 
delete the email from your computer.*

*uSwitch Ltd reserves the right to monitor all email communications for 
compliance with legal, regulatory and professional standards.*

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

Re: Porting Clojure to Native Platforms

[Nurullah Akkaya]

My 2¢ on the subject,

Ferret is not dead, I've been working on it for sometime now. Latest
builds/docs are available at [1].

> Can the Immutable Persistent Data Structures be implemented with a
reference-counting scheme rather than a garbage collector?  This may
improve performance.

That is what Ferret uses. But reference-counting is not cheap. This snippet,

(reduce + 0 (range 1))

will spend most of its time inc/dec reference counts (When running in
single threaded mode with a memory pool.).

> In a similar vein, can the allocation strategy be controlled for these
structures in such a way as to optimize cache locality?

Currently when running on embedded systems or in single threaded mode
ferret can be configured to run using a memory pool. This avoids calling
malloc/heap at runtime, improves performance and determinism you can also
tell how much memory will be used at compile time.  In single threaded mode
this also improves cache locality. (A linked list is just a sequential
memory blocks from the pool allocated on the stack.)

> It wouldn't have to depend on an existing runtime environment like JVM or
JavaScript.

Ferret uses its own runtime. No third party dependencies. Generated code is
strict ISO C++11.

>  Could certain anonymous functions be optimized or inlined in a way that
improves performance over JVM/JS implementations?

Ferret does simple escape analysis when you are not passing a fn as
variable, it is created on the stack. A ferret function is a C++ functor
and no runtime lookup is necessary, compiler should be able to inline them
depending on the optimization level.

> Is there a way to compile C++ code at runtime?  This would be essential
for the REPL and for Macros.

This is not necessary for macros. Ferret is intended for embedded systems a
REPL is not really useful when you have to jump through hoops to
communicate with the device. Ferret does supports macros. Everything is
compiled there is no reader or eval, you can't add/remove/resolve symbols
during runtime. (Unless you setup your own system for it.)

> The main motivation would be performance gains.

Speed is not my main motivation. Ferret is not lighting quick but allows
you to  easily interact with C,C++ libraries or drop in arbitrary C++ code
to squeeze that last bit of performance for critical sections of code. i.e
As someone already said in the thread with ferret you can take the julia
route.

> Julia relies on external native libraries for performance (BLAS, GPU,
whatever). The speed of those libraries is not due to the language (usually
C or ASM) but to the fact that they use algorithms that are heavily
optimized for each hardware architecture

[1] http://dropbox.nakkaya.com/builds/ferret-manual.html

Best,

On Mon, Apr 25, 2016 at 10:47 PM, JvJ  wrote:

> I've been wondering lately about getting Clojure to compile to native
> code, and so I've been doing some looking around.
>
> There are a few projects that are on the right track, such as TinyClojure
>  and Ferret
> ,
> but they are incomplete and don't seem to be under active development any
> more.
>
> I'm wondering about the requirements, how much work it would take, and
> whether or not it would be worth it.  My current thinking is of a
> Clojure->C/C++ compiler.
>
> So far, I have a few topics for discussion that I'm unclear about that
> might be necessary for this kind of project:
>
>- Can the Immutable Persistent Data Structures be implemented with a
>reference-counting scheme rather than a garbage collector?  This may
>improve performance.
>- In a similar vein, can the allocation strategy be controlled for
>these structures in such a way as to optimize cache locality?
>- Can we take advantage of tail-call optimization in existing C++
>compilers?
>- It wouldn't have to depend on an existing runtime environment like
>JVM or JavaScript.
>   - Could this reduce reliance on reflection and increase performance?
>   - Could a new, clojure-optimized runtime be created that improves
>   performance?
>- Could certain anonymous functions be optimized or inlined in a way
>that improves performance over JVM/JS implementations?
>- Is there a way to compile C++ code at runtime?  This would be
>essential for the REPL and for Macros.
>
>
> Let me know if anyone has any thoughts on the matter.
>
> Thanks
>




-- 
Nurullah Akkaya
http://nakkaya.com

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

Re: ANN: Eventually Consistent Datatypes 0.1.0

[Ashish Negi]

Nice..
I was going through the Readme.. but it looked complicated.
Can you write simple cases where this would be useful ?

-- 
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: Porting Clojure to Native Platforms

[Alex Miller]

On Tuesday, April 26, 2016 at 12:23:48 AM UTC-5, Mars0i wrote:
>
> On Tuesday, April 26, 2016 at 12:19:23 AM UTC-5, Mars0i wrote:
>>
>> I was going to say that I'd be surprised if Clojure were as fast as SBCL 
>> (overall, on average, depends on your application, depends on how you code 
>> it, ymmv, etc. ...).  Then I stopped back to check the little benchmarks on 
>> the Computer Language Benchmarks Game 
>> 
>>  
>> .  Whatever it is that those comparisons do, or don't prove, I would no 
>> longer be surprised.
>>
>
> I forgot how much faster Clojure got in 1.7 and 1.8.  I remember Java 
> wiping the floor with Clojure on most of those benchmarks a couple of years 
> ago, but now it's just a little bit faster on average 
>  on those 
> benchmarks.
>

I rewrote most of the Alioth programs back in the Clojure 1.6 timeframe to 
get them in the ballpark of the Java programs. I have timing comparisons 
across 1.6/1.7/1.8 somewhere but the differences are slight (and not all 
improvements) - really the subsequent Clojure versions had little effect on 
the program timings because of the kind of programs they are.

Almost all of the Alioth programs are dominated by tight primitive math 
loops - the bytecode produced by those programs is very similar to the 
output from Java (or Scala for that matter) and thus there's little 
advantage left to gain.

Most of the perf differences between the Java/Scala and Clojure versions 
are attributable to Clojure startup time overhead. As the total program 
timings are mostly in the 5-10 second range, a half second of additional 
startup time is a big factor, percentage-wise. When I've tested lazy var 
prototypes, that definitely helps a bit in reducing this overhead.

Regarding the idiomatic-ness of these programs, I think it's a fair point 
that fast primitive math loops do not fit well with the typical sequence 
(or even transducer) model of data manipulation due to boxing. Rich has 
done some design work on supporting primitive (long/double) transformation 
functions and eventually (not 1.9) that will probably surface in the 
language. When it does, things like primitive vectors will become far more 
useful than they currently are.

I think the compensating factors are that 
1) 99% of most typical (your "typical" may vary) programs is not this kind 
of code
2) it is possible to write most Java primitive/array code in Clojure 
loop/recurs and see similar performance to Java
3) you can always simply write that hot loop in Java or invoke a native lib 
when that is necessary

-- 
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: Macro usage within Clojure community and naming functions which perform actions under certain conditions

[Jason Felice]

I wrote packthread to avoid needing threading counterparts of a bunch of
control forms - it rewrites threading through control forms.

https://github.com/maitria/packthread

It doesn't (yet) solve when you need the threaded value in the middle of a
threading form.  I've had some thoughts about threading, monads, and macros
that I need to sort out (I'd rather not do something anaphoric).  But it
does avoid the combinatorial problem you are seeing when you are trying to
combine cond-> with as->.

-Jason



On Tue, Apr 26, 2016 at 3:16 AM, Ray Miller  wrote:

> On 25 April 2016 at 21:03, Rafał Cieślak  wrote:
>
>> Hi,
>>
>> I'm writing a turn-based game and one of the biggest functions is the one
>> which handles player moves. It receives the current game state (a map) and
>> the index of the cell that the player clicked on (an integer).
>>
>> It has to make a couple of decisions based on the game state. So far I
>> just used -> and cond->. The code looks more or less like this, I
>> removed a bunch of function calls for brevity.
>>
>> (-> game-state
>> ; This stuff happens on each move.
>> (reveal-cell cell-index)
>> ; And this stuff happens only under certain conditions.
>> (cond->
>>   (zero? (:surrounding-power cell))
>>   (reveal-safe-cells cell-index)))
>>
>> The code looks clear IMHO. But then I wanted to add another feature which
>> requires me to make decisions based on the updated value of game-state
>> (the one that is being threaded inside cond->).
>>
>> I thought about cond-> a bit and came to the conclusion that the reason
>> you can't access the currently threaded value is to keep you from writing
>> order-dependent statements. But in my case, I sometimes do want to write
>> order-dependent code. For example, I want to give player exp for killing a
>> monster and then if the exp is above certain threshold, I want to level up
>> his character.
>>
>> So the problem is that I have to check the current value being threaded,
>> but cond-> doesn't allow me to do that.
>>
>>
> You don't need a macro for this sort of thing, and can get some way with
> reduce. For example:
>
> (defn apply-conditional-actions
>   [game-state & pred-actions]
>   (reduce (fn [game-state [pred action]]
> (if (pred game-state)
>   (action game-state)
>   game-state))
>   game-state
>   (partition 2 pred-actions)))
>
> Then call this function with the game-state and a list of pred/action
> pairs:
>
> (apply-conditional-actions game-state
>safe-cell? reveal-safe-cells
>monster-killed? inc-exp-points)
>
>
>
> --
> 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.

[ANN] Specter 0.10.0 released

[Nathan Marz]

Happy to announce the release of Specter 0.10.0. If you're unfamiliar with 
Specter, it's a library that supercharges your ability to query and 
manipulate data structures and has performance rivaling hand-optimized 
code. The README and my talk at Clojure/west are the best introductions to 
the project.

Thanks to @StephenRudolph, @thomasathorne, @bfrabry, @aengelberg, and 
@mfikes for their contributions to this release. Their work constituted the 
bulk of the new functionality.


Highlights of the release:

- No longer uses reducers in cljs version (uses transducers instead). All 
the issues people were having using ALL should now be resolved.
- Zippers are integrated into Specter in the com.rpl.specter.zipper 
namespace.
- subselect, parser, and submap navigators
- Now compatible with bootstrap cljs


Here's a couple of interesting transformations using the new navigators:


(transform (subselect ALL :a even?)
  reverse
  [{:a 2 :b 2} {:a 3} {:a 4} {:a 6} {:a 8}])
;; [{:a 8 :b 2} {:a 3} {:a 6} {:a 4} {:a 2}]

(def STRING<->LONG (parser #(Long/parseLong %) str))
(transform [ALL LAST STRING<->LONG]
  inc
  {:a "1" :b "2"}
  )
;; {:a "2" :b "3"}

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

Lazy evaluation of arguments

[Olek]

Hi!

In short:

I have noticed that in most cases I use macros only for lazy arguments 
evaluation. Why not to make something to use only this feature? It would be 
light version of macro for clojurescript/clojure and easy to grasp for 
newcomers and still powerful in programming (with that you could implement 
binding/scopes/interpreter pattern). I love implicite use of macros where 
from call point of view the user can't distinguish what is function and 
what is macro. 

In long:

Generally the macros are used in compile phase to manipulate AST (or just 
data structures because Clojure is homoiconic) to produce code in order to 
be consumed in evaluation phase.
It is nice to include new language constructs with use of macros but as my 
experience points out for most time I use macros only for changing 
evaluation moment/order.
Maybe there should be some construct like "defnlazy" for which you write 
normal function but all input arguments are evaluated only when you 
explicitly evaluate them.
What we gain? We don't have to deal with # ` @ list eval and separate 
thoughts on read/eval phases, but we still must explicitly say ~ to deref 
passed block of construct as argument.

Also there are some problems to grasp:
- is it safe to implicite convert blocks of construct from statements to 
deref objects
- how it should behave when you pass not deref object to another discussed 
"defnlazy"
- maybe there shouldn't be any defnlazy but you should just implement it in 
arguments destruction so you can use constructs like:

(defn mycrazyif [ statement ~onsuccess ~onfailure ]
   (if statement   ; just evalutated with mycrazyif call
 @onsucess ; deref block in case of success 
  @onfailure)) ; deref block in case of failure


With regards,
Olek

-- 
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: Porting Clojure to Native Platforms

[Raoul Duke]

RC & GC might complement. Don't throw out RC. Also, there are different
kinds of 'performance'. Horses for courses, you know.

https://www.google.com/search?q=bacon+gc+reference+counting+equation

-- 
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: Processing an array

[Olivier Scalbert]

Thanks to all of you for your interesting answers !
Olivier

-- 
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: Lazy evaluation of arguments

[Michael Griffiths]

I'm not sure I fully understand your proposal, but when I really need lazy 
evaluation (which is pretty rare) I reach for `delay` and `force`.

On Tuesday, 26 April 2016 16:41:08 UTC+1, Olek wrote:
>
> Hi!
>
> In short:
>
> I have noticed that in most cases I use macros only for lazy arguments 
> evaluation. Why not to make something to use only this feature? It would be 
> light version of macro for clojurescript/clojure and easy to grasp for 
> newcomers and still powerful in programming (with that you could implement 
> binding/scopes/interpreter pattern). I love implicite use of macros where 
> from call point of view the user can't distinguish what is function and 
> what is macro. 
>
> In long:
>
> Generally the macros are used in compile phase to manipulate AST (or just 
> data structures because Clojure is homoiconic) to produce code in order to 
> be consumed in evaluation phase.
> It is nice to include new language constructs with use of macros but as my 
> experience points out for most time I use macros only for changing 
> evaluation moment/order.
> Maybe there should be some construct like "defnlazy" for which you write 
> normal function but all input arguments are evaluated only when you 
> explicitly evaluate them.
> What we gain? We don't have to deal with # ` @ list eval and separate 
> thoughts on read/eval phases, but we still must explicitly say ~ to deref 
> passed block of construct as argument.
>
> Also there are some problems to grasp:
> - is it safe to implicite convert blocks of construct from statements to 
> deref objects
> - how it should behave when you pass not deref object to another discussed 
> "defnlazy"
> - maybe there shouldn't be any defnlazy but you should just implement it 
> in arguments destruction so you can use constructs like:
>
> (defn mycrazyif [ statement ~onsuccess ~onfailure ]
>(if statement   ; just evalutated with mycrazyif call
>  @onsucess ; deref block in case of success 
>   @onfailure)) ; deref block in case of failure
>
>
> With regards,
> Olek
>

-- 
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: Lazy evaluation of arguments

[Olek]

Yes, the delay and force does the job. Now it would be nice to hide delay 
declaration in arguments destruction as already proposed:

 (den mycrazyif [ statement ~onsuccess ~onfailure ] ; nonsuccess and on 
failure becomes delay objects
   (if statement   ; just evalutated with mycrazyif call
 @onsucess ; deref block in case of success 
  @onfailure)) ; deref block in case of failure


On Tuesday, 26 April 2016 19:59:12 UTC+2, Michael Griffiths wrote:
>
> I'm not sure I fully understand your proposal, but when I really need lazy 
> evaluation (which is pretty rare) I reach for `delay` and `force`.
>
> On Tuesday, 26 April 2016 16:41:08 UTC+1, Olek wrote:
>>
>> Hi!
>>
>> In short:
>>
>> I have noticed that in most cases I use macros only for lazy arguments 
>> evaluation. Why not to make something to use only this feature? It would be 
>> light version of macro for clojurescript/clojure and easy to grasp for 
>> newcomers and still powerful in programming (with that you could implement 
>> binding/scopes/interpreter pattern). I love implicite use of macros where 
>> from call point of view the user can't distinguish what is function and 
>> what is macro. 
>>
>> In long:
>>
>> Generally the macros are used in compile phase to manipulate AST (or just 
>> data structures because Clojure is homoiconic) to produce code in order to 
>> be consumed in evaluation phase.
>> It is nice to include new language constructs with use of macros but as 
>> my experience points out for most time I use macros only for changing 
>> evaluation moment/order.
>> Maybe there should be some construct like "defnlazy" for which you write 
>> normal function but all input arguments are evaluated only when you 
>> explicitly evaluate them.
>> What we gain? We don't have to deal with # ` @ list eval and separate 
>> thoughts on read/eval phases, but we still must explicitly say ~ to deref 
>> passed block of construct as argument.
>>
>> Also there are some problems to grasp:
>> - is it safe to implicite convert blocks of construct from statements to 
>> deref objects
>> - how it should behave when you pass not deref object to another 
>> discussed "defnlazy"
>> - maybe there shouldn't be any defnlazy but you should just implement it 
>> in arguments destruction so you can use constructs like:
>>
>> (defn mycrazyif [ statement ~onsuccess ~onfailure ]
>>(if statement   ; just evalutated with mycrazyif call
>>  @onsucess ; deref block in case of success 
>>   @onfailure)) ; deref block in case of failure
>>
>>
>> With regards,
>> Olek
>>
>

-- 
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: Porting Clojure to Native Platforms

[Gregg Reynolds]

On Apr 26, 2016 12:19 AM, "Mars0i"  wrote:
>
> On Monday, April 25, 2016 at 3:50:45 PM UTC-5, tbc++ wrote:
>>
>> As someone who has spent a fair amount of time playing around with such
things, I'd have to say people vastly misjudge the raw speed you get from
the JVM's JIT and GC. In fact, I'd challenge someone to come up with a
general use, dynamic language that is not based on the JVM and comes even
close to the speed of Clojure.
>
>
> I was going to say that I'd be surprised if Clojure were as fast as SBCL
(overall, on average, depends on your application, depends on how you code
it, ymmv, etc. ...).  Then I stopped back to check the little benchmarks on
the Computer Language Benchmarks Game .  Whatever it is that those
comparisons do, or don't prove, I would no longer be surprised.
>
Wow.  I was going to suggest Lua, but according to the benchmarks it's not
even in the same league.  I wonder what the benchmarks would look like if
they included calls out to C libs.

-- 
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: Porting Clojure to Native Platforms

[Raoul Duke]

Horses for courses. Ask all the game people who use Lua big time. :-)

-- 
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: Porting Clojure to Native Platforms

[Timothy Baldridge]

> Ask all the game people who use Lua big time

See that's the problem. When we say "horses for courses" we have to
actually dig down into what we're saying there. The reason Lua is used in
the gaming community is that it's quite fast, very very small, and simple
for what it does. It also has a fairly decent JIT (in the form of LuaJIT).
But it's still an interpreted language, with a very basic set
of data-structures (basically hash-maps for everything even arrays).

So yeah, the reason it's used in the gaming community is that integrating
the interpreter is fairly easy, and it's "fast enough" to be used for game
logic. But I seriously doubt anyone picked Lua because it had a world-class
GC (because it doesn't), or because out-performed other languages.



On Tue, Apr 26, 2016 at 2:30 PM, Raoul Duke  wrote:

> Horses for courses. Ask all the game people who use Lua big time. :-)
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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: Porting Clojure to Native Platforms

[Gregg Reynolds]

On Apr 26, 2016 3:30 PM, "Raoul Duke"  wrote:
>
> Horses for courses. Ask all the game people who use Lua big time. :-)
>
Sorry, never heard of horses for courses.  Does it mean sth like different
strokes for different folks?  Re: big time users of Lua, I don't know any.
I guess performance isn't so great?

This thread may save me some serious heartache.  As I mentioned previously
I'm about to start a project using the Intel Edison, and maybe also the
Curie. I'm definitely going to experiment with Clojure but I've been kinda
assuming that Lua might be better than Clojure for such constrained
environments.  But maybe I assumed too much.

On the other hand speed is only one aspect of performance, maybe not so
important for IoT stuff.  Space and energy are just as important, maybe
more so.  I wonder if there are any benchmark comparisons for those.

gregg

-- 
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: Lazy evaluation of arguments

[Timothy Baldridge]

Congradulations! You've discovered Fexprs! An ancient technology from a
by-gone age: https://en.wikipedia.org/wiki/Fexpr

On Tue, Apr 26, 2016 at 2:23 PM, Olek  wrote:

> Yes, the delay and force does the job. Now it would be nice to hide delay
> declaration in arguments destruction as already proposed:
>
>  (den mycrazyif [ statement ~onsuccess ~onfailure ] ; nonsuccess and on
> failure becomes delay objects
>(if statement   ; just evalutated with mycrazyif call
>  @onsucess ; deref block in case of success
>   @onfailure)) ; deref block in case of failure
>
>
> On Tuesday, 26 April 2016 19:59:12 UTC+2, Michael Griffiths wrote:
>>
>> I'm not sure I fully understand your proposal, but when I really need
>> lazy evaluation (which is pretty rare) I reach for `delay` and `force`.
>>
>> On Tuesday, 26 April 2016 16:41:08 UTC+1, Olek wrote:
>>>
>>> Hi!
>>>
>>> In short:
>>>
>>> I have noticed that in most cases I use macros only for lazy arguments
>>> evaluation. Why not to make something to use only this feature? It would be
>>> light version of macro for clojurescript/clojure and easy to grasp for
>>> newcomers and still powerful in programming (with that you could implement
>>> binding/scopes/interpreter pattern). I love implicite use of macros where
>>> from call point of view the user can't distinguish what is function and
>>> what is macro.
>>>
>>> In long:
>>>
>>> Generally the macros are used in compile phase to manipulate AST (or
>>> just data structures because Clojure is homoiconic) to produce code in
>>> order to be consumed in evaluation phase.
>>> It is nice to include new language constructs with use of macros but as
>>> my experience points out for most time I use macros only for changing
>>> evaluation moment/order.
>>> Maybe there should be some construct like "defnlazy" for which you write
>>> normal function but all input arguments are evaluated only when you
>>> explicitly evaluate them.
>>> What we gain? We don't have to deal with # ` @ list eval and separate
>>> thoughts on read/eval phases, but we still must explicitly say ~ to deref
>>> passed block of construct as argument.
>>>
>>> Also there are some problems to grasp:
>>> - is it safe to implicite convert blocks of construct from statements to
>>> deref objects
>>> - how it should behave when you pass not deref object to another
>>> discussed "defnlazy"
>>> - maybe there shouldn't be any defnlazy but you should just implement it
>>> in arguments destruction so you can use constructs like:
>>>
>>> (defn mycrazyif [ statement ~onsuccess ~onfailure ]
>>>(if statement   ; just evalutated with mycrazyif call
>>>  @onsucess ; deref block in case of success
>>>   @onfailure)) ; deref block in case of failure
>>>
>>>
>>> With regards,
>>> Olek
>>>
>> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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: Porting Clojure to Native Platforms

[Raoul Duke]

> Sorry, never heard of horses for courses.  Does it mean sth like different
> strokes for different folks?

yessir.

-- 
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: Eventually Consistent Datatypes 0.1.0

[Christian Weilbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26.04.2016 15:46, Ashish Negi wrote:
> Nice.. I was going through the Readme.. but it looked complicated.
>  Can you write simple cases where this would be useful ?

First of all, one should try the Clojure STM first ofc. It also allows
to mark parts of transactions (like incrementing a counter) as
commutative and non-aborting. You only need to drop to eventual
consistency, when consistency becomes too expensive due to parallelism.
For in-memory datatypes, in contrast to CRDTs, there is no
availability problem (unless you would start considering CPU
failures). But there is the contention problem for the STM. The idea
behind the research is, that to avoid this, you start implementing
eventual consistent in-memory datastructures.

A made-up simple use case would be a global log of summarized
operations for a system with 100 CPUs running mostly agents for
example. In this scenario there is no consistency (or serializability)
anyway, but you would like a global log to track progress of the
system. You could use the add-only-bag in this case without slowing
down the agents. They will merge with the global log/bag from time to
time. While 100 CPU machines might sound a bit extreme, I think we are
approaching them soon. GPUs are already at over 1000 cores.

Should I add some more information somewhere to make it better
understandable?

Christian

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJXH9pwAAoJEICbLivqiPOFkigP/RRnLmHYhrYAAHtSQDu1UN4v
c3tS3zZqB5IgORUuCdcRi6rmm0DmeVTJXool3pELuWBsd/2NwpMxwHXnr72CsNgX
Jw7/73wq3/i9zTutaY6nRTaiUVg64N1zE8QqhJ/0oB8cSlPB/VuecP1Zc5Ie5rWW
TF0LJyyojr/PZg+OpnofZ2InI/EhgabV5hMmpxt1d0aIPqxtxMHXZTQ2A+cAqiHK
ZJncd8iFn4FMydaKTpVsjZegNIdHMH08KZVY1JdI91tf0YFQPwA/VD4c66j7hzBi
s058UurjqWFZedxe5Ic3eIbn6M0fwJMxzfjip91geJzvaSPG8RMifFDiBv5yOSLO
EIdM5yB515QJPla9moYESRvE/gace7mqI4QTOkpK1oVZAmO+Cjrpp/FrQUjgE0+Q
ObmqXJjfetFT8aaed+ZYrK0Kz1vfhNCuBDLvlKobK60j4i7rb+lm2nRfSLoPehLr
ibZ1aH/e0/BZ0fwuDHtiKYe0WdUL7DAheoHAnOeslDtdrrNJQxcGGmGIHbW0rEDx
YE4wKRkvF7DzjyvTHSVJ0ripsPcBGwPhYLAT+Abx6zniTOwBu6Y2qSEicX6vSiuz
BskbTughvbVyn09gF4co70jptYK9GguGHCBoHAyNx5jTY0FpNBoUR86lYVW+fPCa
NmLzLM8KD53dpMqF3zxS
=UoKO
-END PGP SIGNATURE-

-- 
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: Porting Clojure to Native Platforms

[Timothy Baldridge]

I wouldn't underestimate ClojureScript running on V8. That's another
platform that's quite fast. And there are a lot of people trying very hard
to make JS engines fast, could consider leveraging that.

On Tue, Apr 26, 2016 at 3:09 PM, Raoul Duke  wrote:

> > Sorry, never heard of horses for courses.  Does it mean sth like
> different
> > strokes for different folks?
>
> yessir.
>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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: Porting Clojure to Native Platforms

[Christian Weilbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 25.04.2016 22:02, Jason Felice wrote:
> There was talk of an LLVM backend a while back, but I believe LLVM
> was deemed too low-level to be useful.  That was, in fact, why I
> signed the contributor agreement.  So, I'd love to see some
> movement on a C back-end.
> 
> Gambit Scheme has a special form that emits C (or C++) code.  It's
> very useful.  I can't remember which Lisp it was, but there was
> definitely a lisp which had an emit-C as it's *only* special form.
> It might have been one of the embedded schemes.
> 
> Last time I looked, I also saw ClojureC:  It looked useful, but
> hasn't been touched in 3 years.h

Just because you mentioned it, I played a lot with the ClojureC
compiler and implemented the metacircular evaluator for it two years
ago. There is a really nice REPL for it:

https://github.com/bertfrees/cljc.repl

But ClojureC is not fast, because statically compiling all the
abstractions in (look at the emitted C code), makes it slow. You can
directly call C though and get a self-contained binary. I guess Ferret
is better for embedded development though.

I found mjolnir really interesting and would like to see a way to
build native building blocks from Clojure that way. At least one could
implement performance critical numeric routines directly in Clojure
including annotations and call them from the JVM (e.g. on the GPU).
This should cover a lot of what Julia does, but I am not familiar
enough with its internals (e.g. JIT and how it standardizes tensor
memory layout etc.).


Cheers,
Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJXH99KAAoJEICbLivqiPOFTNUP/ik2l/Bg528fvcBlX4WG+kOr
zLlNL7YgXu+rx/kZ+yVZuN/IQo5MW/TdRmOuZz7qkqb0nOuYNJ2J/fij4pUXISnn
tvlgVF4Pasj4sV0e/i4ZL5vo7T8KMd4UIb2D8YFdmNMXXFUw1OgBf10ucQvtljxt
eHGiDIf2etLYIfZupJAS5jtZqW17FK+K10sTZGdd5ZlCMUctl708BPXLlwayjpXM
erIXc7/hS5YIemC0iHEgNLYfyFLxIPa/Jid6PW3kZ7bJeB1QmwBTn472nI9GYMln
LF3DVx6QWK9B210qFz4HemgEKhkKj8/wNRR2uNpsBsYtYoMkUvB2tGeWuw6620G+
YFA2VOsVGpHaPPBxPgJLpT6/mN+ELmpmHdDk+L/UlFHw4eP/V/FlCNc1rnoR0HlM
j9Sqz11eJyy4rZRINC1N6PyXNDlTAFVOUypbb9dTAx7s2h/nBvqqLRAuMQ2kHHPf
8+Mp13EsSu2AaHDW/rFkM158zARn04gHiuFvtlCSjqZY6aCSCYAfKgY+v6YKEG1T
lhqyOlVo9i/tXCDCE3xov30Tp1BdqHDjuGyckfkkxFAJdzoylbuyCewR5GMppyie
FH93BZ63niWtwVXo8vuMAQHkiJnnVcw9BNqlFCI5cJH3LUTx0Kt/Jk1LhKxs0256
TZg/fBZqNQAYQtHMorJ1
=VsLc
-END PGP SIGNATURE-

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

Compile ClojureScript in Java application

[Martin Grześlowski]

 

I'm trying to compile String that contains Clojure Script code in 
Java/Groovy. 

I'm not really happy with using *"java -jar ...".execute()*.


Is there any way to invoke clojurescript library (version 1.8.51) to 
compile code?

-- 
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: Porting Clojure to Native Platforms

[Rangel Spasov]

tbc++ - given your experience, would you consider a Clojure port to Erlang 
VM a viable idea for production workloads? I know Elixir comes pretty 
close, but I still prefer Lisp : ) .

On Monday, April 25, 2016 at 1:50:45 PM UTC-7, tbc++ wrote:
>
> As someone who has spent a fair amount of time playing around with such 
> things, I'd have to say people vastly misjudge the raw speed you get from 
> the JVM's JIT and GC. In fact, I'd challenge someone to come up with a 
> general use, dynamic language that is not based on the JVM and comes even 
> close to the speed of Clojure. 
>
> A LLVM/C++/RPython based version of Clojure would on a good day come in at 
> about 1/10 the speed of Clojure on the JVM for general use cases. 
>
>
> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke  > wrote:
>
>> > The main motivation would be performance gains.
>>
>> blah? so many impedance mismatches and layers of indirection that i
>> don't think it will gain much? i mean, it would probably be better to
>> spend time tuning gc parameters or something. just a rant / guess.
>> e.g. robovm is for some use cases perfectly fine performance wise
>> believe it or not.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

-- 
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: Lazy evaluation of arguments

[Olek]

Wow ;-) now I know that I'm talking about fexprs ;-) So my propose is to 
back them alive again. Let the new community consume them in new manner and 
judge theirs usefulness.


On Tuesday, 26 April 2016 23:04:09 UTC+2, tbc++ wrote:
>
> Congradulations! You've discovered Fexprs! An ancient technology from a 
> by-gone age: https://en.wikipedia.org/wiki/Fexpr
>
> On Tue, Apr 26, 2016 at 2:23 PM, Olek 
> > wrote:
>
>> Yes, the delay and force does the job. Now it would be nice to hide delay 
>> declaration in arguments destruction as already proposed:
>>
>>  (den mycrazyif [ statement ~onsuccess ~onfailure ] ; nonsuccess and on 
>> failure becomes delay objects
>>(if statement   ; just evalutated with mycrazyif call
>>  @onsucess ; deref block in case of success 
>>   @onfailure)) ; deref block in case of failure
>>
>>
>> On Tuesday, 26 April 2016 19:59:12 UTC+2, Michael Griffiths wrote:
>>>
>>> I'm not sure I fully understand your proposal, but when I really need 
>>> lazy evaluation (which is pretty rare) I reach for `delay` and `force`.
>>>
>>> On Tuesday, 26 April 2016 16:41:08 UTC+1, Olek wrote:

 Hi!

 In short:

 I have noticed that in most cases I use macros only for lazy arguments 
 evaluation. Why not to make something to use only this feature? It would 
 be 
 light version of macro for clojurescript/clojure and easy to grasp for 
 newcomers and still powerful in programming (with that you could implement 
 binding/scopes/interpreter pattern). I love implicite use of macros where 
 from call point of view the user can't distinguish what is function and 
 what is macro. 

 In long:

 Generally the macros are used in compile phase to manipulate AST (or 
 just data structures because Clojure is homoiconic) to produce code in 
 order to be consumed in evaluation phase.
 It is nice to include new language constructs with use of macros but as 
 my experience points out for most time I use macros only for changing 
 evaluation moment/order.
 Maybe there should be some construct like "defnlazy" for which you 
 write normal function but all input arguments are evaluated only when you 
 explicitly evaluate them.
 What we gain? We don't have to deal with # ` @ list eval and separate 
 thoughts on read/eval phases, but we still must explicitly say ~ to deref 
 passed block of construct as argument.

 Also there are some problems to grasp:
 - is it safe to implicite convert blocks of construct from statements 
 to deref objects
 - how it should behave when you pass not deref object to another 
 discussed "defnlazy"
 - maybe there shouldn't be any defnlazy but you should just implement 
 it in arguments destruction so you can use constructs like:

 (defn mycrazyif [ statement ~onsuccess ~onfailure ]
(if statement   ; just evalutated with mycrazyif call
  @onsucess ; deref block in case of success 
   @onfailure)) ; deref block in case of failure


 With regards,
 Olek

>>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

-- 
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: Lazy evaluation of arguments

[Olek]

Here is a nice discussion about fexprs: 
http://lambda-the-ultimate.org/node/3640



On Tuesday, 26 April 2016 23:04:09 UTC+2, tbc++ wrote:
>
> Congradulations! You've discovered Fexprs! An ancient technology from a 
> by-gone age: https://en.wikipedia.org/wiki/Fexpr
>
> On Tue, Apr 26, 2016 at 2:23 PM, Olek 
> > wrote:
>
>> Yes, the delay and force does the job. Now it would be nice to hide delay 
>> declaration in arguments destruction as already proposed:
>>
>>  (den mycrazyif [ statement ~onsuccess ~onfailure ] ; nonsuccess and on 
>> failure becomes delay objects
>>(if statement   ; just evalutated with mycrazyif call
>>  @onsucess ; deref block in case of success 
>>   @onfailure)) ; deref block in case of failure
>>
>>
>> On Tuesday, 26 April 2016 19:59:12 UTC+2, Michael Griffiths wrote:
>>>
>>> I'm not sure I fully understand your proposal, but when I really need 
>>> lazy evaluation (which is pretty rare) I reach for `delay` and `force`.
>>>
>>> On Tuesday, 26 April 2016 16:41:08 UTC+1, Olek wrote:

 Hi!

 In short:

 I have noticed that in most cases I use macros only for lazy arguments 
 evaluation. Why not to make something to use only this feature? It would 
 be 
 light version of macro for clojurescript/clojure and easy to grasp for 
 newcomers and still powerful in programming (with that you could implement 
 binding/scopes/interpreter pattern). I love implicite use of macros where 
 from call point of view the user can't distinguish what is function and 
 what is macro. 

 In long:

 Generally the macros are used in compile phase to manipulate AST (or 
 just data structures because Clojure is homoiconic) to produce code in 
 order to be consumed in evaluation phase.
 It is nice to include new language constructs with use of macros but as 
 my experience points out for most time I use macros only for changing 
 evaluation moment/order.
 Maybe there should be some construct like "defnlazy" for which you 
 write normal function but all input arguments are evaluated only when you 
 explicitly evaluate them.
 What we gain? We don't have to deal with # ` @ list eval and separate 
 thoughts on read/eval phases, but we still must explicitly say ~ to deref 
 passed block of construct as argument.

 Also there are some problems to grasp:
 - is it safe to implicite convert blocks of construct from statements 
 to deref objects
 - how it should behave when you pass not deref object to another 
 discussed "defnlazy"
 - maybe there shouldn't be any defnlazy but you should just implement 
 it in arguments destruction so you can use constructs like:

 (defn mycrazyif [ statement ~onsuccess ~onfailure ]
(if statement   ; just evalutated with mycrazyif call
  @onsucess ; deref block in case of success 
   @onfailure)) ; deref block in case of failure


 With regards,
 Olek

>>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> “One of the main causes of the fall of the Roman Empire was that–lacking 
> zero–they had no way to indicate successful termination of their C 
> programs.”
> (Robert Firth) 
>

-- 
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: Porting Clojure to Native Platforms

[Colin Fleming]

Of course, most people using Lua seriously use LuaJit, which is
surprisingly fast. However it's very prone to the branching problems you
described earlier for complex application code. I believe LuaJit does
optimise hashmaps when they're used as arrays etc. LuaJit really shines
when used for something with a really tight inner loop with perhaps a
couple of main branches - it's used for packet filtering, for example, and
it's possible to get more or less the same performance as C under those
restricted conditions but with dynamic adaptation to traffic conditions for
things like DDOS attacks.

One thing that LuaJit does offer is much better control over memory layout
than Java/JS etc. You can manually allocate blocks of memory and treat them
as arrays of floats etc - it would be interesting to see how fast it would
run something like a raytracer or a mandelbrot calculation, I'd imagine it
could get pretty fast.

On 27 April 2016 at 09:01, Timothy Baldridge  wrote:

> > Ask all the game people who use Lua big time
>
> See that's the problem. When we say "horses for courses" we have to
> actually dig down into what we're saying there. The reason Lua is used in
> the gaming community is that it's quite fast, very very small, and simple
> for what it does. It also has a fairly decent JIT (in the form of LuaJIT).
> But it's still an interpreted language, with a very basic set
> of data-structures (basically hash-maps for everything even arrays).
>
> So yeah, the reason it's used in the gaming community is that integrating
> the interpreter is fairly easy, and it's "fast enough" to be used for game
> logic. But I seriously doubt anyone picked Lua because it had a world-class
> GC (because it doesn't), or because out-performed other languages.
>
>
>
> On Tue, Apr 26, 2016 at 2:30 PM, Raoul Duke  wrote:
>
>> Horses for courses. Ask all the game people who use Lua big time. :-)
>>
>> --
>> 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.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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: Porting Clojure to Native Platforms

[Plínio Balduino]

Hi, J

Based on my yet small experience:

Can the Immutable Persistent Data Structures be implemented with a
reference-counting scheme rather than a garbage collector?  This may
improve performance.
- Yes, using Smart Pointers. I'm trying something like this, but I'm still
in the very beginning. I don't have any info about the behavior of these
structures under heavy usage yet.

In a similar vein, can the allocation strategy be controlled for these
structures in such a way as to optimize cache locality?
- AFAIK, not with the default memory allocator. There are some custom
memory allocators for C/C++, but I never used it.

Can we take advantage of tail-call optimization in existing C++ compilers?
- Since you can't control by default the call stack, in a first moment you
can't do it. You could do it writing your own way to control the call
stack, where it surely will make you develop your own virtual machine or
your own compiler with this optimization. Two herculean tasks IMHO. Or you
can repeat the Clojure approach and use explicit loop/recur implementing it
internally as a loop.

It wouldn't have to depend on an existing runtime environment like JVM or
JavaScript.
* Could this reduce reliance on reflection and increase performance?
- You will need to implement your own way to control reflection. There's no
guarantee that this could improve performance.

* Could a new, clojure-optimized runtime be created that improves
performance?
- No idea

* Could certain anonymous functions be optimized or inlined in a way that
improves performance over JVM/JS implementations?
- Since the compiler is yours, yes. But I don't know how much effort it
would take.

* Is there a way to compile C++ code at runtime?  This would be essential
for the REPL and for Macros.
- I never heard about on demand native code generation and execution. I
think it could be a paradise for viruses, but I know almost nothing about
this field. Unless of course you're generating code for (your own|a)
virtual machine, so the rules are different.

I hope I helped and I really would like to see this project, if you start
to develop it.

Regards

Plínio

On Mon, Apr 25, 2016 at 4:47 PM, JvJ  wrote:

>
>
> I've been wondering lately about getting Clojure to compile to native
> code, and so I've been doing some looking around.
>
> There are a few projects that are on the right track, such as TinyClojure
>  and Ferret
> ,
> but they are incomplete and don't seem to be under active development any
> more.
>
> I'm wondering about the requirements, how much work it would take, and
> whether or not it would be worth it.  My current thinking is of a
> Clojure->C/C++ compiler.
>
> So far, I have a few topics for discussion that I'm unclear about that
> might be necessary for this kind of project:
>
>- Can the Immutable Persistent Data Structures be implemented with a
>reference-counting scheme rather than a garbage collector?  This may
>improve performance.
>- In a similar vein, can the allocation strategy be controlled for
>these structures in such a way as to optimize cache locality?
>- Can we take advantage of tail-call optimization in existing C++
>compilers?
>- It wouldn't have to depend on an existing runtime environment like
>JVM or JavaScript.
>   - Could this reduce reliance on reflection and increase performance?
>   - Could a new, clojure-optimized runtime be created that improves
>   performance?
>- Could certain anonymous functions be optimized or inlined in a way
>that improves performance over JVM/JS implementations?
>- Is there a way to compile C++ code at runtime?  This would be
>essential for the REPL and for Macros.
>
>
> Let me know if anyone has any thoughts on the matter.
>
> 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.
>

-- 
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://gro

Re: Compile ClojureScript in Java application

[Francis Avila]

On Tuesday, April 26, 2016 at 4:38:02 PM UTC-5, Martin Grześlowski wrote:
>
> I'm trying to compile String that contains Clojure Script code in 
> Java/Groovy. 
>
> I'm not really happy with using *"java -jar ...".execute()*.
>
>
> Is there any way to invoke clojurescript library (version 1.8.51) to 
> compile code?
>

The clojurescript compiler is a clojure library, so you can invoke it from 
Java the same way you can invoke any Clojure code from java.

Basics of invoking Clojure from Java: http://stackoverflow.com/a/23555959

It will probably look something like:

IFn require = Clojure.var("clojure.core", "require");
require.invoke(Clojure.read("cljs.build.api"));
IFn build = Clojure.var("cljs.build.api","build");
build.invoke("src", Clojure.read("{:output-to ...}"));



The second argument to build can be a HashMap you construct in your Java 
code. (Make sure the keys are Keyword type.)

-- 
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: Porting Clojure to Native Platforms

[Timothy Baldridge]

>> would you consider a Clojure port to Erlang VM a viable idea for
production workloads? I know Elixir comes pretty close, but I still prefer
Lisp : ) .

I looked into that at one point, but sadly the Erlang VM is a really poor
platform for a Clojure port. Here are a few reasons why:

Unit of compilation is the module, not sure how that all plays out with the
Elixir repl, but it's not optimal. From what I can tell, re-deffing a defn
would require re-loading an entire namespace (module) or require
one-defn-per-module.

No native polymorphism. Elixir fakes it with structs (think defrecords)
with a custom hidden field, then looks up functions in a hash map on that
field to dispatch.

Total lack of shared state. This one doesn't sound like a problem till you
think of how to do things like a REPL that can re-def defns at runtime.
Also, clojure makes fairly liberal use of atoms, vars, and volatile! cells.
Even stuff like lazy seqs leverage limited mutability and set-once
behaviors. You don't have any of that in BEAM, just actors. And converting
all those things to actors would be a major mistake.

So can you have a lisp flavored Erlang? Sure. But what you're left with
would not be Clojure.

Timothy





On Tue, Apr 26, 2016 at 3:55 PM, Rangel Spasov  wrote:

> tbc++ - given your experience, would you consider a Clojure port to Erlang
> VM a viable idea for production workloads? I know Elixir comes pretty
> close, but I still prefer Lisp : ) .
>
> On Monday, April 25, 2016 at 1:50:45 PM UTC-7, tbc++ wrote:
>>
>> As someone who has spent a fair amount of time playing around with such
>> things, I'd have to say people vastly misjudge the raw speed you get from
>> the JVM's JIT and GC. In fact, I'd challenge someone to come up with a
>> general use, dynamic language that is not based on the JVM and comes even
>> close to the speed of Clojure.
>>
>> A LLVM/C++/RPython based version of Clojure would on a good day come in
>> at about 1/10 the speed of Clojure on the JVM for general use cases.
>>
>>
>> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke  wrote:
>>
>>> > The main motivation would be performance gains.
>>>
>>> blah? so many impedance mismatches and layers of indirection that i
>>> don't think it will gain much? i mean, it would probably be better to
>>> spend time tuning gc parameters or something. just a rant / guess.
>>> e.g. robovm is for some use cases perfectly fine performance wise
>>> believe it or not.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
> --
> 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.
>



-- 
“One of the main causes of the fall of the Roman Empire was that–lacking
zero–they had no way to indicate successful termination of their C
programs.”
(Robert Firth)

-- 
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: Porting Clojure to Native Platforms

[Plínio Balduino]

LISP Flavoured Erlang:
http://lfe.io/

On Tue, Apr 26, 2016 at 9:45 PM, Timothy Baldridge 
wrote:

> >> would you consider a Clojure port to Erlang VM a viable idea for
> production workloads? I know Elixir comes pretty close, but I still prefer
> Lisp : ) .
>
> I looked into that at one point, but sadly the Erlang VM is a really poor
> platform for a Clojure port. Here are a few reasons why:
>
> Unit of compilation is the module, not sure how that all plays out with
> the Elixir repl, but it's not optimal. From what I can tell, re-deffing a
> defn would require re-loading an entire namespace (module) or require
> one-defn-per-module.
>
> No native polymorphism. Elixir fakes it with structs (think defrecords)
> with a custom hidden field, then looks up functions in a hash map on that
> field to dispatch.
>
> Total lack of shared state. This one doesn't sound like a problem till you
> think of how to do things like a REPL that can re-def defns at runtime.
> Also, clojure makes fairly liberal use of atoms, vars, and volatile! cells.
> Even stuff like lazy seqs leverage limited mutability and set-once
> behaviors. You don't have any of that in BEAM, just actors. And converting
> all those things to actors would be a major mistake.
>
> So can you have a lisp flavored Erlang? Sure. But what you're left with
> would not be Clojure.
>
> Timothy
>
>
>
>
>
> On Tue, Apr 26, 2016 at 3:55 PM, Rangel Spasov  wrote:
>
>> tbc++ - given your experience, would you consider a Clojure port to
>> Erlang VM a viable idea for production workloads? I know Elixir comes
>> pretty close, but I still prefer Lisp : ) .
>>
>> On Monday, April 25, 2016 at 1:50:45 PM UTC-7, tbc++ wrote:
>>>
>>> As someone who has spent a fair amount of time playing around with such
>>> things, I'd have to say people vastly misjudge the raw speed you get from
>>> the JVM's JIT and GC. In fact, I'd challenge someone to come up with a
>>> general use, dynamic language that is not based on the JVM and comes even
>>> close to the speed of Clojure.
>>>
>>> A LLVM/C++/RPython based version of Clojure would on a good day come in
>>> at about 1/10 the speed of Clojure on the JVM for general use cases.
>>>
>>>
>>> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke  wrote:
>>>
 > The main motivation would be performance gains.

 blah? so many impedance mismatches and layers of indirection that i
 don't think it will gain much? i mean, it would probably be better to
 spend time tuning gc parameters or something. just a rant / guess.
 e.g. robovm is for some use cases perfectly fine performance wise
 believe it or not.

 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> “One of the main causes of the fall of the Roman Empire was that–lacking
>>> zero–they had no way to indicate successful termination of their C
>>> programs.”
>>> (Robert Firth)
>>>
>> --
>> 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.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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 ar

Re: Porting Clojure to Native Platforms

[Rangel]

Thanks for the detailed write up! I guess a carefully chosen subset of
Clojure can make sense then, but definitely not all of Clojure.

On Tue, Apr 26, 2016 at 5:45 PM, Timothy Baldridge 
wrote:

> >> would you consider a Clojure port to Erlang VM a viable idea for
> production workloads? I know Elixir comes pretty close, but I still prefer
> Lisp : ) .
>
> I looked into that at one point, but sadly the Erlang VM is a really poor
> platform for a Clojure port. Here are a few reasons why:
>
> Unit of compilation is the module, not sure how that all plays out with
> the Elixir repl, but it's not optimal. From what I can tell, re-deffing a
> defn would require re-loading an entire namespace (module) or require
> one-defn-per-module.
>
> No native polymorphism. Elixir fakes it with structs (think defrecords)
> with a custom hidden field, then looks up functions in a hash map on that
> field to dispatch.
>
> Total lack of shared state. This one doesn't sound like a problem till you
> think of how to do things like a REPL that can re-def defns at runtime.
> Also, clojure makes fairly liberal use of atoms, vars, and volatile! cells.
> Even stuff like lazy seqs leverage limited mutability and set-once
> behaviors. You don't have any of that in BEAM, just actors. And converting
> all those things to actors would be a major mistake.
>
> So can you have a lisp flavored Erlang? Sure. But what you're left with
> would not be Clojure.
>
> Timothy
>
>
>
>
>
> On Tue, Apr 26, 2016 at 3:55 PM, Rangel Spasov  wrote:
>
>> tbc++ - given your experience, would you consider a Clojure port to
>> Erlang VM a viable idea for production workloads? I know Elixir comes
>> pretty close, but I still prefer Lisp : ) .
>>
>> On Monday, April 25, 2016 at 1:50:45 PM UTC-7, tbc++ wrote:
>>>
>>> As someone who has spent a fair amount of time playing around with such
>>> things, I'd have to say people vastly misjudge the raw speed you get from
>>> the JVM's JIT and GC. In fact, I'd challenge someone to come up with a
>>> general use, dynamic language that is not based on the JVM and comes even
>>> close to the speed of Clojure.
>>>
>>> A LLVM/C++/RPython based version of Clojure would on a good day come in
>>> at about 1/10 the speed of Clojure on the JVM for general use cases.
>>>
>>>
>>> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke  wrote:
>>>
 > The main motivation would be performance gains.

 blah? so many impedance mismatches and layers of indirection that i
 don't think it will gain much? i mean, it would probably be better to
 spend time tuning gc parameters or something. just a rant / guess.
 e.g. robovm is for some use cases perfectly fine performance wise
 believe it or not.

 --
 You received this message because you are subscribed to the Google
 Groups "Clojure" group.
 To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>>
>>> --
>>> “One of the main causes of the fall of the Roman Empire was that–lacking
>>> zero–they had no way to indicate successful termination of their C
>>> programs.”
>>> (Robert Firth)
>>>
>> --
>> 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.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> 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 a

Callback fn in core.async/put!

[Alan Thompson]

The docs for put! say

(put! port val)
(put! port val fn0)
(put! port val fn0 on-caller?)
Asynchronously puts a val into port, calling fn0 (if supplied) when
 complete. nil values are not allowed. Will throw if closed. If
 on-caller? (default true) is true, and the put is immediately
 accepted, will call fn0 on calling thread.  Returns nil.


but it doesn't say much about fn0.  Apparently it needs to be a 1-arg
function (error msg for otherwise).  But, what is the arg passed to it?

Alan

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

Tiny fix for LispReader

[Frank Pursel]

I believe the following line should replace the current 1.8.0 
jvm/clojure/lang/LispReader.java line 68:

static Pattern intPat =
Pattern.compile(

"([-+]?)(?:(0)|(0*[1-9][0-9]*)|0[xX]([0-9A-Fa-f]+)|([0-7]{3})|([1-9][0-9]?)[rR]([0-9A-Za-z]+)|0[0-9]+)(N)?");


Without this change the 1.8.0 clojure reader fails on some simple things 
like:

(read-string "08")
(read-string "09")

I see that the prior commit was trying to get old style octal identifiers 
to work (and this change doesn't get this right either) but octal can still 
be correctly read using the radix notation, eg (read-string "8r45") works. 

Perhaps someone here can get this change or a more sophisticated fix 
committed that will allow numeric strings with leading zeros to be 
successfully read.  

Regards,
Frank Pursel

-- 
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: Tiny fix for LispReader

[Andy Fingerhut]

Frank:

I am pretty sure that the intent is that strings like 077 are read as
octal, and in Clojure 1.8.0 this is what happens, e.g. (read-string "077")
evaluates to the integer 63 (decimal), not 77.  Thus it is intentional that
(read-string "08") and (read-string "09") throw exceptions.

Andy

On Tue, Apr 26, 2016 at 8:51 PM, Frank Pursel 
wrote:

> I believe the following line should replace the current 1.8.0
> jvm/clojure/lang/LispReader.java line 68:
>
> static Pattern intPat =
> Pattern.compile(
>
> "([-+]?)(?:(0)|(0*[1-9][0-9]*)|0[xX]([0-9A-Fa-f]+)|([0-7]{3})|([1-9][0-9]?)[rR]([0-9A-Za-z]+)|0[0-9]+)(N)?");
>
>
> Without this change the 1.8.0 clojure reader fails on some simple things
> like:
>
> (read-string "08")
> (read-string "09")
>
> I see that the prior commit was trying to get old style octal identifiers
> to work (and this change doesn't get this right either) but octal can still
> be correctly read using the radix notation, eg (read-string "8r45") works.
>
> Perhaps someone here can get this change or a more sophisticated fix
> committed that will allow numeric strings with leading zeros to be
> successfully read.
>
> Regards,
> Frank Pursel
>
> --
> 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: Tiny fix for LispReader

[Erik Assum]

In addition to what Andy said, this same behavior was recently implemented in 
tools.reader (the Clojure impel of lisp reader) 
http://dev.clojure.org/jira/browse/TRDR-36

Erik. 
-- 
i farta

> Den 27. apr. 2016 kl. 07.13 skrev Andy Fingerhut :
> 
> Frank:
> 
> I am pretty sure that the intent is that strings like 077 are read as octal, 
> and in Clojure 1.8.0 this is what happens, e.g. (read-string "077") evaluates 
> to the integer 63 (decimal), not 77.  Thus it is intentional that 
> (read-string "08") and (read-string "09") throw exceptions.
> 
> Andy
> 
>> On Tue, Apr 26, 2016 at 8:51 PM, Frank Pursel  wrote:
>> I believe the following line should replace the current 1.8.0 
>> jvm/clojure/lang/LispReader.java line 68:
>> 
>> static Pattern intPat =
>> Pattern.compile(
>> 
>> "([-+]?)(?:(0)|(0*[1-9][0-9]*)|0[xX]([0-9A-Fa-f]+)|([0-7]{3})|([1-9][0-9]?)[rR]([0-9A-Za-z]+)|0[0-9]+)(N)?");
>> 
>> 
>> Without this change the 1.8.0 clojure reader fails on some simple things 
>> like:
>> 
>> (read-string "08")
>> (read-string "09")
>> 
>> I see that the prior commit was trying to get old style octal identifiers to 
>> work (and this change doesn't get this right either) but octal can still be 
>> correctly read using the radix notation, eg (read-string "8r45") works. 
>> 
>> Perhaps someone here can get this change or a more sophisticated fix 
>> committed that will allow numeric strings with leading zeros to be 
>> successfully read.  
>> 
>> Regards,
>> Frank Pursel
>> -- 
>> 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.