For example, It seems that 1+2 can be used in Guile as a variable name:
(define 1+2 4)
1+2 ;==>4
I was surprised to find that R6RS appears not to like identifiers whose names start with a digit (unless they are escaped, perhaps?), if I am reading it properly. It looks as if the same is true for R5RS. I have not looked at other specifications.
So, if my readings of the specs are correct, then yes, Guile is relaxing this requirement. However, as I say, I was surprised by this, as, for instance, Racket is perfectly happy with identifiers like 1+, even when using the r5rs language, and such identifiers are very common in other Lisp-family languages (Common Lisp defines 1+ and 1- in the language itself).
It may however be the case that I am misreading the syntax for <identifier> in the specs, or misinterpreting what they mean.
Related
Common Lisp provides the lovely ~r directive for printing cardinal English numbers. For example:
(format nil "~r" 27) -> "twenty-seven"
Does lisp provide a directive (or some library function) that does the reverse, from cardinal English numbers to integer values? I'm using Allegro CL on a Windows machine.
EDIT: I'm looking for this type of functionality in a cleaner fashion:
(defconstant +cardinal-number-map+
(loop for number from 0 to 100
collect (cons (format nil "~r" number) number)))
(defun cardinal->int (cardinal)
(cdr (assoc cardinal +cardinal-number-map+ :test #'string-equal)))
Does lisp provide a directive (or some library function) that does the
reverse, from cardinal English numbers to integer values?
The short answer is "no". You can read in different radices, but not the English text. That said, doing this type of reading is a common enough exercise that you can find code out there that will do it. For instance, on the Code Golf site, there's a question, Convert English to a number. I don't see any Lisp solutions there, but there are some short answers that could be translated without too much trouble. (The Javascript answer is short and might be a nice candidate.)
However, because format's output isn't specified precisely, there's not going to be a simple and portable solution that will work with every implementation's format output. For that, you might have to do something like what you suggested in the question.
I need to export to a file a Prolog program expressed using an arbitrary term representation in Java. The idea is that a Prolog interpreter should be able to consult the generated file afterwards.
My question is about the correct way to write in the file Java Strings representing atom terms.
For example, if the string has a space in the middle, it should be surrounded by single quotes in the file:
hello world becomes 'hello world'
And the exporter should take into consideration characters that should be escaped:
' becomes '\''
Could someone point me to the place were these rules are specified?, and: Can I assume that these rules are respected by major Prolog implementors? (I mean, a Prolog program generated following these rules would be correctly parsed by most Prolog interpreters?).
The precise place for this is the standard, ISO/IEC 13211-1:1995, quoted_token (* 6.4.2 *). See this answer how to get it for USD 30.
The precise syntax is quite complex due to a lot of extras like continuation lines and the like. If you are only writing atoms that should be read by Prolog, things are a bit easier. Also in that situation, you could always quote, which makes writing again a bit simpler.
Some things to be aware of:
Only simple spaces may occur as layout in a quoted atom. All other spaces need to be escaped like \t, \n (abrftnv). Many systems accept also other layout but they differ to each other in very tiny details.
Backslash and quote must be escaped.
Characters outside the printable ASCII range depend on the PCS supported by a system. In a conforming system, the accompanying documentation should define how the additional characters (extended characters) are classified. Documentation quality varies on a wide range.
In any case, test your interface also with GNU-Prolog from 1.4.1 upwards. To date, no differences are known between GNU 1.4.1+ and the standard as far as syntax is concerned.
Here are some 240+ syntax related test cases. Please report any oversight!
A practical hint: if you issue a writeq with your Prolog, with data you need to know about, you'll get quotes around when required.
This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
What does # mean in LISP
I am learning lisp, but one thing I do not understand is why it is necessary for #' to be used. If a function with a specific name exists, why would lisp think its a variable?
Ex:
>(remove-if-not #'evenp '(1 2 3 4 5 6 7 8 9 10))
(2 4 6 8 10)
Some lisps, like Common Lisp, require this. Others, like Scheme, do not.
You need to do this because the Lisp you're using has a separate namespace for functions versus "normal" variables. If you left out the #' then the symbol evenp would be interpreted as referring to the "normal" (non-function) namespace.
The read syntax
#'X
means exactly the same thing as
(FUNCTION X)
(FUNCTION X) means, roughly, "resolve the symbol X in the namespace of functions". Without this, X is evaluated as a variable. Functions and variables are in separate namespaces in Common Lisp. This is a rule.
As to the question, why would Lisp think it is a variable? Let's put it another way: given that there are two namespaces, why can't Lisp just fall back automatically on one or the other if there is no ambiguity? The reason is that that would be a hack compared to just Lisp-1 or Lisp-2, worse than either of them. Lisp-1 and Lisp-2 are words used in the Lisp culture to refer to dialects that have one a single namespace for variables and those that have two.
If you want to know more about the pros and cons of doing it one way or another, it's all in this paper by Kent Pitman and Richard Gabriel: http://www.nhplace.com/kent/Papers/Technical-Issues.html [Technical Issues of Separation in Function Cells and Value Cell].
As an aside: you can use 'FUNC or (QUOTE FUNC) instead: (remove-if-not 'evenp ...). This is a very late binding mechanism that goes through the symbol, and will not work for lexical functions. It probably won't compile very efficiently. Calling through 'FUNC always has to do a lookup through the symbol, whereas #'FUNC (at least in some important situations) can be optimized.
I'm relatively new to scheme and am having a hard time finding a concrete document online overviewing the major changes that happened with R6RS. Anyone care to elaborate?
http://community.schemewiki.org/?R6RS has compiled a list of high level changes with some commentary, including:
case sensitive syntax
square brackets are now equivalent to parentheses (e.g., (let ([foo 3]) ...) - this was supported in some scheme implementations but is now part of the standard
retaining the ability to return multiple values
more escape characters in strings, e.g., "\n"
hashtables as a library
multiline and expression comments
http://www.r6rs.org/versions/CHANGES
http://www.r6rs.org/formal-comments/
http://lambda-the-ultimate.org/node/1342
If you're relatively new to scheme and have the fortitude you will get more mileage reading the spec instead of skimming a changelog though...
How does the Scheme procedure inexact->exact, described in SICP, operate?
The Scheme standard only gives some general constraints on how exactness/inexactness is recorded, but most Scheme implementations, up to standard R5RS, operate as follows (MIT Scheme, which is SICP's "mother tongue", also works this way):
The type information for each cell that contains data of a numeric type says whether the data is exact or inexact.
Arithmetic operations on the data record derive the exactness of the result from the exactness of the inputs, where generally inexactness is infectious: if any of the operands is inexact, the result probably will be so too. Note, though, Scheme implementations are allowed to infer exactness in special cases, say if you multiply inexact 4.3 by exact 0, you can know the result is 0 exactly.
The special operations inexact->exact and exact->inexact are casts on the numeric types, ensuring that the resulting type is exact or inexact respectively.
Some points: first, different scheme standards vary in when operators give exactness or not; the standards underdetermine what happens. For example, several Scheme implementations have representations for exact rationals, allowing (/ 1 3) to be represented exactly, where a Scheme implementation with only floats must represent this inexactly.
Second, R6RS has a different notion of contagion from that of SICP and earlier standards, because the older criterion is, frankly, broken.
Exactness is simply a property of a number: it doesn't change the value of the number itself. So, for an implementation that uses a flag to indicate exactness, inexact->exact simply sets the exactness flag on that number.