Re: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

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

Another thing is that dependent types (the Liquid Haskell kind), would also 
catch potential false positive.

I'll mention Spectrum for clojure.spec again, because it is essentially a 
dependently typed static type checker for Clojure. It suffers from not 
everything being specced in Clojure, but you'll find it can still catch quite a 
lot, including the division by zero error I've described. It is still in early 
stages, and doesn't work with all Clojure code bases, but I'd keep an eye open 
for it.

Reference: 
http://goto.ucsd.edu/~ucsdpl-blog/liquidtypes/2015/09/19/liquid-types/

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

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 dynamically calculated, you 
won't catch this statically even if you have a non zero type.

I don't know enough about dependent types, I think they could catch this, 
maybe, I'm unsure. I do know that none of the asked languages have them. I've 
also heard from more knowledgeable people that they're still very verbose and 
unpractical. 

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Gregg Reynolds]

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 missed your point sorry, I'm still not following.

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

In most static type systems this will not be caught, because they don't
have a fraction type.


"most" -ok.  that's empirical, eww!

So this is actually a function that takes two number types, and 0 is a
number too, so it will type check, but throw an exception at runtime.


maybe my mind has been twisted by dependent types. imho a definition of
"div" that accepts 0 as denominator is a bad defn, or at least a non-typed
defn.  "10/0" is ill-typed. this is obvious mathematically, right? division
by zero is undefined.  it's not really a question of "fraction types"; just
rewrite as (div 10 0).  you do not need a fraction type to define "/". what
you need is a type that does not include zero.


i would add that if you want real static typing you're almost forced to
support dependent types. unless you want a defn of static typing that
includes a great big "well, except for..  " clause.  like a fn that is only
defined for 0..9.


g

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Gregg Reynolds]

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.

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

In most static type systems this will not be caught, because they don't
have a fraction type.


"most" -ok.  that's empirical, eww!

So this is actually a function that takes two number types, and 0 is a
number too, so it will type check, but throw an exception at runtime.


maybe my mind has been twisted by dependent types. imho a definition of
"div" that accepts 0 as denominator is a bad defn, or at least a non-typed
defn.  "10/0" is ill-typed. this is obvious mathematically, right? division
by zero is undefined.  it's not really a question of "fraction types"; just
rewrite as (div 10 0).  you do not need a fraction type to define "/". what
you need is a type that does not include zero.

g

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Colin Yates]

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 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
>>> longevity and PureScript's performance on the JVM's Javascript
>>> environment.
>>
>>
>> Note that both of those options both suffer from very difficult interop -
>> PureScript will probably not have any at all since it will be expecting to
>> interop with JS, and Frege has some but it's clunky due to the type system
>> mismatch.
>>
>> Personally I long for a Kotlin/Clojure hybrid, to the point that I have
>> seriously considered trying to build one.
>>
>
> ShenLanguage  is maybe the closest thing from a
> fully typed Clojure on the JVM, though it also suffers from poor interop.
>
> I'd like to suggest Fantom . I wish more people used
> it. It is a functional/oop, actor concurrent, inference typed, static with
> optional dynamic typing language with good interop that runs on top of the
> JVM, CLR and JavaScript. It has a lot of similarities with Clojure, like a
> strong support for data literals such as for maps and lists, looping is
> mostly done through higher order functions, it has a subset of its own
> language as a data declaration format, immutable by default, strong
> concurrency support using actors model, etc. It just needs some love. I
> find at its core, its got a better offering than Kotlin.
>
> On Friday, 7 April 2017 20:34:34 UTC-7, Colin Fleming wrote:
>>
>> 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
>>> longevity and PureScript's performance on the JVM's Javascript
>>> environment.
>>
>>
>> Note that both of those options both suffer from very difficult interop -
>> PureScript will probably not have any at all since it will be expecting to
>> interop with JS, and Frege has some but it's clunky due to the type system
>> mismatch.
>>
>> Personally I long for a Kotlin/Clojure hybrid, to the point that I have
>> seriously considered trying to build one.
>>
>> On 8 April 2017 at 14:57, 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.
>>>
>>>  | 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.
>>>
>>> In most static type systems this will not be caught, because they don't
>>> have a fraction type. So this is actually a function that takes two number
>>> types, and 0 is a number too, so it will type check, but throw an exception
>>> at runtime.
>>>
>>> --
>>> 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.
>>>
>>
>> --
> 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 

Re: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

>
> 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 
>> longevity and PureScript's performance on the JVM's Javascript 
>> environment.
>
>
> Note that both of those options both suffer from very difficult interop - 
> PureScript will probably not have any at all since it will be expecting to 
> interop with JS, and Frege has some but it's clunky due to the type system 
> mismatch.
>
> Personally I long for a Kotlin/Clojure hybrid, to the point that I have 
> seriously considered trying to build one.
>

ShenLanguage  is maybe the closest thing from a 
fully typed Clojure on the JVM, though it also suffers from poor interop.

I'd like to suggest Fantom . I wish more people used 
it. It is a functional/oop, actor concurrent, inference typed, static with 
optional dynamic typing language with good interop that runs on top of the 
JVM, CLR and JavaScript. It has a lot of similarities with Clojure, like a 
strong support for data literals such as for maps and lists, looping is 
mostly done through higher order functions, it has a subset of its own 
language as a data declaration format, immutable by default, strong 
concurrency support using actors model, etc. It just needs some love. I 
find at its core, its got a better offering than Kotlin.

On Friday, 7 April 2017 20:34:34 UTC-7, Colin Fleming wrote:
>
> 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 
>> longevity and PureScript's performance on the JVM's Javascript 
>> environment.
>
>
> Note that both of those options both suffer from very difficult interop - 
> PureScript will probably not have any at all since it will be expecting to 
> interop with JS, and Frege has some but it's clunky due to the type system 
> mismatch.
>
> Personally I long for a Kotlin/Clojure hybrid, to the point that I have 
> seriously considered trying to build one.
>
> On 8 April 2017 at 14:57, 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.
>>
>>  | 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.
>>
>> In most static type systems this will not be caught, because they don't 
>> have a fraction type. So this is actually a function that takes two number 
>> types, and 0 is a number too, so it will type check, but throw an exception 
>> at runtime.
>>
>> --
>> 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.
>>
>
>

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Colin Fleming]

>
> 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
> longevity and PureScript's performance on the JVM's Javascript
> environment.


Note that both of those options both suffer from very difficult interop -
PureScript will probably not have any at all since it will be expecting to
interop with JS, and Frege has some but it's clunky due to the type system
mismatch.

Personally I long for a Kotlin/Clojure hybrid, to the point that I have
seriously considered trying to build one.

On 8 April 2017 at 14:57, 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.
>
>  | 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.
>
> In most static type systems this will not be caught, because they don't
> have a fraction type. So this is actually a function that takes two number
> types, and 0 is a number too, so it will type check, but throw an exception
> at runtime.
>
> --
> 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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

 | 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 caught. 10/0 is not an int, and typed 
"/' would reject 0 as an ill-typed denominator.

In most static type systems this will not be caught, because they don't have a 
fraction type. So this is actually a function that takes two number types, and 
0 is a number too, so it will type check, but throw an exception at runtime. 

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Gregg Reynolds]

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 view spec as a type system.  more like the
dual of a type system. clojure does not do types, strictly speaking.  there
are lots of reasons to like it, but "it types" is not one of them.  spec
does not change this.

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Gregg Reynolds]

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.

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Colin Yates]

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 Clojure Spec against _only_ a static typing machine to be
disingenuous, that's all.

Love, peace and goodwill to all :-).

On Friday, 7 April 2017, Didier  wrote:

> @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, ya off course you can, but not without
> considerable effort. Similarly, you can add static typing to Clojure, but
> that also comes with considerable effort.
>
> That's why people skip over this. Can I embed a haskell inside Clojure? I
> could. I could embed a Clojure inside Haskell too. But those are not a
> given feature provided to me for free as standard.
>
> So the discussion should center around what features I get for free. With
> spec, you get a very powerful description DSL, more powerful than most
> static typing ones. You get generative testing, parsing, validation,
> asserts and documentation. With static typing systems, you get a often less
> powerful description DSL, compile time type assertions, and documentation.
>
> --
> 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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

@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, ya off course you can, but not without 
considerable effort. Similarly, you can add static typing to Clojure, but that 
also comes with considerable effort.

That's why people skip over this. Can I embed a haskell inside Clojure? I 
could. I could embed a Clojure inside Haskell too. But those are not a given 
feature provided to me for free as standard. 

So the discussion should center around what features I get for free. With spec, 
you get a very powerful description DSL, more powerful than most static typing 
ones. You get generative testing, parsing, validation, asserts and 
documentation. With static typing systems, you get a often less powerful 
description DSL, compile time type assertions, and documentation. 

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Colin Yates]

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 invariants, with a static typing
lib you are limited to whatever constructs language provides. So
Clojure Spec is much more open and extensible in that regard.


However, I see a lot of people stopping the discussion there without
accounting for the fact that you _also_ have the "entirety of
language-X to describe those invariants" for any given language. Pre
and Post conditions have been around since the dawn of time and most
languages (I know about) have asserts. If the language has support for
AOP then even better as the description and application of those
invariants don't need to be embedded in the code in question. This
means that any given language, purely from a "can it enforce this?" is
at least as powerful as Clojure Spec.

And Clojure Spec's ability to feed the generative testing machine is
awesome if you can describe your accepted inputs in that way.

So, in terms of "can I express this invariant" in both static and
statically typed languages? Yep, of course.


Clojure Spec and static type systems are both tools for enforcing
invariants. Can Clojure Spec describe invariants that
StaticTypingLanguage-X can't? No, of course not. Is the machinery
around Clojure Spec useful - absolutely.

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 longevity and PureScript's performance on the JVM's
Javascript environment.

On 7 April 2017 at 06:07, Didier  wrote:
> 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 to do an operation over 
> a type which does not support it. 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. So int/int will be ok, but int/string will be caught at compile time as 
> a bug.
>
> The advantage of static type systems is that what they do catch, they will 
> catch 100% of the time and they generally run pretty quickly.
>
> Clojure.spec catches bugs where you'll try to do something on a value which 
> isn't acceptable, as well as catch bugs where the relationship between the 
> input and output values is wrong. So it can catch 10/0 and 10/"123". If a 
> parameter was true and functionally that means the output should be false, 
> but a bug causes it to be true instead, well it can also catch that.
>
> The disadvantage of clojure.spec is that you cannot be sure it caught 100% of 
> those bugs. It will catch some, but maybe not all. It will also be much 
> slower to run.
>
> Now, clojure.spec has one more trick up its sleeves. It can be used for 
> static analyses on steroids. If you've ever used Find bugs in java, you know 
> a little what I'm talking about. If you use Spectrum, it will try to catch 
> some of those same bugs at compile time, and it could in theory be made to 
> catch 100% of the bugs static type systems catch. Spectrum is new and not 
> fully featured yet, but so is clojure.spec, so this is a possible future 
> which you can have a taste for today. I recommend checking it out: 
> https://github.com/arohner/spectrum
>
> Alright, that's the part about catching bugs. Now there's more to it. Type 
> declarations are normally helpful documentation too, and so is clojure.spec. 
> Spec, once again, can be way more precise in documenting. Similarly, types 
> can help tooling and error messages, so can spec.
>
> Finally, spec also allows some things types don't even cover, such as parsing 
> and validation of non typed data like json. Spec can parse a complex 
> structure into an AST. It can also validate EDN, or json that was 
> unmarshalled into clojure.
>
> As time goes on, I'm sure someone will find other use cases for it too.
>
> Hope this helps.
>
> P.S.: Clojure also has a static type system called core.typed. It is not as 
> widely used though, and has only one developer working on it. It also doesn't 
> compare to the languages you listed, since it is a gradual type system, more 
> inline with typescript, typed racket and hack.
>
> --
> 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 

Re: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Didier]

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 to do an operation over a 
type which does not support it. 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. So 
int/int will be ok, but int/string will be caught at compile time as a bug.

The advantage of static type systems is that what they do catch, they will 
catch 100% of the time and they generally run pretty quickly.

Clojure.spec catches bugs where you'll try to do something on a value which 
isn't acceptable, as well as catch bugs where the relationship between the 
input and output values is wrong. So it can catch 10/0 and 10/"123". If a 
parameter was true and functionally that means the output should be false, but 
a bug causes it to be true instead, well it can also catch that.

The disadvantage of clojure.spec is that you cannot be sure it caught 100% of 
those bugs. It will catch some, but maybe not all. It will also be much slower 
to run.

Now, clojure.spec has one more trick up its sleeves. It can be used for static 
analyses on steroids. If you've ever used Find bugs in java, you know a little 
what I'm talking about. If you use Spectrum, it will try to catch some of those 
same bugs at compile time, and it could in theory be made to catch 100% of the 
bugs static type systems catch. Spectrum is new and not fully featured yet, but 
so is clojure.spec, so this is a possible future which you can have a taste for 
today. I recommend checking it out: https://github.com/arohner/spectrum

Alright, that's the part about catching bugs. Now there's more to it. Type 
declarations are normally helpful documentation too, and so is clojure.spec. 
Spec, once again, can be way more precise in documenting. Similarly, types can 
help tooling and error messages, so can spec.

Finally, spec also allows some things types don't even cover, such as parsing 
and validation of non typed data like json. Spec can parse a complex structure 
into an AST. It can also validate EDN, or json that was unmarshalled into 
clojure.

As time goes on, I'm sure someone will find other use cases for it too.

Hope this helps.

P.S.: Clojure also has a static type system called core.typed. It is not as 
widely used though, and has only one developer working on it. It also doesn't 
compare to the languages you listed, since it is a gradual type system, more 
inline with typescript, typed racket and hack.

-- 
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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Timothy Baldridge]

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 function spec that says "Union is a
function that takes two hashsets. The return value of this function is a
hashset that contains all the values found in the hashset arguments".
That's impossible to statically check in most languages. Some languages
like Idris approach this level of expressibility, but when they fall short,
you're sunk. In spec you can always pop the escape hatch and write a custom
predicate in Clojure code.

So for me that's the tradeoff. I loose compile-time checking, but gain a
*ton* of power. And since types exist at run-time we can do cool things
like introspect them and generate data, documentation, better error
messages, or even run logic over them to write a static type checker.

On Thu, Apr 6, 2017 at 2:57 PM, Jeaye  wrote:

> 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 validates data at run-time. spec's instrumentation, and thus
> Orchestra's, checks function arguments, return values, etc _when the
> function is called_, not during AOT compilation.
>
> In contrast, a static type system would catch theses errors before the
> program itself even runs. In my opinion, clojure.spec + Orchestra still
> falls quite short of a static type system, but it's the best setup I've
> seen for automated data validation as it moves through all parts of your
> Clojure programs. Even in languages with static type systems (C++, even),
> you almost certainly won't get automatic validation of the data, for each
> function call, return, etc, given only a declarative spec. In that way,
> clojure.spec alone provides something of great value.
>
> Aside from that, you're talking about the gains of Clojure versus all of
> those languages you listed. That's not related to Orchestra and would
> likely be better answered by people more knowledgeable than me.
>
> --
> 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: was Re: ANN: Orchestra, complete instrumentation for clojure.spec

[Jeaye]

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 validates data at run-time. spec's instrumentation, and thus 
Orchestra's, checks function arguments, return values, etc _when the function 
is called_, not during AOT compilation.

In contrast, a static type system would catch theses errors before the program 
itself even runs. In my opinion, clojure.spec + Orchestra still falls quite 
short of a static type system, but it's the best setup I've seen for automated 
data validation as it moves through all parts of your Clojure programs. Even in 
languages with static type systems (C++, even), you almost certainly won't get 
automatic validation of the data, for each function call, return, etc, given 
only a declarative spec. In that way, clojure.spec alone provides something of 
great value.

Aside from that, you're talking about the gains of Clojure versus all of those 
languages you listed. That's not related to Orchestra and would likely be 
better answered by people more knowledgeable than me.

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


signature.asc
Description: PGP signature