I'm learning about ambiguity in grammars and I need a little help to understand better. Here is a grammar:
<S> ::= if <S> then <S>
<S> ::= if <S> then <S> else <S>
<S> ::= a
Using a parse tree or left-most derivation, how can I show that this grammar is ambiguous?
Consider the following:
if a then if a then a else a
You could consider grouping it either of the following two ways:
(if a then (if a then a else a))
or
(if a then (if a then a) else a)
Both are possible with the grammar you provide, so it's ambiguous.
Related
I'm attempting to implement a lisp version of a domain specific language that uses the binary operators and comparators on discrete probability distributions. Is there a safe(ish) and concise way to extend the functionality of these atoms < <= = >= > + - / * to work with new types, without completely bricking the language?
I realize just making new operator names would be the easiest solution, but that answer is not compelling nor fun, and certainly doesn't live up to lisp's reputation as the programmable programming language.
For example, say we have the hash-table:
((4 . 1/4) (3 . 1/4) (2 . 1/4) (1 . 1/4))
which we create with the macro (d 4), and we want to be able to compare it to a number like so
(< (d 4) 3)
which we would want to return a hash-table representing a 50% chance it's true and 50% chance it's false, say in this form:
((0 . 1/2) (1 . 1/2))
but currently it produces the error:
*** - <: #S(HASH-TABLE :TEST FASTHASH-EQL (4 . 1/4) (3 . 1/4) (2 . 1/4) (1 . 1/4)) is not a real number
There are three answers to this:
no, you can't do it because + &c are not generic functions in CL and you may not redefine symbols exported from the CL package ...
... but yes, of course you can do it if you're willing to accept a small amount of inconvenience, because Lisp is a programmable programming language ...
... but no, in fact you can't completely do it if you want to preserve the semantics of your extended language in fact, and there isn't anything you can do about that.
So let's look at these in order.
(1): The arithmetic operators are not generic functions in CL ...
This means you can't extend them: they work on numbers. And you can't redefine them because the language forbids that.
(2): ... but of course you can get around that ...
So, the first trick is we want to define a package in which the arithmetic operators are not the CL versions of them. We can do this manually, but we'll use Tim Bradshaw's conduits system to make life easier:
(in-package :org.tfeb.clc-user)
(defpackage :cl/generic-arith
;; The package people will use
(:use)
(:extends/excluding :cl
#:< #:<= #:= #:= #:> #:+ #:- #:/ #:*)
(:export
#:< #:<= #:= #:= #:> #:+ #:- #:/ #:*))
(defpackage :cl/generic-arith/user
;; User package
(:use :cl/generic-arith))
(defpackage :cl/generic-arith/impl
;; Implementation package
(:use :cl/generic-arith))
So now:
> (in-package :cl/generic-arith/user)
#<The CL/GENERIC-ARITH/USER package, 0/16 internal, 0/16 external>
> (describe '*)
* is a symbol
name "*"
value #<unbound value>
function #<unbound function>
plist nil
package #<The CL/GENERIC-ARITH package, 0/1024 internal, 978/1024 external>
So now we can get on with defining these things. There are some problems: because what we've done is create an environment where, for instance * is not cl:*, then anything which uses * as a symbol will not work. So for instance cl:* is bound the the value of the last form evaluated in the repl, and typing * isn't going to get that symbol: you'll need to type cl:*.
Similarly the + method combination will not work: you'd have to explicitly say
(defgeneric foo (...)
...
(:method-combination cl:+)
...)
So there is some pain. But not, probably, that much pain.
And now we can start implementing things. The obvious approach is to define generic functions which are 2-arg versions of the functions we need, and then define the functions on top of them. That means we can use things like compiler macros for the actual operators without fear of breaking the underlying generic functions.
So start by
(in-package :cl/generic-arith/impl)
(defgeneric +/2 (a b)
(:method ((a number) (b number))
(cl:+ a b)))
...
And now you think for a bit and realise that ...
(3) ... but there are problems you can't get around, in any language
The problem is at least this: + is one of the two operators on a field, and the way it is defined in CL in terms of some two-argument function like +/2 above is something like this (this may be wrong implementationally but it's how the maths would go):
(+ a) is a;
(+ a b) is (+/2 a b);
(+ a b ...) is (+/2 a (+ b ...)` and this is fine by associativity (but beware of floats).
And that looks fine but we've missed a case:
(+) is the additive identity of the field (and similarly (*) is the multiplicative identity).
Oh, wait: what field? For cl:+ this is fine: it's the identities of the field of numbers. But now? Who knows? And there's nothing that can be done about that: if you want + to work the way it does in CL, except on other fields, you can't have that.
In general if + and * are to represent the two operations of a field, then if zero-argument versions of those operators are allowed those should return the two identities of the field (which they do in CL). But that means that all fields they are defined for must share those two identities (which, again, they do in CL: the fields of rationals & complex numbers share identities). This means in turn that (+ x 3) (from (+ x (*) (*) (*))) must be allowed (and so on). Or you either disallow the zero-argument case, or that they represent the field operations, or both.
You can by using generic-cl, that does that and that is extensible.
(= "hello" y) ;; would throw an error in standard CL
You would :use :generic-cl instead of :cl in a package definition, and you would use :generic-cl-user at the REPL.
Subclass the methods equalp and lessp.
*Note: Despite having frequented StackOverflow for a long time, this is the first question that I have posted myself. Apologies if it's a bit verbose. Constructive criticism appreciated.
When I define a struct in Common Lisp using defstruct, a predicate function is automatically generated that tests whether its argument is of the type defined by the defstruct. Eg:
(defstruct book
title
author)
(let ((huck-finn (make-book :title "The Adventures of Huckleberry Finn" :author "Mark Twain")))
(book-p huck-finn))
=> True
However, when defining a class using defclass, such functions are seemingly not generated by default (is there a way to specify this?), so I'm trying to add this functionality myself, because I'd like a) for this syntax to be consistent between structs and classes, b) to have an abbreviation of (typep obj 'classname), which I need to write very often and is visually noisy,
and c) as a programming exercise, since I'm still relatively new to Lisp.
I could write a macro that defines a predicate function given the name of a class:
(defclass book ()
((title :initarg :title
:accessor title)
(author :initarg :author
:accessor author)))
;This...
(defmacro gen-predicate (classname)
...)
;...should expand to this...
(defun book-p (obj)
(typep obj 'book))
;...when called like this:
(gen-predicate 'book)
The name that I need to pass to defun must be of the form 'classname-p. Here's where I have difficulty. To create such a symbol, I could use the "symb" function from Paul Graham's On Lisp (p. 58). When it is run on the REPL:
(symb 'book '-p)
=> BOOK-P
My gen-predicate macro looks like this so far:
(defmacro gen-predicate (classname)
`(defun ,(symb classname '-p) (obj)
(typep obj ,classname)))
(macroexpand `(gen-predicate 'book))
=>
(PROGN
(EVAL-WHEN (:COMPILE-TOPLEVEL) (SB-C:%COMPILER-DEFUN '|'BOOK-P| 'NIL T))
(SB-IMPL::%DEFUN '|'BOOK-P|
(SB-INT:NAMED-LAMBDA |'BOOK-P|
(OBJ)
(BLOCK |'BOOK-P| (TYPEP OBJ 'BOOK)))
NIL 'NIL (SB-C:SOURCE-LOCATION)))
T
It would seem that the symbol created by (symb 'book '-p) is actually considered |'BOOK-P| by the implementation (SBCL), not BOOK-P. Sure enough, this now works:
(let ((huck-finn (make-instance 'book)))
(|'BOOK-P| huck-finn))
=> True
Why is the symbol created by symb interned as |'BOOK-P|? In On Lisp (same page as above) Graham says: "Any string can be the print-name of a symbol, even a string containing lowercase letters or macro characters like parentheses. When a symbol's name contains such oddities, it is printed within vertical bars." No such oddities exist in this case, do they? And am I correct in thinking that the "print-name" of a symbol is what is actually displayed on the standard output when the symbol is printed, and is, in the case of such oddities, distinct from the form of the symbol itself?
To be able to write function-defining macros like gen-predicate - whose defined functions are named based on the arguments passed to the macro - seems to me like something that Lisp hackers have probably been doing for ages. User Kaz says here (Merging symbols in common lisp) that the "mashing-up" of symbols can often be avoided, but that would defeat the purpose of this macro.
Finally, assuming I could get gen-predicate to work how I want, what would be the best way of ensuring that it be called for each new class as they are defined? Much in the same way as initialize-instance can be customized to perform certain actions upon instantiation of a class, is there a generic function called by defclass that can perform actions upon definition of a class?
Thank you.
That's a usual problem: what gets passed to a Macro?
Compare calls like this:
(symb 'book '-p)
and
(symb ''book '-p)
Your macro form is this:
(gen-predicate 'book)
GEN-PREDICATE is a macro. classname is a parameter for this macro.
Now what is the value of classname inside the macro during code expansion? Is it book or 'book?
Actually it is the latter, because you wrote (gen-predicate 'book). Remember: macros see source code and the argument source gets passed to the macro function - not the value. The argument is 'book. Thus this gets passed. (QUOTE BOOK) is the same, only printed differently. So it is a two element list. The first element is the symbol QUOTE and the second element is the symbol BOOK.
Thus the macro now calls the function SYMB with the argument value (QUOTE BOOK) or, shorter, 'BOOK.
If you want to generate the predicate without the quote character, you need to write:
(gen-predicate book)
Alternatively you can also change the macro:
(symb classname '-p)
would be:
(symbol (if (and (consp classname)
(eq (first classname) 'quote))
(second classname)
classname))
Compare
We write
(defun foo () 'bar)
and not
(defun 'foo () 'bar) ; note the quoted FOO
DEFUN is a macro and the first argument is the function name. It's a similar problem then...
Second part of the question
I don't really know any good answer to that. I can't remember any easy way to run code (for example to define a function) after a class definition.
Maybe use the MOP, but that's ugly.
write a custom macro DEFINE-CLASS which does what you want: expands into DEFCLASS and the DEFUN.
iterate over all symbols in a package, find the classes and define the corresponding predicates
To address the second part of the question, classes are themselves objects, thanks to the MOP, so it might be possible to write an :after method on initialize-instance specialized on STANDARD-CLASS. But you should check the MOP to see whether defining such a method is allowed or not.
If it's possible, then yes, you can run code in response to the creation of a class; however, since you don't know the name of the class being created until runtime, you cannot spell it textually in the source, so you cannot use your macro (unless you use eval). You'd rather use something like
(let ((classname (class-name class)))
(compile (generate-my-predicate-symbol classname)
(lambda (x) (typep x classname))))
I think Rainer's suggestion to write your own DEFINE-CLASS macro is the way to go, I mean, the way a seasoned Lisper most likely would do it, if there aren't any other considerations at play. But I'm not really a seasoned Lisper, so I might be wrong ;)
I want to express a grammar rule that is written in BNF using Lisp.
here is the rule. It is important to note that non-terminals are represented in capital letters and the terminals are represented in small letters:
A -> a A b
I tried to use the define function of lisp to define that grammar. However when I use a define function Lisp obliges me to specify the body of the function that I defined.
#lang racket
(define (A a A b B)())
However if I fill the body with whatever like:
#lang racket
(define (A a A b B)("Hello World"))
I don't get any error.
My question here is whether I should specify something in the body that will help me define other rules of the grammar, for example should I specify in the body of A the rule for the non terminal B?
If that define () function is not the right one to use, what other function(s) would help me represent that BNF grammar using Lisp?
Perhaps I'm misunderstanding something here, but it seems to me that you want to represent an EBNF as a piece of data. If this is the case, you could simply use an s-expression.
Something like this, perhaps?
#lang racket
(define my-ebnf
`((A (a A b))
(Q (z z Q z))
(T (A p Q))))
I recommend taking a look at this classic, recursive descent parser:
http://www.cs.indiana.edu/eip/compile/scan-numlist.ss
The example consists of a lexer for a small Scheme subset.
It was used for he the Scheme compiler workshop in 1996.
http://www.cs.indiana.edu/eip/compile/
Are there any practical differences between special forms and macros? In what do they differ?
The terms aren't quite synonymous, but they aren't exclusive either (this answer assumes Scheme):
A special form (also known as a syntax in the Scheme Reports) is an expression that's not evaluated according to the default rule for function application. (The default rule, just to be explicit, is to eval all of the subexpressions, and then apply the result of the first one to the list of the results of the others.)
The macro system is a language feature that allows definition of new special forms within the language itself. A macro is a special form defined using the macro system.
So you could say that "special form" is a term that pertains to interface or semantics, whereas "macro" is a term that pertains to implementation. "Special form" means "these expressions are evaluated with a special rule," while "macro" means "here's an implementation of a special rule for evaluating some expressions."
Now one important thing is that most Scheme special forms can be defined as macros from a really small core of primitives: lambda, if and macros. A minimal Scheme implementation that provides only these can still implement the rest as macros; recent Scheme Reports have made that distinction by referring to such special forms as "library syntax" that can be defined in terms of macros. In practice, however, practical Scheme systems often implement a richer set of forms as primitives.
Semantically speaking, the only thing that matters about an expression is what rule is used to evaluate it, not how that rule is implemented. So in that sense, it's not important whether a special form is implemented as a macro or a primitive. But on the other hand, the implementation details of a Scheme system often "leak," so you may find yourself caring about it...
Lisp has certain language primitives, which make up Lisp forms:
literal data: numbers, strings, structures, ...
function calls, like (sin 2.1) or like ((lambda (a b) (+ a b 2)) 3 4)
special operators used in special forms. These are the primitive built-in language elements. See Special Operators in Common Lisp. These need to be implemented in the interpreter and compiler. Common Lisp provides no way for the developer to introduce new special operators or to provide your own version of these. A code parsing tool will need to understand these special operators; these tools are usually called 'code walkers' in the Lisp community. During the definition of the Common Lisp standard, it was made sure that the number is very small and that all extensions otherwise are done via new functions and new macros.
macros: macros are functions which are transforming source code. The transformation will happen recursively until no macro is left in the source code. Common Lisp has built-in macros and allows the user to write new ones.
So the most important practical difference between special forms and macros is this: special operators are built-in syntax and semantics. They can't be written by the developer. Macros can be written by the developer.
In contrast to special forms, macro forms can be macroexpanded:
CL-USER(1): (macroexpand '(with-slots (x y z)
foo
(format t "~&X = ~A" x)))
(LET ((#:G925 FOO))
(DECLARE (IGNORABLE #:G925))
(DECLARE (SB-PCL::%VARIABLE-REBINDING #:G925 FOO))
#:G925
(SYMBOL-MACROLET ((X (SLOT-VALUE #:G925 'X))
(Y (SLOT-VALUE #:G925 'Y))
(Z (SLOT-VALUE #:G925 'Z)))
(FORMAT T "~&X = ~A" X)))
T
For me the most practical difference has been in the debugger: Macros don't show up in the debugger; instead, the (typically) obscure code from the macro's expansion shows up in the debugger. It is a real pain to debug such code and a good reason to ensure your macros are rock solid before you start relying upon them.
the super short answer for the lazy
You can write your own macroes any time you want, though you can't add special forms without recompiling clojure.
In Scheme, we just had define for all the definition, why does Clojure and Lisp use different keywords for different declarations?
defn, defmacro, defstruct and such are just macros for defining their corresponding structure, making it unnecessary to write boilerplate code. For example, defn makes it easier to write functions since you no longer have to worry about putting in the lambda term (which you can do in Scheme just by bracketing the arguments immediately after the name being defined):
Scheme:
(define hello
(lambda (name)
(display (string-append "hello, " name))))
(define (hello name)
(display (string-append "hello, " name)))
Clojure:
(def hello
(fn [name]
(println (str "hello, " name))))
(defn hello [name]
(println (str "hello, " name)))
You can look at defn as a mnemomic device for def + fn. Such shortcuts make for less boilerplate coding and make the code just easier to read in general. I'm teaching someone how to program Scheme at the moment and I make them use the long forms so that they have in mind at all times what the language is doing (and will appreciate the work-saving macros all the more when they finally start using them).
The define or def forms give a name to some expression that follows. The lambda or fn form gives the name a set of bindings when used within a define or def expression. That's where things start to get more complex and the use of macro forms keeps you sane and protects you from typing boredom.
They define different kinds of objects (functions, special variables, macros, structures, classes, generic functions, methods, packages). In Common Lisp, they also are in different namespaces. Different definition forms also have different syntax (Scheme's define combines variable and function definition. But can it define a class?)
def in Clojure is a special form and it's nice to keep special forms as simple and primitive as possible. defn is a macro that adds sugar for easily setting docstrings and metadata, and (as others have said) removes the need for extraneous parens. defn also automatically sets up some metadata on your function itself (showing arglists etc.) which makes no sense for a general def.
Functions are by far the most common thing you're going to be defining toplevel in Clojure. Toplevel mutable variables are discouraged. So it makes sense to have an easy and fast way to define a toplevel function. Using def for everything would result in a lot of boilerplate. If there was no defn we'd all be reinventing it ourselves to avoid being annoyed to death.