Hi.
The combo:
[org.clojure/clojure "1.9.0-alpha20"]
[org.clojure/clojurescript "1.9.660"]
seems to be emitting broken js:
return new cljs.core.PersistentVector(null, 2, 5,
cljs.core.PersistentVector.EMPTY_NODE, [##NaN,##NaN], null);
With 1.9.0-alpha19 it gives:
return new cljs.core.Persiste
The question of markup has tended to attract many far-sighted suggestions
that turn it into a bike shed. Luckily, the undertaking needs no blessing.
Clojure's doc strings change infrequently, if ever! Someone may set forth a
markup language and create a fork with marked-up doc strings, and
tool
That looks like a cljs issue, it shouldn't emit NaNs at all there, not
relevant to the clojure change around how they are printed.
On 8 Sep 2017 8:03 a.m., "Tommi Reiman" wrote:
Hi.
The combo:
[org.clojure/clojure "1.9.0-alpha20"]
[org.clojure/clojurescript "1.9.660"]
seems to be emitting bro
On Thu, Sep 7, 2017 at 10:20 PM, Bill Robertson
wrote:
> Does it run in Java 9?
>
Excellent question! The short and possibly misleading answer is yes, as do
all other 1.9 alphas, and 1.8, and probably earlier versions of Clojure as
well *with some important caveats*:
* CLJ-2077 - clojure.core c
>
> You can probably also avoid the 60- to 80-second wait if you call
> (shutdown-agents) at the end of your program.
>
My program is endless =)
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegrou
Are there any plans to make the ## reader macro extensible in the future?
--
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
On Fri, Sep 8, 2017 at 2:17 PM, Joel Holdbrooks
wrote:
> Are there any plans to make the ## reader macro extensible in the future?
No. For most data uses you are better served by tagged literals.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To
Relatedly, what is the rationale for this requiring or benefiting from new
syntax, versus using tagged literals for things like Inf & -Inf. Is it a
compiler performance optimization or something like that?
On Friday, September 8, 2017 at 12:27:02 PM UTC-7, Alex Miller wrote:
>
>
> On Fri, Sep 8
It's a judgement call when to add a new reader type vs when to use a tagged
literal. Using the new reader type allows for greater concision for sure
(##Inf vs ##double Inf) which seems particularly useful with numbers. It
should allow for faster reading, printing, etc.
On Friday, September 8,
Similar to Tommi, I'm also seeing issues with the new syntax when combined with
JS on our front-end:
[org.clojure/clojure "1.9.0-alpha20"]
[org.clojure/clojurescript "1.9.908"]
> SEVERE: my-project/client/target/android/cljs/core.js:3579: ERROR - Parse
> error. primary expression expected
> cas
10 matches
Mail list logo
