Re: clojure.spec - relationship between :args

[dimitris]

Hi Alex,

I think I've figured it out. Here is the complete solution I've come up 
with in case you feel like providing feedback:


(defn- extract-sensible-k-gen
  "Gen override for `::extract-args`." []
  (gen/bind (spc/gen ::persistent-coll)
#(let [r (rand)
   heads? ( >= r0.5)];; flip a coin (gen/tuple (gen/elements (cond 
(empty? %) (repeat 2 :NOT-FOUND);; nothing can be possibly found in an empty coll 
(map? %) (if heads?
(keys %);; keys that will be found (repeat 2 
:NOT-FOUND));; keys that will not be found (set? %) (if heads?
%;; elements (repeat 2 :NOT-FOUND))
 (sequential? %) (let [c (count %)]
   (if heads?;; index overrides (if ( > r0.75)
   (range c);;valid indices (concat (range -1 
(dec (- c))-1);; invalid (negative) indices (range c (+ c10
 (if ( > r0.25);; predicate overrides (repeat 2 
(constantly true))
   (repeat 2 (constantly false)
 ))
 (gen/return %)))
))


;== 
(spc/def ::persistent-coll (spc/or :map (spc/map-of any? any?)
:vector (spc/coll-of any?:kind vector?)
:set (spc/coll-of any?:kind set?)
:list (spc/coll-of any?:kind list?)))

(spc/def ::predicate (spc/fspec :args (spc/cat :x any?)
 :ret boolean?))

(spc/def ::extract-args (spc/cat :k (spc/or :predicate ::predicate 
:key-or-index any?)
   :coll ::persistent-coll))

(spc/fdef enc/extract

  :args ::extract-args :ret (spc/tuple any? coll?)

  :fn (spc/or :some-found #(let [[e c] (:ret %)
   [coll-type arg-coll] (-> %:args :coll)]
  (and (some? e)
   ( > (count arg-coll)
  (count c))
   #_(do (println "SOME-FOUND - cret=" c "argc=" arg-coll \newline (-> % 
:args :k second)) true) ))

:nil-found #(let [[e c] (:ret %)
  [coll-type arg-coll] (-> %:args :coll)]
 (and (nil? e)
  ( > (count arg-coll)
 (count c))
  #_(do (println "NIL-FOUND - cret=" c "argc=" arg-coll \newline (-> % 
:args :k second)) true) ))

:not-found #(let [[e c] (:ret %)
  [coll-type arg-coll] (-> %:args :coll)]
 (and (nil? e)
  (= arg-coll c)
  #_(do (println "NOT-FOUND - cret=" c "argc=" arg-coll \newline (-> % 
:args :k second)) true) )))

  )

 and i call it like so:

(-> (test/check `treajure.encore/extract {:gen {::extract-args 
extract-sensible-k-gen}})
test/summarize-results

I must say, i was surprised to see that my humble 8G-ram laptop can 
barely deal with the default number of generative tests (1000), but at 
least it works :).


Many thanks again, for redirecting me to Stu's video - it all made much 
more sense after digesting that.


Regards,

Dimitris


On 04/11/16 00:14, dimitris wrote:


HI Alex,

Many thanks for your response, it was very helpful. I see your point 
about customizing the generator, and in fact the video in the link 
does something sort of similar to what I am trying to. So yeah I'll 
figure it out tomorrow :). Thanks again!


Dimitris


On 03/11/16 18:53, Alex Miller wrote:



On Thursday, November 3, 2016 at 1:12:39 PM UTC-5, Jim foo.bar wrote:

Hi everyone,

I'm starting to get familiar with clojure.spec, and in my very
first spec I needed to specify relationship between the args
themselves (similar to how :fn specs allow for specifying some
relationship between :args & :ret). Is that at all possible?


:fn is the best way to do this (specifying a relationship either 
between args or between an arg and ret)


Here is my use-case for the sake of argument:

(defn extract
   "Analogous to `clojure.core/get`, but returns a vector of
`[item-at-k, coll-without-k]`. For Sequential things  can be
an integer (the index), or a predicate. In case of a predicate,
the first item that satisfies it will be extracted." [k coll]
   ...)

The implementation is quite simple but irrelevant for my question
and therefore omitted. Here are some sample invocations:

(extract :a {:a 1 :b 2}) => [1 {:b 2}]

(extract :a #{:a :b}) => [:a #{:b}]

(extract 1 [:a :b :c]) => [:b [:a :c]]

(extract (partial = b) [:a :b :c]) => [:b [:a :c]] ;; same as above

(extract 3 [:a :b :c]) => [nil [:a :b :c]] ;; nothing found

And here is my attempt at spec-ing this:

(spc/def ::predicate (spc/fspec :args (spc/cat :x any?)
  :ret boolean?))

(spc/fdef extract

   :args (spc/cat :value (spc/alt :index nat-int?
   ;:key any? FIXME::predicate ::predicate )
  

Re: [ANN] Nightlight, an embedded editor for Clojure

[Didier]

Wow, this looks awesome.

For now, I'm pretty satisfied with Atom + ProtoREPL. But if your approach 
can achieve much better code completion, much better linting, much better 
refactoring and hopefully much better debugging, I'm going to have to move 
to it.

Actually, it would be awesome if you could try to focus on Debugging, 
because that part I feel is badly served by other Clojure IDEs. It would be 
great if I could use whatever editor I wanted, and if suddenly I needed to 
debug Clojure, I could drop Nightcode as a dependency and get a full 
fledged web browser based debugger.

On Saturday, 29 October 2016 16:50:37 UTC-7, Zach Oakes wrote:
>
> Yep I definitely plan on adding that feature. For now, you'll just have to 
> refresh your browser =) By the way, I just released version 1.1.0, which 
> adds some initial support for ClojureScript! I added a new section on the 
> website that explains how to set it up.
>
> On Saturday, October 29, 2016 at 3:41:05 AM UTC-4, ru wrote:
>>
>> Great work, Zach! Thank you. I would like to switch from 
>> Lifhttable+Terminal working environment that I use now, to Nightlight. But 
>> I definitely need "Refresh folder" and/or "Refresh file" actions, because 
>> sometimes I update source files from outside of a project. Is it possible 
>> to add something like that to Nightlight? 
>>
>> Sincerely,
>>  Ru
>>
>> воскресенье, 9 октября 2016 г., 5:03:58 UTC+3 пользователь Zach Oakes 
>> написал:
>>>
>>> Just when you thought I was done with my weird obsession with making 
>>> projects that start with “night”, I went and made another. This one is 
>>> called Nightlight, and it’s a Clojure editor with a unique twist: it is 
>>> meant to run *inside* your project, giving it direct access to the state of 
>>> your program. This might end up being a great idea, or an embarrassingly 
>>> stupid one.
>>>
>>> Website: https://sekao.net/nightlight/
>>>
>>> Github: https://github.com/oakes/Nightlight
>>>
>>> I’ve only been working on this for a few weeks. To explain the idea, 
>>> I’ll channel Uncle Bob and give it to you in the form of a socratic dialog 
>>> between myself (Z1) and myself from two weeks ago (Z2):
>>>
>>> Z2: Nightcode has a lot of crippling limitations. It has no code 
>>> completion, for starters. Its instaREPL is a toy, because it only works 
>>> with clojure core. Forget about refactoring support.
>>>
>>> Z1: It’s almost as if these are caused by the same core issue.
>>>
>>> Z2: Yeah almost. Anyway where was I...
>>>
>>> Z1: No, they actually are. Traditional editors and IDEs have the same 
>>> basic design -- they are standalone programs, so they have to use all sorts 
>>> of complicated maneuvers to understand your project. It’s a huge source of 
>>> complexity.
>>>
>>> Z2: What’s the alternative?
>>>
>>> Z1: Imagine completely reversing the relationship. Instead of an 
>>> external tool enveloping and running your program, what if your program ran 
>>> your development tool? What if they lived in the same process? Your editor 
>>> would have direct access to the state of your program, opening the doors to 
>>> all sorts of interactivity.
>>>
>>> Z2: So what’s the alternative?
>>>
>>> Z1: Are you serious? I just explained it.
>>>
>>> Z2: Right. Genius! Nobody has thought of this before.
>>>
>>> Z1: Plenty of people have, but for the most part those tools are not 
>>> mainstream. Various Lisp and Smalltalk tools blurred those lines. For 
>>> example, DrRacket can run your code in the same Racket instance that it is 
>>> running in.
>>>
>>> Z2: Doesn’t this mean if you crash your program, you crash your editor?
>>>
>>> Z1: Yeah...don’t do that.
>>>
>>> Z2: Got it. How do we build it? Should we just shoehorn Nightcode into 
>>> some kind of build task, so it pops up every time you start developing a 
>>> project?
>>>
>>> Z1: That would be pretty obnoxious, which I realize makes the idea more 
>>> appealing to you. But consider this: if it was a totally browser-based 
>>> editor, we could just run a little web server inside your project and the 
>>> user could interact with it via a browser.
>>>
>>> Z2: That sounds like a lot of work.
>>>
>>> Z1: Not really. Nightcode’s editor is already browser-based, so we just 
>>> need to make the rest of the interface. It should only take about a month, 
>>> or even less if a large hurricane happens to slam your city in the near 
>>> future, giving you nothing else to do but code and drink beer.
>>>
>>> Z2: Hah yeah that’s not going to happen.
>>>
>>

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

Re: Java like static typing for Clojure?

[Didier]

Spectrum (https://github.com/arohner/spectrum) seems quite interesting. I 
haven't tried spec yet, but form quick glance, it looks just as annoying as 
typed clojure to use.

I think I'm imagining something simpler though. Say a system that just used 
already existing Clojure type hints, and performed compile time checks 
about to whatever level is possible given the provided annotation.

So say I did:

(def ^int something "test")

This would fail at compile time.

Similarly:

(def ^String something "test")
(inc something)

It would fail at compile time.

Or:

(defn inc2 [^Long a]
  (inc (inc a)))
(inc2 1.80)

Would also fail.

And hopefully this:

(defn ^Long inc2 [^Long a]
  (inc (inc a)))
(def temp ["test", 2.48])
(map inc2 temp)

Would also fail. Because the type checker would infer that the vector has 
String or Double as type, and inc2 expects none of these.

Or:

(conj ["a", "b"] "c")

would still work.

(conj ^Vec ["a", "b"] 10)

would fail.

Now I don't know, maybe this is too simple, not really useful, or maybe its 
non trivial to implement. But I feel just small type checks like that could 
be useful, and they wouldn't be too burdening.

On Saturday, 15 October 2016 15:14:08 UTC-7, Didier wrote:
>
> I know a lot of people like to say how unhelpful Java like static typing 
> is, and only more powerful type systems of the ML family add value, but 
> I've been wondering recently if for Clojure it wouldn't make more sense to 
> simply extend the type hints to enable an optional Java like static typing 
> schemI the.
>
> It is my understanding that ML style static typing is incredibly difficult 
> to add properly and without compromise to a dynamic language. That doing so 
> limits the scope of type inference, rendering the task of adding type info 
> more tedious then in ML languages themselves.
>
> ML style static typing provide enhanced safety grantees, but seem to add 
> too much complexity to Clojure to be practical. What about a Java like 
> static typing scheme though?
>
> I haven't found in practice that the safety of Clojure was an issue, as 
> the REPL workflow tend to promote quite a lot of testing. So I'm not too 
> worried about needing the state of the art of provable correctness for my 
> programs. What has been a biggest cause of issue to me was refactoring and 
> shared code base across a team. Those last two use cases are actually 
> pretty well handled by Java like static type checking. Is it a powerful 
> type checker, not really, but it enables most trivial type errors to be 
> caught early, and it allows easier integration points for other devs to 
> follow, as well as documentation for functions, better tools support and 
> easier refactoring, while also enabling performance optimizations.
>
> I have limited knowledge in typing systems, and have no idea how easy it 
> is to implement them, but as a user of Clojure, I feel like I would find an 
> optional Java like static typing a great addition, one that I am more 
> willing to use and benefit from then Typed Clojure's more complex ML style 
> type checking.
>
> What do other think?
> Can anyone with better knowledge tell me if this would be feasible or if 
> adding such gradual typing system is effectively as hard as adding ML style 
> type checking?
>

-- 
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: Addressing Matthias Felleisen's concerns?

[Didier]

Cool, I'm looking forward to it. Seems like that would greatly enhance 
TypedClojure's usefulness.

On Monday, 9 May 2016 15:44:46 UTC-7, Ambrose Bonnaire-Sergeant wrote:
>
> Josh is correct. I'm currently working on merging this work now that my 
> courses are over.
>
> Thanks,
> Ambrose
>
> On Mon, May 9, 2016 at 6:32 PM, Josh Tilles  > wrote:
>
>> On Monday, May 9, 2016 at 5:36:53 PM UTC-4, Didier wrote:
>>>
>>> At Clojurewest 2016, Matthias Felleisen gave a great keynote about the 
>>> pragmatism of soundness for maintening large code bases. He mentioned that 
>>> adding type gradually was useful, but only when the border between typed 
>>> land and untyped land is guarded. He mentioned how Racket does that. He 
>>> also talked about the cost of doing so, which seem to remain an open 
>>> question.
>>>
>>> I'm wondering if any of this has been taken up by somebody in Clojure to 
>>> try to do the same? My understanding is typed clojure does not protect the 
>>> border between typed and untyped. Therefore, you do not have the guarantee 
>>> that your typed code will be correct for all its usage.
>>>
>> I believe that Ambrose (the core developer/maintainer of Typed Clojure) 
>> has been focusing on that very topic as of late: CTYP-309: “Export typed 
>> vars with contracts to untyped namespaces” 
>> .
>>
>>> Also, does anyone know exactly what he meant by the cost? Is doing 
>>> gradual typing causing slower runtimes, slower compilation, does it hamper 
>>> the dynamism, etc.
>>>
>>  I expect that dynamically-checked contracts would (at least) cause 
>> slower runtimes in the cases of untyped-calling-typed code or 
>> typed-calling-untyped code; I think typed-calling-typed code would skip the 
>> runtime contract verification.
>>
>> -- 
>> 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.

[ANN] Quil 2.5.0 Release

[Nikita Beloglazov]

Happy to announce Quil 2.5.0 release.
Quil is a Clojure/ClojureScript library for creating interactive drawings
and animations.

The release available on clojars: https://clojars.org/quil. List of changes:

   - Support svg rendering. #188 .
   - Add do-record  macro to
   simplify svg/pdf generation. #189
   .
   - Update Processing to 3.2.2 and Processing.js to 1.6.3.
   - Fix mouse-wheel event propagation outside of sketch. #175
   
   - Fix reflection warnings. #185 

Since 2.5.0 Quil works only on Java 8+ because Processing 3.2.2 doesn't
support Java 7 and below.

Documentation on http://quil.info has been updated as well.

Happy hacking!
Nikita

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