spdegabrielle
2021-2-10 09:34:11

I thought I should start learning about type systems and I came across a term I didn’t > Certain languages, for example https://en.wikipedia.org/wiki/Clojure\|Clojure, <https://en.wikipedia.org/wiki/Common_Lisp|Common Lisp>, or https://en.wikipedia.org/wiki/Cython\|Cython are dynamically type checked by default, but allow programs to opt into static type checking by providing optional annotations. One reason to use such hints would be to optimize the performance of critical sections of a program. This is formalized by <https://en.wikipedia.org/wiki/Type_system#Gradual_typing|gradual typing>. This is formalized by <https://en.wikipedia.org/wiki/Type_system#Gradual_typing|gradual typing>. The programming environment _https://en.wikipedia.org/wiki/DrRacket\|DrRacket_, a pedagogic environment based on Lisp, and a precursor of the language https://en.wikipedia.org/wiki/Racket_(programming_language)#Development\|Racket is also soft-typed. https://en.wikipedia.org/wiki/Type_system#Combining_static_and_dynamic_type_checking

Any idea what ‘*soft-typed*’ is? - it is not defined or mentioned elsewhere in the page.


soegaard2
2021-2-10 09:43:55

It’s an older term/idea. From “Practical Soft Typing” by Andrew K. Wright.



spdegabrielle
2021-2-10 09:59:42

thanks!


evyatar2013
2021-2-10 19:10:49

Another rosette question. (require rosette/solver/smt/z3 rosette/query/debug) (define s (z3 #:options (hash ':produce-unsat-cores 'true ':smt.relevancy 2 ':smt.mbqi.max_iterations 10000000))) (define-symbolic i (bitvector 32)) (current-solver s) (define c (solve (assert (and (bveq (bv 0 32) i) (bveq (bv 1 32) i))))) (unsat? c) &gt; #t (core c) &gt; #f ==== Using the solver directly seems to work (solver-assert s (list (bveq (bv 0 32) i) (bveq (bv 1 32) i))) (solver-debug s) &gt; (core (bveq (bv #x00000000 32) i) (bveq (bv #x00000001 32) i)) I assume I’m not configuring the solver correctly to get the unsat core, but I couldnt find anything in the source/docs to help point me at the correct instantiation


sorawee
2021-2-10 19:28:06

You can’t use solve to get an unsat core


evyatar2013
2021-2-10 19:29:55

I also tried debug but it only respected the provided expr and not any of the other asserts previously made.

Is there a function I’m missing?


evyatar2013
2021-2-10 19:30:30

(assert (bveq (bv 0 32) i)) (assert (bveq (bv 1 32) i)) (debug i) code in case that’s helpful


sorawee
2021-2-10 19:30:58

I guess the question I need to ask is, what are you trying to do? Are you using Rosette for its symbolic evaluation? Or simply as an interface to an SMT solver?


sorawee
2021-2-10 19:31:17

For the latter, your second approach is the right one (just use the solver directly)


evyatar2013
2021-2-10 19:31:34

For symbolic evaluation. I just tried to distill the core problem to focus the discussion


sorawee
2021-2-10 19:34:02

Ah, OK. I think the short answer is that there’s no good way to do that, simply because the information unsat cores provided usually is not useful much (according to Emina), so we don’t really support it.


sorawee
2021-2-10 19:34:10

If you are OK with hacking Rosette internals, you can create a new solver



sorawee
2021-2-10 19:34:43

evyatar2013
2021-2-10 19:35:04

Ha! while we were having this discussion I did exactly that and I’m slowly discovering that the information unsat core is producing isnt that helpful :stuck_out_tongue:


evyatar2013
2021-2-10 19:35:35

“exactly” ~= quickly hacking it in the repl, not a robust solution


evyatar2013
2021-2-10 19:35:52

As always thank you @sorawee


sorawee
2021-2-10 19:36:01

you are welcome!


bfowke
2021-2-11 06:08:57

@bfowke has joined the channel