I read a lot about generic functions in CL. I get it. And I get why they are valuable.
Mainly, I use them for when I want to execute a similar action with different data types, like this:
(defgeneric build-url (account-key)
(:documentation "Create hunter api urls"))
(defmethod build-url ((key number))
"Build lead api url"
(do-something...))
(defmethod build-url ((key string))
"build campaign api url"
(do-somthing... ))
In this example, campaign-url and lead-url are structures (defstruct).
My question is, at a high level, how do classes add value to the way generic functions + structures work together?
Structures historically predate classes, are more restricted and more "static" than classes: once a structure is defined, the compiler can generate code that accesses its slots efficiently, can assume their layout is fixed, etc. There is a lot of inlining or macro-expansion done that makes it necessary to rebuild everything from scratch when the structure changes. Being able to redefine a struct at runtime is not something defined by the standard, it is merely implementations trying to be nice.
On the other hand, classes have more features and are easier to manipulate at runtime. Suppose you write this class:
(defclass person ()
((name :initarg :name :reader .name)))
And you instantiate it:
(defparameter *someone* (make-instance 'person :name "Julia O'Caml"))
It is possible now to update the class definition:
(defparameter *id-counter* 0)
(defun generate-id ()
(incf *id-counter*))
(defclass person ()
((name :initarg :name :reader .name)
(dob :initarg :date-of-birth :reader .date-of-birth)
(%id :reader .id :initform (generate-id))))
And now, *someone*, which existed already, has two additional fields, dob that is unbound, and %id that is automatically initialized to 1. There is a whole section about Object Creation and Initialization (7.1) that defines how objects can be redefined, change class, etc.
Moreover, this mechanism is not fixed, a lot of the steps described above rely on generic functions. It is possible to define how an object is allocated, initialized, etc. The concept was standardized as what is known as the Meta-Object Protocol, which also introduces the concept of metaobject, the object representing a class: usually a class has a name, parent classes, slots, etc. but you can add new members to a class, or change how instance slots are organized (maybe your just need a global handle and a connection, and the actual instance slots are stored in another process?).
Note also that once CLOS/MOP was defined, it was also eventually possible to define structures in this framework: in the standard , defstruct (without a :type option) defines classes with a structure-class metaclass. Still, they do not behave like standard-class because as said above they are more restricted, and as such are subject to more aggressive compilation optimizations (in general).
Structures are nice if you need to program like in C and you are ok with recompiling all your code when the structure changes. It is however premature optimization to use them in all cases. It is possible to use a lot of standard objects without noticing much slowness nowadays (a bit like Python).
Related
I am currently starting to set up stumpwm, and I would like to assign a specific window to a particular group.
So far I have this:
(define-frame-preference "Spotify"
(0 t t :class "Spotify")
)
So essentially, I would expect that that would set the windows with the class Spotify to the group Spotify, this however does not happen.
Can anybody help me on this?
Thank you!
The relationship between X11 windows and Linux processes is thin: things are asynchronous, you start a process and some time later zero, one or more windows are created.
You have to work with callbacks, there is no easy way to create a process and synchronously have all its windows in return.
Some processes are nice enough to set the _NET_WM_PID property on windows (it looks like the "Spotify" application does it). You can retrieve this property as follows:
(first (xlib:get-property (window-xwin w) :_net_wm_pid))
Placement rules cannot help here, given how Spotify fails to set the class property early enough (see comments and other answer). But you can use a custom hook:
STUMPWM-USER> (let ((out *standard-output*))
(push (lambda (&rest args) (print args out))
*new-window-hook*))
(#<CLOSURE (LAMBDA (&REST ARGS)) {101A92388B}>)
Notice how I first evaluate *standard-output* to bind it lexically to out, so that the function can use it as a stream when printing informations. This is because the hook might be run in another thread, where the dynamic binding of the standard output might not be the one I want here (this ensures debugging in done in the Slime REPL, in my case).
When I start for example xclock, the following is printed in the REPL:
(#S(TILE-WINDOW "xclock" #x380000A))
So I can change the hook so that instead if does other things. This is a bit experimental but for example, you can temporarily modify the *new-window-hook* to react on a particular window event:
(in-package :stumpwm-user)
(let ((process (sb-ext:run-program "xclock" () :search t :wait nil))
(hook))
(sb-ext:process-kill process sb-unix:sigstop)
(flet ((hook (w)
(when (find
(sb-ext:process-pid process)
(xlib:get-property (window-xwin w) :_net_wm_pid))
(move-window-to-group w (add-group (current-screen) "XCLOCK"))
(setf *new-window-hook* (remove hook *new-window-hook*)))))
(setf hook #'hook)
(push #'hook *new-window-hook*))
(sb-ext:process-kill process sb-unix:sigcont))
Basically: create a process, stop it to minimize race conditions, define a hook that checks if the PID associated in the client matches the one of the process, execute some rules, then remove the hook from the list of hooks. This is fragile, since if the hook is never run, it stays in the list, and in case of errors, it also stays in the list. At the end of the expression, the hook is added and the process resumes execution.
So it seems like, as pointed out by coredump, the are issues in the way the Spotify window is defined.
As an alternative, there are fortunately plenty of ways to control spotify via Third Party Clients (ArchWiki)
Personally, I found that you can control spotify via Ivy on Emacs thanks to this project
Ivy Spotify and this will probably be what I will use.
This happens to me time and again: I define the class and forget that I wanted it funcallable or it is, say, Gtk widget class, thus it's metaclass needs to be stated. Once it is defined, however, SBCL doesn't let me change me the metaclass (even if there is no instance of this class). For example, evaluating
(defclass foo ()
((slot-a)))
and then adding a metaclass and re-evaluating:
(defclass foo ()
((slot-a))
(:metaclass gobject:gobject-class))
results in error:
Cannot CHANGE-CLASS objects into CLASS metaobjects.
[Condition of type SB-PCL::METAOBJECT-INITIALIZATION-VIOLATION]
See also:
The Art of the Metaobject Protocol, CLASS [:initialization]
Unfortunately I don't have a copy of The Art of the Metaobject Protocol to check what it says. For now the only way I could figure out is to restart lisp, which can be quite disruptive.
Since I realise the error soon enough, I don't mind dodging the defined class completely by removing it. Questions:
If I have created instances of the class, is there a way to find them to nullify them and get them GCed?
How to remove the class? Something like fmakunbound for functions.
Unfortunately I don't have a copy of The Art of the Metaobject Protocol to check what it says.
Even though I recommend reading the book, you can find some information online. See for example ENSURE-CLASS-USING-CLASS.
How to remove the class?
You can use (SETF FIND-CLASS):
(setf (find-class 'foo) nil)
Or, you can use the fancy slime inspector. You call slime-inspect-defintion while pointing the name of the class. Then, you'll see the name. When you select it, you inspect the symbol naming your class. Then, you can see something like:
It names the class FOO [remove]
Provided FOO only names a class, you can use the bigger hammer:
(unintern 'foo)
If I have created instances of the class, is there a way to find them to nullify them and get them GCed?
No, only the GC has the global view, and for practical reasons, it doesn't generally keep backward references about who references a particular object (and how)1.
There is no global record of all instances of a class unless you introduce your own (weak) hash-table to store them. But if you have kept a record of all of your instances, you can CHANGE-CLASS them. For example, you define:
(defclass garbage () ())
... any previously held reference in your object will be released and the GC has an opportunity to dispose of objects your instances where referencing. And when another object reference an instance of 'garbage, you can update it. Instead of using 'garbage, you could probably change instances of old classes to your new class (the name is the same, but the class object is different).
Note also that CHANGE-CLASS is a generic function.
1. Implementations might offer heap walkers. See for example Heap walkers in Allegro CL.
I am implementing a simple C-like language in OCaml and, as usual, AST is my intermediate code representation. As I will be doing quite some traversals on the tree, I wanted to implement
a visitor pattern to ease the pain. My AST currently follows the semantics of the language:
type expr = Plus of string*expr*expr | Int of int | ...
type command = While of boolexpr*block | Assign of ...
type block = Commands of command list
...
The problem is now that nodes in a tree are of different type. Ideally, I would pass to the
visiting procedure a single function handling a node; the procedure would switch on type of the node and do the work accordingly. Now, I have to pass a function for each node type, which does not seem like a best solution.
It seems to me that I can (1) really go with this approach or (2) have just a single type above. What is the usual way to approach this? Maybe use OO?
Nobody uses the visitor pattern in functional languages -- and that's a good thing. With pattern matching, you can fortunately implement the same logic much more easily and directly just using (mutually) recursive functions.
For example, assume you wanted to write a simple interpreter for your AST:
let rec run_expr = function
| Plus(_, e1, e2) -> run_expr e1 + run_expr e2
| Int(i) -> i
| ...
and run_command = function
| While(e, b) as c -> if run_expr e <> 0 then (run_block b; run_command c)
| Assign ...
and run_block = function
| Commands(cs) = List.iter run_command cs
The visitor pattern will typically only complicate this, especially when the result types are heterogeneous, like here.
It is indeed possible to define a class with one visiting method per type of the AST (which by default does nothing) and have your visiting functions taking an instance of this class as a parameter. In fact, such a mechanism is used in the OCaml world, albeit not that often.
In particular, the CIL library has a visitor class
(see https://github.com/kerneis/cil/blob/develop/src/cil.mli#L1816 for the interface). Note that CIL's visitors are inherently imperative (transformations are done in place). It is however perfectly possible to define visitors that maps an AST into another one, such as in Frama-C, which is based on CIL and offer in-place and copy visitor. Finally Cαml, an AST generator meant to easily take care of bound variables, generate map and fold visitors together with the datatypes.
If you have to write many different recursive operations over a set of mutually recursive datatypes (such as an AST) then you can use open recursion (in the form of classes) to encode the traversal and save yourself some boiler plate.
There is an example of such a visitor class in Real World OCaml.
The Visitor pattern (and all pattern related to reusable software) has to do with reusability in an inclusion polymorphism context (subtypes and inheritance).
Composite explains a solution in which you can add a new subtype to an existing one without modifying the latter one code.
Visitor explains a solution in which you can add a new function to an existing type (and to all of its subtypes) without modifying the type code.
These solutions belong to object-oriented programming and require message sending (method invocation) with dynamic binding.
You can do this in Ocaml is you use the "O" (the Object layer), with some limitation coming with the advantage of having strong typing.
In OCaml Having a set of related types, deciding whether you will use a class hierarchy and message sending or, as suggested by andreas, a concrete (algebraic) type together with pattern matching and simple function call, is a hard question.
Concrete types are not equivalent. If you choose the latter, you will be unable to define a new node in your AST after your node type will be defined and compiled. Once said that a A is either a A1 or a A2, your cannot say later on that there are also some A3, without modifying the source code.
In your case, if you want to implement a visitor, replace your EXPR concrete type by a class and its subclasses and your functions by methods (which are also functions by the way). Dynamic binding will then do the job.
currently, when I am experimenting the continuation in functional languages, my understanding is that a continuation records the current program counter and register files, and when a continuation is returned, then the PC and the registered files will be restored to the values it has recorded.
So in the following dumb example from Might's blog post,
; right-now : -> moment
(define (right-now)
(call-with-current-continuation
(lambda (cc)
(cc cc))))
; go-when : moment -> ...
(define (go-when then)
(then then))
; An infinite loop:
(let ((the-beginning (right-now)))
(display "Hello, world!")
(newline)
(go-when the-beginning)) ; here the-beginning continuation passed to go-when, which ultimately will have an continuation applied to an continuation, that returns a continuation, which will cause the the program point resumed to the PC and registers states recorded in it.
I am not sure my understanding right.. Please correct me if you think it is not.....
Program counter and register files are not what the continuation records.
The best way to describe the meaning of call-with-current-continuation is that it records the program context. For instance, suppose you're evaluating the program
(+ 3 (f (call-with-current-continuation g)))
In this case, the context of the call-with-current-continuation expression would be
(+ 3 (f [hole]))
That is, the stuff surrounding the current expression.
Call-with-current-continuation captures one of these contexts. Invoking a continuation causes the replacement of the current context with the one stored in the continuation.
The idea of a context is a lot like that of a stack, except that there's nothing special about function calls in contexts.
This is a very brief treatment. I strongly urge you to take a look at Shriram Krishnamurthi's (free, online) book PLAI, in particular Part VII, for a more detailed and careful look at this topic.
I'm using Hunchentoot and would like to change the name of the session cookie. This is implemented with a generic function and the docs say to change the name you can "specialize the function".
I'm not really sure what this means here. I was under the impression that specializing a function is to dispatch a method on certain argument types. In this particular case, the function takes the server acceptor and I don't want to change that. Can someone illuminate me on this?
The API: http://weitz.de/hunchentoot/#session-cookie-name
Here's the implementation in the source:
(defgeneric session-cookie-name (acceptor)
(:documentation "Returns the name \(a string) of the cookie \(or the
GET parameter) which is used to store a session on the client side.
The default is to use the string \"hunchentoot-session\", but you can
specialize this function if you want another name."))
(defmethod session-cookie-name ((acceptor t))
"hunchentoot-session")
Make a subclass and specialize that way:
(defclass my-acceptor (hunchentoot:acceptor) ())
(defmethod session-cookie-name ((acceptor my-acceptor))
"my-session")
The function still takes an acceptor, it's just your kind of acceptor, now.