Consider the following inductive definition describing the small step semantics of the language of guarded commands:
inductive small_step :: "com × state ⇒ com × state ⇒ bool" (infix "→" 55)
where
Assign: "(x ::= a, s) → (SKIP, s(x := aval a s))" |
Seq1: "(SKIP;;c2,s) → (c2,s)" |
Seq2: "(c1,s) → (c1',s') ⟹ (c1;;c2,s) → (c1';;c2,s')" |
IfBlock: "(b,c) ∈ set gcs ⟹ bval b s ⟹ (IF gcs FI,s) → (c,s)" |
DoTrue: "(b,c) ∈ set gcs ⟹ bval b s ⟹ (DO gcs OD,s) → (c;;DO gcs OD,s)" |
DoFalse: "(∀ b c. (b,c) ∈ set gcs ⟶ ¬ bval b s) ⟹ (DO gcs OD,s) → (SKIP,s)"
I want to prove:
lemma "((c1 ;; c2) ;; c3) ~ (c1 ;; (c2 ;; c3))"
where:
definition equiv_c :: "com ⇒ com ⇒ bool" (infix "~" 50) where
"c ~ c' ≡ ∀ s c0 s0. (c,s) → (c0,s0) = (c',s) → (c0,s0)"
And it is getting surprinsingly difficult to do so. The closest solution I have found is given in "An operational semantics for the Guarded Command Language" by Johan J. Lukkien. However, in that article programs are modelled as sequences of states whereas here I'm modelling them as command configurations, plus states. Perhaps, there is a relation between the two but my tries so far have been frustrated.
Do you see a way to prove this lemma in Isabelle?
The desired lemma as stated does not hold. So you will not be able to prove this. I can see two main problems:
The → denotes one step of the execution, but equivalence should talk about the whole behaviour, not just one step. After one step, it is likely that the resulting programs are still different.
The semantics can get stuck for some programs, e.g., IF [] FI. Such stuck states make it hard to state equivalence if you want to say something about the remaining program c0. For example, take c1 = SKIP;; IF [] FI in your lemma and c2 = c3 = SKIP. Then no partially evaluated command reachable from (c1 ;; c2) ;; c3 is identical to one reachable from c1 ;; (c2 ;; c3).
I recommend that you first figure out what the behaviour of a program is supposed to be. For a while language, this is typically the set of reachable final states and possibly non-termination. Then, you have to decide what kind of equivalence you are interested in. Typically, one looks at trace equivalence or at bisimulation, which are not the same for non-deterministic programs. And the equivalence notion will determine how to prove such a lemma.
Related
Going at the root of Agda standard library, and issuing the following command:
grep -r "module _" . | wc -l
Yields the following result:
843
Whenever I encounter such anonymous modules (I assume that's what they are called), I quite cannot figure out what their purpose is, despite of their apparent ubiquity, nor how to use them because, by definition, I can't access their content using their name, although I assume this should be possible, otherwise their would be no point in even allowing them to be defined.
The wiki page:
https://agda.readthedocs.io/en/v2.6.1/language/module-system.html#anonymous-modules
has a section called "anonymous modules" which is in fact empty.
Could somebody explain what the purpose of anonymous modules is ?
If possible, any example to emphasize the relevance of the definition of such modules, as well as how to use their content would be very much appreciated.
Here are the possible ideas I've come up with, but none of them seems completely satisfying:
They are a way to regroup thematically identical definitions inside an Agda file.
Their name is somehow infered by Agda when using the functions they provide.
Their content is only meant to be visible / used inside their englobing module (a bit like a private block).
Anonymous modules can be used to simplify a group of definitions which share some arguments. Example:
open import Data.Empty
open import Data.Nat
<⇒¬≥ : ∀ {n m} → n < m → n ≥ m → ⊥
<⇒¬≥ = {!!}
<⇒> : ∀ {n m} → n < m → m > n
<⇒> = {!!}
module _ {n m} (p : n < m) where
<⇒¬≥′ : n ≥ m → ⊥
<⇒¬≥′ = {!!}
<⇒>′ : m > n
<⇒>′ = {!!}
Afaik this is the only use of anonymous modules. When the module _ scope is closed, you can't refer to the module anymore, but you can refer to its definitions as if they hadn't been defined in a module at all (but with extra arguments instead).
In python objects, overriding the methods __repr__ and __str__ of an object allows one to provide "unambiguous" and "human-readable" representations of the object, respectively. How does one achieve similar behavior in Racket?
I came across the printable<%> interface here, which seems like it should be usable for this purpose, but I haven't been able to get it to work quite as I expect it to. Building on the standard "fish" example from the docs:
(define fish%
(class* object% (printable<%>)
(init size) ; initialization argument
(super-new) ; superclass initialization
;; Field
(define current-size size)
;; Public methods
(define/public (get-size)
current-size)
(define/public (grow amt)
(set! current-size (+ amt current-size)))
(define/public (eat other-fish)
(grow (send other-fish get-size)))
;; implement printable interface
(define/public (custom-print port quoting-depth)
(print "Print called!"))
(define/public (custom-write port)
(print "Write called!"))
(define/public (custom-display port)
(print "Display called!"))))
This is the output I get:
> (define f (new fish% [size 10]))
> f
"Display called!""Display called!""Print called!"
> (print f)
"Write called!""Print called!"
> (display f)
"Display called!""Display called!"
> (write f)
"Write called!""Write called!"
>
So the question is threefold:
Why does it behave this way, i.e. with the multiple methods being invoked on an apparently singular rendering of the object?
What should the methods custom-print, custom-write, and custom-display evaluate to? Should they simply return a string, or should they actually entail the side effect of printing, writing, or displaying, as the case may be? E.g. should the custom-write method invoke the write function internally?
Is this the right construct to use for this purpose at all? If not, is there one / what is it?
As for
Why does it behave this way, i.e. with the multiple methods being invoked on an apparently singular rendering of the object?
You have accidently used print in write, so writing the value, will first print the value.
(define/public (custom-write port)
(print "Write called!"))
A similar problem is present in display.
Also remember to print/write/display to the proper port.
Try
#lang racket
(define fish%
(class* object% (printable<%>)
(init size) ; initialization argument
(super-new) ; superclass initialization
;; Field
(define current-size size)
;; Public methods
(define/public (get-size)
current-size)
(define/public (grow amt)
(set! current-size (+ amt current-size)))
(define/public (eat other-fish)
(grow (send other-fish get-size)))
;; implement printable interface
(define/public (custom-print port quoting-depth)
(print (~a "Print " current-size "\n") port))
(define/public (custom-write port)
(write (~a "Write " current-size "\n") port))
(define/public (custom-display port)
(display (~a "Display " current-size "\n") port))))
In the repl you will see:
> (define f (new fish% [size 10]))
> f
"Print 10\n"
> (display f)
Display 10
> (write f)
"Write 10\n"
Another answer has already helped you find the problem in your code—you need to use the port given as an argument, not the implicit (current-output-port)—but the explanation isn't quite right. To tackle your questions in reverse order:
Is this the right construct to use for this purpose at all? If not, is there one / what is it?
Yes, printable<%> is the right construct to use to customize printing of a class-based object. More generally, a struct type that is not a class can customize printing for instance through the gen:custom-write generic interface or the low-level prop:custom-write struct type property, which is used to implement printable<%>.
What should the methods custom-print, custom-write, and custom-display evaluate to? Should they simply return a string, or should they actually entail the side effect of printing, writing, or displaying, as the case may be? E.g. should the custom-write method invoke the write function internally?
The methods should actually do the side-effect of performing IO on the port they are given as an argument. They should use the corresponding function (e.g. write for custom-write, print for custom-print) internally for recursively printing/writing/displaying values in fields. On the other hand, when directly emitting particular characters, they should generally use functions like write-char, write-string, or printf. The docs for gen:custom-write give an example of a tuple datatype that prints as <1, 2, "a">: it uses write-string for the angle-brackets and commas, but recursive print/write/display for the elements of the tuple.
Why does it behave this way, i.e. with the multiple methods being invoked on an apparently singular rendering of the object?
This is the most involved part of your question. Printing in Racket is customizable through several hooks: for a few examples, see current-print, port-write-handler, global-port-print-handler, and make-tentative-pretty-print-output-port. Many of these customization hooks use intermediate ports in the process of producing output.
One thing that is not a part of the explanation is the fact that you used print in your implementation, particularly as print is bound to the normal Racket function by lexical scope, not to a method of your object.
As an illustration, consider the following adaptation of your example, which reports to the (current-output-port) the identity of the port given as an argument to the method:
#lang racket
(define report
(let ([next-id 0]
[id-cache (make-hash)])
(λ (op port)
(printf "~a ~a ~v\n"
op
(hash-ref id-cache
port
(λ ()
(define id next-id)
(hash-set! id-cache port id)
(set! next-id (add1 next-id))
id))
port))))
(define fish%
(class* object% (printable<%>)
(super-new)
;; implement printable interface
(define/public (custom-print port quoting-depth)
(report "custom-print " port))
(define/public (custom-write port)
(report "custom-write " port))
(define/public (custom-display port)
(report "custom-display" port))))
(define f (new fish%))
f
(print f)
(newline)
(display f)
(newline)
(write f)
In DrRacket, this generates the output:
custom-display 0 #<output-port:null>
custom-display 1 #<output-port:null>
custom-print 2 #<printing-port>
custom-display 3 #<output-port:null>
custom-display 4 #<output-port:null>
custom-print 5 #<printing-port>
custom-display 6 #<output-port:null>
custom-display 7 #<printing-port>
custom-display 8 #<output-port:null>
custom-write 9 #<printing-port>
while at the command line, the output is:
$ racket demo.rkt
custom-write 0 #<output-port:null>
custom-print 1 #<output-port:redirect>
custom-write 2 #<output-port:null>
custom-print 3 #<output-port:redirect>
custom-display 4 #<output-port:null>
custom-display 5 #<output-port:redirect>
custom-write 6 #<output-port:null>
custom-write 7 #<output-port:redirect>
Basically, I need to write a what the title says, the only relationship I have been able to think of is if I take some number of elements from a list with TAKE and then take the not-as-important other half with CDR and then APPEND the two that I took to prove that it's the same as the original list.
(After long painful hours of building it), the proof seems to be fine (It compiles just fine), but for some reason it fails when run.
I am using Proofpad with Dracula, in case you need the information.
Here is the code:
(include-book "doublecheck" :dir :teachpacks)
(defproperty take-append-relationship-test ;not sure why this fails.
(xs :value (random-integer-list))
(iff (consp xs)
(let* ((x1 (take 1 xs))
(xs2 (cdr xs)))
(equal (append x1 xs2)
xs))))
Here is the error log I get.
By the simple :definition TAKE we reduce the conjecture to
Goal'
(COND ((CONSP XS)
(LET ((X1 (FIRST-N-AC 1 XS NIL)))
(EQUAL (APPEND X1 (CDR XS)) XS)))
((LET ((X1 (FIRST-N-AC 1 XS NIL)))
(EQUAL (APPEND X1 (CDR XS)) XS))
NIL)
(T T)).
This simplifies, using the :definition FIRST-N-AC, the :executable-
counterparts of BINARY-+, BINARY-APPEND, CONS, FIRST-N-AC and ZP, primitive
type reasoning and the :rewrite rules DEFAULT-CAR and DEFAULT-CDR,
to
Goal''
(IMPLIES (CONSP XS)
(EQUAL (APPEND (FIRST-N-AC 1 XS NIL) (CDR XS))
XS)).
The destructor terms (CAR XS) and (CDR XS) can be eliminated by using
CAR-CDR-ELIM to replace XS by (CONS XS1 XS2), (CAR XS) by XS1 and (CDR XS)
by XS2. This produces the following goal.
Goal'''
(IMPLIES (CONSP (CONS XS1 XS2))
(EQUAL (APPEND (FIRST-N-AC 1 (CONS XS1 XS2) NIL)
XS2)
(CONS XS1 XS2))).
This simplifies, using primitive type reasoning, to
Goal'4'
(EQUAL (APPEND (FIRST-N-AC 1 (CONS XS1 XS2) NIL)
XS2)
(CONS XS1 XS2)).
Normally we would attempt to prove Goal'4' by induction. However,
we prefer in this instance to focus on the original input conjecture
rather than this simplified special case. We therefore abandon our
previous work on this conjecture and reassign the name *1 to the original
conjecture. (See :DOC otf-flg.)
No induction schemes are suggested by *1. Consequently, the proof
attempt has failed.
Summary
Form: ( DEFTHM TAKE-APPEND-RELATIONSHIP-TEST ...)
Rules: ((:DEFINITION FIRST-N-AC)
(:DEFINITION IFF)
(:DEFINITION TAKE)
(:ELIM CAR-CDR-ELIM)
(:EXECUTABLE-COUNTERPART BINARY-+)
(:EXECUTABLE-COUNTERPART BINARY-APPEND)
(:EXECUTABLE-COUNTERPART CONS)
(:EXECUTABLE-COUNTERPART FIRST-N-AC)
(:EXECUTABLE-COUNTERPART ZP)
(:FAKE-RUNE-FOR-TYPE-SET NIL)
(:REWRITE DEFAULT-CAR)
(:REWRITE DEFAULT-CDR))
Time: 0.00 seconds (prove: 0.00, print: 0.00, other: 0.00)
Prover steps counted: 328
---
The key checkpoint goal, below, may help you to debug this failure.
See :DOC failure and see :DOC set-checkpoint-summary-limit.
---
*** Key checkpoint before reverting to proof by induction: ***
Goal''
(IMPLIES (CONSP XS)
(EQUAL (APPEND (FIRST-N-AC 1 XS NIL) (CDR XS))
XS))
ACL2 Error in ( DEFTHM TAKE-APPEND-RELATIONSHIP-TEST ...): See :DOC
failure.
******** FAILED ********
Could someone at least point me in the right direction?
I have read the error log and what I get is that there is some sort of redundancy.
I am not sure how to fix this at all.
If I do that (so like '(1 2 3 4) instead of (random-integer-list)), it throws an error:
ACL2 Error in TOP-LEVEL: One value, '(1 2 3 4 5), is being returned
where 2 values were expected. Note: This error occurred in the context
(MV-LET (XS STATE)
'(1 2 3 4 5)
(IF T
(MV-LET (STATE RESULT ASSIGNMENTS)
(EXPAND-VARS NIL (IFF # #))
(MV STATE RESULT (CONS # ASSIGNMENTS)))
(MV STATE 'WHERE-NOT-MATCHED NIL))).
(See :DOC set-iprint to be able to see elided values in this message.)
My setup:
Install Racket
Open it and run the following code:
(pound)lang racket
(require (planet cce/dracula:8:23/lang/dracula))
Restart Dr Racket. Click the "Choose Language" at the bottom of the window and choose ACL2 under Dracula.
From the Dracula menu, choose "Change ACL2 Executable Path..." and choose "run_acl2" (or "run_acl2.exe") which is located in the installation folder of proofpad (i.e. "C:\Program Files (x86)\Proof Pad", if you have a 64 bits PC)
download PSP++ and run it. Make sure to unzip it in the Proofpad installation directory, otherwise it will tell you it didn't find the things it needed.
So, I have read from
setq and defvar in lisp,
http://www.cs.ucf.edu/courses/cop4020/spr2006/plsetup.html, and
In Lisp, how do I fix "Warning: Assumed Special?"
among other places about the difference between setf and defvar. So I decided to play around with the idea a bit:
CL-USER> (defun foo ()
(setf x 10)
(print x))
; in: DEFUN FOO
; (SETF X 10)
; ==>
; (SETQ X 10)
;
; caught WARNING:
; undefined variable: X
;
; compilation unit finished
; Undefined variable:
; X
; caught 1 WARNING condition
FOO
CL-USER> x
; Evaluation aborted on #<UNBOUND-VARIABLE X {10040F1543}>.
CL-USER> (foo)
10
10
CL-USER> x
10
Okay, I know that setf should be used to change the value of an existing variable, but the undefined variable warning seems to be handled pretty well in SBCL (though I have read that different CL implementations may handle this differently, thus it isn't the best thing to do).
Enter the second test:
CL-USER> (defun bar ()
(defvar y 15)
(print y))
; in: DEFUN BAR
; (PRINT Y)
;
; caught WARNING:
; undefined variable: Y
;
; compilation unit finished
; Undefined variable:
; Y
; caught 1 WARNING condition
BAR
CL-USER> y
; Evaluation aborted on #<UNBOUND-VARIABLE Y {10045033D3}>.
CL-USER> (bar)
15
15
CL-USER> y
15
As per the links, I changed the setf to defvar which I think should create and bind the variable all at once. Now my undefined variable warning gets pushed into the (print y) line ... what is going on here?
As a secondary question, I am expecting the values of any variables assinged within a funciton to be inaccessible outside of the function, as is the case in Python:
>>> def foo():
... x = 10
... print x
...
>>> foo()
10
>>> x
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
I am guessing this has something to do with the way common lisp deals with scope, ie defvar creates a "global special variabe" ... So I tried one last time with (let ...)
CL-USER> (defun baz ()
(let ((z 10)) (print z))
(incf z 10)
(print z))
; in: DEFUN BAZ
; (INCF Z 10)
; --> LET*
; ==>
; (SETQ Z #:NEW0)
;
; caught WARNING:
; undefined variable: Z
;
; compilation unit finished
; Undefined variable:
; Z
; caught 1 WARNING condition
And after reading What's difference between defvar, defparameter, setf and setq, this one seems to work right:
CL-USER> (defun apple ()
(defparameter x 10)
(print 10))
APPLE
CL-USER> x
; Evaluation aborted on #<UNBOUND-VARIABLE X {1004436993}>.
CL-USER> (apple)
10
10
CL-USER> x
10
Just to reiterate my questions:
1) what is really going on with setf, defvar and let?
2) is there a way to get common lisp to scope the variables inside a function as in the python example?
answering 2) DEFVAR defines a variable. But it has not been executed. So the compiler does not know about the variable in the print form - when compiling the DEFUN form.. It's also inside a DEFUN. Thus it is not on the top-level. As a top-level form the compiler would recognize the DEFVAR and would notice that y is a global special variable.
Just to reiterate my questions: 1) what is really going on with setf, defvar and let?
2) is there a way to get common lisp to scope the variables inside a function as in the python example?
1) SETF sets a variable value, but does not define it. If that variable is undefined, then the Common Lisp standard does not really say what happens. Most Common Lisp implementations will do something useful. Typically it gets executed as if the variable would have been declared special (thus you also get a warning).
DEFVAR is used as a top-level form (usually not inside functions) to define global special variables. Since DEFVAR declares the variable name to be special, it is a very useful convention to write a variable with stars around it: *y* instead of just y.
LET defines a scope for local variables.
2) Common Lisp functions have the parameter list to introduce variables. Other than that they don't define a variable scope. If you want to introduce a local variable inside a function, use LET.
>>> def foo():
... x = 10
... print x
Is
(defun foo ()
(let ((x 10))
(print x)))
Again: a function does not provide a scope for variables, such that assigning a variable inside a function will automagically define it to be function-local. Use LET instead.
Note also that LET is syntactic sugar, mostly: (let ((a 1) (b 2)) (+ a b)) is basically doing the same as ((lambda (a b) (+ a b)) 1 2). It's just a simple function application written differently to improve it for the human reader.
There is also support in Common Lisp for an older syntax:
(defun foo (&aux (x 10))
(print x))
Above defines a local variable X, just like a LET would do.
I'll keep it short and simple:
1) what is really going on with setf, defvar and let?
defvar and defparameter are used to declare and set globally special variables. They only differ when the name is already bound.
setf is used for assignment (to special variables, lexical variables, and other – possibly custom – setfable places.)
let (and let*) creates new variable bindings that are visible inside its body. It may create either lexical or special bindings, depending on (global or local) declarations. If there are no special declarations, lexical bindings will be created.
2) is there a way to get common lisp to scope the variables inside a
function as in the python example?
Put the code inside let's body, where the binding is visible:
CL-USER> (defun baz ()
(let ((z 10))
(print z)
(incf z 10) ; i.e. (setf z (+ z 10))
(print z)))
BAZ
CL-USER> (baz)
10
20
20
CL-USER> z
; Evaluation aborted on #<UNBOUND-VARIABLE #x186C611E>.
Given the program:
import Debug.Trace
main = print $ trace "hit" 1 + trace "hit" 1
If I compile with ghc -O (7.0.1 or higher) I get the output:
hit
2
i.e. GHC has used common sub-expression elimination (CSE) to rewrite my program as:
main = print $ let x = trace "hit" 1 in x + x
If I compile with -fno-cse then I see hit appearing twice.
Is it possible to avoid CSE by modifying the program? Is there any sub-expression e for which I can guarantee e + e will not be CSE'd? I know about lazy, but can't find anything designed to inhibit CSE.
The background of this question is the cmdargs library, where CSE breaks the library (due to impurity in the library). One solution is to ask users of the library to specify -fno-cse, but I'd prefer to modify the library.
How about removing the source of the trouble -- the implicit effect -- by using a sequencing monad that introduces that effect? E.g. the strict identity monad with tracing:
data Eval a = Done a
| Trace String a
instance Monad Eval where
return x = Done x
Done x >>= k = k x
Trace s a >>= k = trace s (k a)
runEval :: Eval a -> a
runEval (Done x) = x
track = Trace
now we can write stuff with a guaranteed ordering of the trace calls:
main = print $ runEval $ do
t1 <- track "hit" 1
t2 <- track "hit" 1
return (t1 + t2)
while still being pure code, and GHC won't try to get to clever, even with -O2:
$ ./A
hit
hit
2
So we introduce just the computation effect (tracing) sufficient to teach GHC the semantics we want.
This is extremely robust to compile optimizations. So much so that GHC optimizes the math to 2 at compile time, yet still retains the ordering of the trace statements.
As evidence of how robust this approach is, here's the core with -O2 and aggressive inlining:
main2 =
case Debug.Trace.trace string trace2 of
Done x -> case x of
I# i# -> $wshowSignedInt 0 i# []
Trace _ _ -> err
trace2 = Debug.Trace.trace string d
d :: Eval Int
d = Done n
n :: Int
n = I# 2
string :: [Char]
string = unpackCString# "hit"
So GHC has done everything it could to optimize the code -- including computing the math statically -- while still retaining the correct tracing.
References: the useful Eval monad for sequencing was introduced by Simon Marlow.
Reading the source code to GHC, the only expressions that aren't eligible for CSE are those which fail the exprIsBig test. Currently that means the Expr values Note, Let and Case, and expressions which contain those.
Therefore, an answer to the above question would be:
unit = reverse "" `seq` ()
main = print $ trace "hit" (case unit of () -> 1) +
trace "hit" (case unit of () -> 1)
Here we create a value unit which resolves to (), but which GHC can't determine the value for (by using a recursive function GHC can't optimise away - reverse is just a simple one to hand). This means GHC can't CSE the trace function and it's 2 arguments, and we get hit printed twice. This works with both GHC 6.12.4 and 7.0.3 at -O2.
I think you can specify the -fno-cse option in the source file, i.e. by putting a pragma
{-# OPTIONS_GHC -fno-cse #-}
on top.
Another method to avoid common subexpression elimination or let floating in general is to introduce dummy arguments. For example, you can try
let x () = trace "hi" 1 in x () + x ()
This particular example won't necessarily work; ideally, you should specify a data dependency via dummy arguments. For instance, the following is likely to work:
let
x dummy = trace "hi" $ dummy `seq` 1
x1 = x ()
x2 = x x1
in x1 + x2
The result of x now "depends" on the argument dummy and there is no longer a common subexpression.
I'm a bit unsure about Don's sequencing monad (posting this as answer because the site doesn't let me add comments). Modifying the example a bit:
main :: IO ()
main = print $ runEval $ do
t1 <- track "hit 1" (trace "really hit 1" 1)
t2 <- track "hit 2" 2
return (t1 + t2)
This gives us the following output:
hit 1
hit 2
really hit 1
That is, the first trace fires when the t1 <- ... statement is executed, not when t1 is actually evaluated in return (t1 + t2). If we define the monadic bind operator as
Done x >>= k = k x
Trace s a >>= k = k (trace s a)
instead, the output will reflect the actual evaluation order:
hit 1
really hit 1
hit 2
That is, the traces will fire when the (t1 + t2) statement is executed, which is (IMO) what we really want. For example, if we change (t1 + t2) to (t2 + t1), this solution produces the following output:
hit 2
really hit 2
hit 1
The output of the original version remains unchanged, and we don't see when our terms are really evaluated:
hit 1
hit 2
really hit 2
Like the original solution, this also works with -O3 (tested on GHC 7.0.3).