I have following class:
(define stackClass%
(class object%
(super-new)
(init-field (mystack '(A B C)))
(define/public (push n)
(set! mystack (cons n mystack)))
(define/public (pop)
(cond [(empty? mystack) #f]
[else (define res (car mystack))
(set! mystack (cdr mystack))
res] ))
(define/public (get)
mystack) ))
I create an object and alter it:
(define sc (new stackClass%))
(send sc push 1)
(send sc push 2)
Can I now save this "sc" object as a binary file to be retrieved later? If yes, would I need to save the stackClass% also? (In reality the objects may be much more complex and may even have other objects, images, files etc, in addition to simple numbers or text).
I checked the documentation at different places including http://docs.racket-lang.org/binary-class/index.html but could not understand how to achieve this.
The racket object system has support for serialization. That means your class must be defined with define-serializable-class and it needs to implement externalize and internalize. externalize needs to return a representation that only consist of serializable data (except instances og its own class) and it seems the system will do the rest. internalize method needs to take that format and set the members on a freshly created instance accordingly.
Racket seem to add some information so that the rest happens magically as long as the class is defined in the system that unserializes the data.
Related
If you evaluate (list-tail '(1 2) 3) at guile scheme. You will get an exception.
It would be smarter to have an '() as answer.
Overall why do we haven't closure property with respect to cdr combinator? What complications may arise?
Examples to make my point clearer
Now (cdr (cdr (cdr '(1 2))) -> raise-exception
Should be (cdr (cdr (cdr ... (cdr '(1 2))...))) -> ()
Then we would automatically have properly working list-tail
(define (list-tail list n)
(if (= n 0)
list
(list-tail (cdr list) (- n 1)))
Group-by then could be written elegantly and exceptionless
(define (group-by list-arg n)
(if (null? list-arg)
'()
(cons (list-head n) (list-tail n))))
The historic answer is that:
Originally, the Lisp 1 and 1.5 languages created by John MacCarthy did not allow (CDR NIL). The CDR function required a cons cell argument.
The idea that it would be convenient for (CDR NIL) to just return NIL came from a dialect called Interlisp (but may have been present elsewhere).
In the 1960's, there was another major dialect of Lisp called MacLisp (two decades before the Apple Mac, unrelated).
According to The Evolution of Lisp by Peter Gabriel and Guy Steele, some MacLisp people held a pow-wow with Interlisp people in 1974:
In 1974, about a dozen persons attended a meeting at MIT between the MacLisp and Interlisp implementors, including Warren Teitelman, Alice Hartley, Jon L White, Jeff Golden, and Guy Steele. There was some hope of finding substantial common ground, but the meeting actually served to illustrate the great chasm separating the two groups, in everything from implementation details to overall design philosophy. [...] In the end only a trivial exchange of features resulted from “the great MacLisp/Interlisp summit”: MacLisp adopted from Interlisp the behavior (CAR NIL) → NIL and (CDR NIL) → NIL, and Interlisp adopted the concept
of a read table.
Both Interlisp and MacLisp are ancestral dialects to Common Lisp, which also has the forgiving car and cdr.
Further remarks are made in the above paper on this matter, begining with:
The adoption of the Interlisp treatment of NIL was not received with universal warmth.
You can see from this fifty, sixty years ago, Lisp people were already divided into camps, and didn't agree on everything. Whether the car of an empty list should just yield the empty list, or error out is a very old issue.
Ashwin Ram, presently director of AI at Google, put in his own opinion in favor of forgiving cdr in 1986, when he composed this poem.
It still remains a divisive issue that is a matter of opinion.
It is undeniable that the flexible car, cdr and their derivatives can help you "code golf" list processing code.
It's also true that such code-golfed code sometimes handles only happy cases without error checking, which can cause problems in some circumstances.
For instance, some list that is assumed to always have three items is subject to (caddr list) to get the third item. But, due to some bug, it has only two. Now the code just ran off with the nil value, which may cause a problem somewhwere else. For instance, suppose the value is expected to be a string, and in some totally different function elsewhere, nil is passed to some API that needs a string and blows up. Now you're hunting through the code to discover where this nil came from.
People who write Lisp interpreters or compilers that rely on the forgiving destructuring performed by car and cdr end up producing something that accepts bad syntax silently.
For instance
(defun interpret-if (form env)
(let ((test (car form))
(then (cadr form))
(else (caddr form)))
(if (interpret-expr test env)
(interpret-expr then env)
(interpret-expr else env))))
This is actually a very nice example for discussing both sides of the issue.
On the one hand, the code is succinct, and nicely supports the optional else clause: the user of this interpreter can do:
(if (> x y)
(print "x is greater than y"))
In interpret-if, the else variable will pull out a nil, and that will get handed off to (eval expr else env) where it just evaluates to nil, and everything is cool; the optionality of else was obtained from free thanks to caddr not complaining.
On the other hand, the interpreter doesn't diagnose this:
(if) ;; no arguments at all
or this:
(if (> x y)) ;; spec says "then" is required, but no error!
However, all these issues have nice solutions and ways of working that don't require tightening up the list accessor functions, so that we can resort to the succinct coding when we need to. For instance, the interpreter could use pattern matching of some kind, like Common Lisp's rudimentary destructuring-bind:
(defun interpret-if (form env)
(destructuring-bind (test then &optional else) form
(if (interpret-expr test env)
(interpret-expr then env)
(interpret-expr else env))))
destructuring-bind has strict checking. It generates code with car, caddr and other functions under the hood, but also error checking code. The list (1 2 3) will not be destructured by the pattern (a b).
You have to look at the entire language and how it is used and what else is in it.
Introducing forgiving car and cdr into Scheme might give you less mileage than you think. There is another issue, which is that the only Boolean false value in Scheme is #f. The empty list () in Scheme is not false.
Therefore, even if car is forgiving, code like this cannot work.
Suppose the third element of a list is always a number, or else it doesn't exist. In Lisp, we can do this to default to zero:
(or (third list) 0)
for that to work in Scheme in the default 0 case, (third list) would have to return the Boolean false value #f.
A plausible approach might be to have different default values for car and cdr:
(car ()) -> #f
(cdr ()) -> ()
However, that is rather arbitrary: it works in some circumstances, but fails in situations like:
;; if list has more than two items ...
(if (cddr list) ...)
If cddr returns () by default, then that is always true, and so the test is useless. Different defaulting for car and cdr would probably be more error prone than common defaulting.
In Lisp, the forgiving list accessors work in a synergistic way with the empty list being false, which is why once upon a time I was quite surprised to learn that the forgiving list accessors came in fairly late into the game.
Early Scheme was implemented as a project written in Lisp, and therefore to interoperate smoothly with the host language, it used the same convention: () being NIL being the empty list and false. This was eventually changed, and so if you're wishing to have that back, you're asking for Scheme to revert a many-decades-old decision which is next to impossible now.
Object-oriented programming weighs in on this also. The fact that (car nil) does something instead of failing is an instance of the Null Object Pattern, which is something useful and good. We can express this in the Common Lisp object system, in which it practically disappears:
Suppose we had a car function which blows up on non-conses. We could write a generic function kar which doesn't, like this:
;; generic fun
(defgeneric kar (obj))
;; method specialization for cons class: delegate to car.
(defmethod kar ((obj cons))
(car obj))
;; specialization for null class:
(defmethod kar ((obj null))) ;; return nil
;; catch all specialization for any type
(defmethod kar ((obj t))
:oops)
Test:
[1]> (kar nil)
NIL
[2]> (kar '(a . b))
A
[3]> (kar "string")
:OOPS
In CLOS, the class null is that class whose only instance is the object nil. When a method parameter specializes to null, that method is only eligible when the argument for that parameter nil.
The class t is the superclass of everything: the top of the type spindle. (There is a bottom of the type spindle also, the class named nil, which contains no instances and is a subclass of everything.)
Specializing methods on null lets us catch method calls with nil parameters. Thanks to CLOS multiple dispatch, these can be thus handled in any parameter position. Because of that, and null being a class, the Null Object Pattern disappears in CLOS.
If you're debating Lisp with OOP people, you can present (car nil) can be spoken about as being the Null Object pattern.
The inconvenience of explicit null handling is recognized in numerous newer programming languages.
A common feature nowadays is to have null safe object access. For instance
foo.bar
might blow up if foo is null. So the given language provides
foo?.bar
or similar, which will only dereference .bar if foo isn't nil, otherwise the expression yields nil.
When languages add foo?.bar, they do not throw away foo.bar, or make foo.bar behave like foo?.bar. Sometimes you want the error (foo being nil is a programming error you want to catch in testing) and sometimes you want the default.
Sometimes you want the default, so you can collapse multiple levels of default and catch an error:
if (foo?.bar?.xyzzy?.fun() == nil) {
// we coudn't have fun(); handle it
// this was because either foo was nil, or else bar was nil,
// or else xyzzy was nil, or else fun() returned nil.
} else {
// happy case
}
cdr is only allowed on pairs. When you reach the end of the list, the value is (), which is not a pair, so you get an error.
You can check for this in your list-tail procedure to allow it to be more permissive.
(define (list-tail list n)
(if (or (= n 0) (not (pair? list)))
list
(list-tail (cdr list) (- n 1)))
Using (not (pair? list)) will also allow it to work for improper lists like (1 2 . 3). It will keep returning 3 for any n >= 2.
"You will get an exception."
This is a problem with many core libraries, and not just Scheme. Take Haskell's core library:
tail [1] -- []
tail [] -- error
head [1] -- 1
head [] -- error
As you know, the technical name for a function like this is a Partial Function. It is a function that doesn't work for some inputs, leading to errors.
So, yes, you can define your own version. One thing, though - what should be returned in the end condition? Should (list-tail '(1 2) 3) return () or should it return 0? If I'm trying to get a value to add to another number, then 0 would be appropriate. If I'm using cons to gather values then () would be appropriate. I guess that's why the function is left as partial.
"Right. I was interested why scheme was designed that way, without car/cdr closure property. Is it feature or just design flaw. It's more like scheme is less consistent than Common Lisp, rather strict."
Common Lisp returns NIL when it runs out of list:
(car '(1)) ; 1
(car '()) ; NIL
(cdr '(1)) ; 1
(cdr '()) ; NIL
In this case you would have to test for NIL, and if you wanted a zero instead make the replacement.
Why Scheme didn't have this is due to its minimalistic design. The report was so under-specified you could do pointer arithmetic and just let the program segfault since any faulty scheme code was deemed not scheme and pigs could fly. Later reports, like R7RS, requires much more error checking since it is required to signal errors in many situations where just undefined behavior would be OK in early reports.
With today's Scheme we can easily create car and cdr that does what you want:
#!r7rs
(define-library
(sylwester pair-accessors)
(export car cdr)
(import (rename (scheme base) (car base:car) (cdr base:cdr))
(except (scheme base) (car cdr)))
(begin
(define (car v)
(if (pair? v)
(base:car v)
'()))
(define (cdr v)
(if (pair? v)
(base:cdr v)
'()))))
So in your library or program you just import (scheme) (or (scheme base)) without car and cdr and also import (sylwester pair-accessors) and you're in business. Alternatively you can make a (scheme base) or (scheme) that replaces all accessors with you own safe ones using a macro to produce them all.
The only thing you cannot do is inject your version of car/cdr into already defined libraries since that would require some late binding or monkey-patching, but that isn't supported by the language. I'm fascinated by these things and would love to make a OO-scheme where you can augment standard procedures with some CLOS-ish late binding where all core functions under the hood are indeed methods so that you can define your own objects and accessors and that standard libraries and user libraries created for normal pairs would just work out of the box for your new data structures that has pair like features.
I have quite simple set of .rkt sources and, say, "a.rkt" and "b.rkt" among them. I'd like to be able to write (require "a.rkt") in "b.rkt" and vice versa. Now I'm facing error about "loading cycle".
Can I solve this issue with bare modules without adding units? Does Racket have anything similar to forward declaration so I could simple add missing signature instead of requiring? If both answers are "No", does someone know good and understandable tutorial on how to implement units with typed/racket (aside of official docs)?
You can use lazy-require:
;; a.rkt
#lang racket
(require racket/lazy-require)
(lazy-require ["b.rkt" (b)])
(provide a)
(define (a) 'a)
(list (a) (b))
;; b.rkt
#lang racket
(require racket/lazy-require)
(lazy-require ["a.rkt" (a)])
(provide b)
(define (b) 'b)
(list (a) (b))
Notice that you must tell lazy-require the specific things you want to import. That's because it is implemented in terms of dynamic-require plus set!.
If you peek at the source for xrepl, you'll see it define a defautoload macro, which (modulo some N/A details) is simply:
(define-syntax-rule (defautoload libspec id ...)
(begin
(define id
(make-keyword-procedure
(λ (kws kw-args . args)
(set! id (dynamic-require 'libspec 'id))
(keyword-apply id kws kw-args args))))
...))
Is there a way to access a stored list in Racket without passing it new data? A list of past responses is stored using the following code in a program I'm working on.
(define (storage response lst)
(cons response lst))
This makes a list by taking a response to a question and a previous list. I don't want to change what's in the list just simply see what's inside it. If other code is needed I will be happy to show what I have.
The standard way to access a list's elements in Racket is by using the first and rest procedures (or equivalently: car and cdr) to recursively iterate over a list. For example, let's say that you want to find out if the list contains the "404" response:
(define responses '("302" "403" "404" "505"))
(define (find-response lst response)
; the list is empty, the element was not found
(cond ((empty? lst)
#f)
; `first` accesses the first element in the list
((equal? (first lst) response)
#t)
(else
; `rest` advances to the next elements in the list
(find-response (rest lst) response))))
(find-response responses "404")
=> #t
(find-response responses "201")
=> #f
Of course, once you learn how this works, you can move and use existing procedures, for example member as suggested in the other answers. Please take a look at the list procedures available for use, you'll see that the most frequent operations are already implemented and at your disposal.
As currently constructed, you created a function called storage that takes response and a list and returns a new list with response as the head and lst as the tail.
If you want to get the head or tail of (storage a l) then you just call (car (storage a l)) or (cdr (storage a l))- it's just a list.
Yes, there is a way to access a stored list without passing it as new data. See page 25, Section 6.3.2 in the Scheme R5RS Specification for a full list of 'list accessing' functions. Racket probably has more; other Scheme versions may have additional ones.
Here is an example. To test if a 'response' has been seen already:
(member response lst)
to count the number of responses:
(length lst)
I'm evaluating/testing a browser based application presumably written in common lisp. Apart from the browser based interface, the software provides a 'Listener' window with a 'CL-User >' REPL prompt.
I wish to examine the list of functions, symbols, and packages from the REPL prompt. So that I could co-relate the frontend functionality with what is exposed via the REPL.
Google search is futile for me as it leads to tutorials and resources that teaches lisp step-by-step.
Any hints, pointers on examining the state via REPL will be much appreciated.
If you don't know what symbols you're looking for, but do know what packages you want to search, you can drastically reduce the amount of searching you have to do by only listing the symbols from those specific packages:
(defun get-all-symbols (&optional package)
(let ((lst ())
(package (find-package package)))
(do-all-symbols (s lst)
(when (fboundp s)
(if package
(when (eql (symbol-package s) package)
(push s lst))
(push s lst))))
lst))
(get-all-symbols 'sb-thread) ; returns all the symbols in the SB-THREAD package
The line (get-all-symbols 'sb-thread) does just that.
If you have an idea about what type of symbols you're looking for, and want to take a guess at their names, you can do this
(apropos-list "mapc-") ; returns (SB-KERNEL:MAPC-MEMBER-TYPE-MEMBERS SB-PROFILE::MAPC-ON-NAMED-FUNS)
(apropos-list "map" 'cl) ; returns (MAP MAP-INTO MAPC MAPCAN MAPCAR MAPCON MAPHASH MAPL MAPLIST)
(apropos-list) returns all symbols whose name contains the string you pass in, and takes an optional package to search.
As far as figuring out what all those symbols do, well, try this: http://www.psg.com/~dlamkins/sl/chapter10.html
To list everything:
(apropos "")
To list everything from a specific package add 'project-name:
(apropos "" 'quickproject)
To list all the packages (duh):
(list-all-packages)
To find functions exported from a particular package:
(loop for x being the external-symbol of "CL" when (fboundp x) collect x)
(let ((lst ()))
(do-all-symbols (s lst)
(when (fboundp s) (push s lst)))
lst)
Pretty much taken as-is from here.
Maybe something like this:
(defun get-symbols-in-package (&optional (package *package*))
(let ((lst ()))
(do-symbols (s package)
(push s lst))
lst))
Use as (get-symbols-in-package) or (get-symbols-in-package 'foo) ...
I've been reading through SICP (Structure and Interpration of Computer Programs) and was really excited to discover this wonderful special form: "make-environment", which they demonstrate to use in combination with eval as a way of writing modular code (excerpt from section 4.3 on "packages"):
(define scientific-library
(make-environment
...
(define (square-root x)
...)))
They then demonstrate how it works with
((eval 'square-root scientific-library) 4)
In their example, they then go on to demonstrate exactly the usage that I would want - an elegant, minimalist way of doing the "OO" style in scheme... They "cons" together a "type", which is actually what was returned by the "make-environment" special form (i.e. the vtable), and an arg ("the state")...
I was so excited because this is exactly what I've been looking for as a way to do polymorphic dispatch "by symbol" in Scheme without having to write lots of explicit code or macros.
i.e. I want to create an "object" that has, say, two functions, that I call in different contexts... but I don't want to refer to them by "car" and "cdr", I want to both declare and evaluate them by their symbolic names.
Anyway, when I read this I couldn't wait to get home and try it.
Imagine my disappointment then when I experienced the following in both PLT Scheme and Chez Scheme:
> (make-environment (define x 3))
Error: invalid context for definition (define x 3).
> (make-environment)
Error: variable make-environment is not bound.
What happened to "make-environment" as referenced in SICP? It all seemed so elegant, and exactly what I want, yet it doesn't seem to be supported in any modern Scheme interpreters?
What's the rationale? Is it simply that "make-environment" has a different name?
More information found later
I took at look at the online version:
https://mitp-content-server.mit.edu/books/content/sectbyfn/books_pres_0/6515/sicp.zip/full-text/book/book-Z-H-28.html#%_sec_4.3
I was reading was the first edition of SICP. The second edition appears to have replaced the discussion on packages with a section on non-deterministic programming and the "amp" operator.
After more digging around I discovered this informative thread on newsnet:
"The R5RS EVAL and environment specifiers are a compromise between
those who profoundly dislike first-class environments and want a
restricted EVAL, and those who can not accept/understand EVAL without
a second argument that is an environment."
Also, found this "work-around":
(define-syntax make-environment
(syntax-rules ()
((_ definition ...)
(let ((environment (scheme-report-environment 5)))
(eval '(begin definition
...)
environment)
environment))))
(define arctic
(make-environment
(define animal 'polarbaer)))
(taken from this)
However, I ended up adopting a "message passing" style kinda of like the first guy suggested - I return an alist of functions, and have a generic "send" method for invoking a particular function by name... i.e something like this
(define multiply
(list
(cons 'differentiate (...))
(cons 'evaluate (lambda (args) (apply * args)))))
(define lookup
(lambda (name dict)
(cdr (assoc name dict))))
; Lookup the method on the object and invoke it
(define send
(lambda (method arg args)
((lookup method arg) args)))
((send 'evaluate multiply) args)
I've been reading further and am aware that there's all of CLOS if I really wanted to adopt a fully OO style - but I think even above is somewhat overkill.
They wrote it like that because MIT Scheme does, in fact, have first-class environments, and presumably that's what the writers were planning to teach their class with (since the book was written at MIT).
Check out http://groups.csail.mit.edu/mac/projects/scheme/
However, I've noticed that MIT Scheme, while still somewhat actively developed, lacks many of the features that a really modern Scheme would have, like a foreign function interface or GUI support. You probably wouldn't want to use it for a serious software development project, at least not by itself.
Scheme has no first-class environments because of performance reasons. When Scheme was created, it wasn't the fastest language around due to nifty stuff like first-class functions, continuations, etc. Adding first-class environments would have crippled the performance even further. So it was a trade-off made in the early Scheme days.
Would a classical dispatcher function work? I think this is similar to what you're looking for.
(define (scientific-library f)
(define (scientific-square-root x) (some-scientific-square-root x))
(cond ((eq? f 'square-root) scientific-square-root)
(else (error "no such function" f))))
(define (fast-library f)
(define (fast-square-root x) (some-fast-square-root x))
(cond ((eq? f 'square-root) fast-square-root)
(else (error "no such function" f))))
((scientific-library 'square-root) 23)
((fast-library 'square-root) 23)
You could even combine the example scientific and fast libraries into one big dispatch method:
(define (library l f)
(define (scientific-library f)
...)
(define (fast-library f)
...)
(cond ((eq? l 'scientific) (scientific-library f))
((eq? l 'fast) (fast-library f))
(else (error "no such library" l))))
(library 'fast 'square-root)