After a bit of digging, it appears that dependent types, at least the Liquid
Haskell kind, could catch it, but could also miss it. If you've constrained
everything very tightly, it would catch it, if not, it could miss it.
In this regard, generative testing could still end up being practically m
Sorry, I didn't mean fraction type, I meant fraction literal.
All I can say is neither Java, Kotlin or Ceylon have a non zero type. Not sure
about heck or frege.
Also, I was eventually leading to more than just the literal 10/0. If the zero
in this division comes from another formula, or is dy
On Apr 8, 2017 3:47 PM, "Gregg Reynolds" wrote:
On Apr 7, 2017 9:57 PM, "Didier" wrote:
| I think you missed my point, which is only "Spec is great as we have the
power of Clojure" - sure, just don't forget you have the power of ANOther
language in that language as well.
Hum, I've probably
On Apr 7, 2017 9:57 PM, "Didier" wrote:
| I think you missed my point, which is only "Spec is great as we have the
power of Clojure" - sure, just don't forget you have the power of ANOther
language in that language as well.
Hum, I've probably missed your point sorry, I'm still not following.
They look great. My main reservation about Kotlin (and Fantom?) is the
mutability. I fear Clojure has spoiled mutable data structures for me :-).
On Saturday, 8 April 2017, Didier wrote:
> I have longed for a statically compiled language with type inference with
>>> the simplicity and consistenc
>
> I have longed for a statically compiled language with type inference with
>> the simplicity and consistency of Clojure's syntax that also supports
>> generative testing and works on the JVM but alas, I have not found one.
>> Frege and PureScript both look interesting but I am unsure of Freg
>
> I have longed for a statically compiled language with type inference with
> the simplicity and consistency of Clojure's syntax that also supports
> generative testing and works on the JVM but alas, I have not found one.
> Frege and PureScript both look interesting but I am unsure of Frege's
> l
| I think you missed my point, which is only "Spec is great as we have the
power of Clojure" - sure, just don't forget you have the power of ANOther
language in that language as well.
Hum, I've probably missed your point sorry, I'm still not following.
| no, this will, or at least should, be
On Apr 6, 2017 3:47 PM, "Raoul Duke" wrote:
I am writing to ignorantly sincerely ask how spec + Orchestra compares to
other statically typed out of the box JVM languages. What are the succint
wins over not Scala shudder but eg Kotlin Ceylon, heck Frege, et. al.?
i could be wrong, but i do not v
On Apr 7, 2017 12:07 AM, "Didier" wrote:
Types are not very precise though, like it will catch 10/"123", but not
10/0, because the type isn't more precise then int.
no, this will, or at least should, be caught. 10/0 is not an int, and typed
"/' would reject 0 as an ill-typed denominator.
--
Not sure where you are getting the assertion of equivalence from, it
certainly isn't what I meant. I think you missed my point, which is only
"Spec is great as we have the power of Clojure" - sure, just don't forget
you have the power of ANOther language in that language as well.
I think comparing
@Colin Yates
If spec is a DSL to describe invariants and the static typing of other
languages are too, then it's not true that all static typing DSLs can express
what the spec DSL can.
If you say, could I build spec in other languages, or can I put asserts in the
code using the full languages,
So I see Clojure Spec as an "internal DSL if you squint" for
describing invariants that are enforced at runtime. Static typing is
also an "internal DSL if you squint" for describing
data-shape-invariants at compile time. With Clojure Spec you have the
entirety of Clojure to describe those invariant
It's different, yet related.
Static type systems and clojure.spec both try to prevent bugs. They're tools to
help you write correct programs, the same way that a testing framework is.
Neither of them will catch all your bugs unfortunately.
Static type systems catches bugs where you would try t
The power offered by spec is probably better compared against dependent
type systems like Idris. True static type systems run analysis at
compile-time, but spec allows you to perform very complex checks because
you have the power of full blown language.
For example, with spec you can write a funct
On Thu, Apr 06, 2017 at 01:47:17PM -0700, Raoul Duke wrote:
> I am writing to ignorantly sincerely ask how spec + Orchestra compares to
> other statically typed out of the box JVM languages. What are the succint
> wins over not Scala shudder but eg Kotlin Ceylon, heck Frege, et. al.?
clojure.spec
I am writing to ignorantly sincerely ask how spec + Orchestra compares to
other statically typed out of the box JVM languages. What are the succint
wins over not Scala shudder but eg Kotlin Ceylon, heck Frege, et. al.?
--
You received this message because you are subscribed to the Google
Groups "
I think that answers my question. I just wanted an approximate idea of the
kind of LTS this would have, before depending on it. I meant like if it
would keep up with the changes to spec before release. So I'm glad to hear
it will and possibly even beyond.
Thanks.
On Thursday, 6 April 2017 11:4
On Thu, Apr 06, 2017 at 11:31:46AM -0700, Didier wrote:
> Looks good. May I ask, what kind of support are we looking at? Is this
> something you reasonably see being carried to the release of 1.9? Or was it
> more of an experiment?
I'm not entirely sure what you mean by "carried to the release o
Looks good. May I ask, what kind of support are we looking at? Is this
something you reasonably see being carried to the release of 1.9? Or was it
more of an experiment?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send ema
Sounds nice! Will definitely be looking into this.
Alan
On Wed, Apr 5, 2017 at 11:21 AM, Jeaye wrote:
> Folks,
>
> tl;dr -- https://github.com/jeaye/orchestra
>
> I'd like to announce the release of Orchestra, which tackles an
> opinionated issue of clojure.spec's instrumentation not checking :r
21 matches
Mail list logo