This is a pattern of optimization in Lisp code that I want to achieve in Red:
(defmacro compute-at-compile (x)
`(+ ,(* pi 2) ,x))
(macroexpand '(compute-at-compile 1))
; => (+ 6.283185307179586 1)
How do I express this in Red? (I realize it may not be possible in today's implementation, I'm wondering about how one would express the code at the language level to get such an optimization. Would it require special markup in the source, or would it be automatic like Lisp?)
Trying to extend my answer to maybe cover another idea that may help you find what you are looking for.
Red/System
From my understanding, the Red/System #define directive can help with optimization (in reducing function calls). Here is a similar example in Red/System. Within Red, it would require using within #system or #system-globaldirective.
#define COMPUTE(x) (3.13159 * 2.0 + x)
b: COMPUTE(1.0)
print b
Processing the macro should result in:
b: (3.13159 * 2.0 + 1.0)
print b
and results
7.26318
Math between types isn't defined yet, so you'll run into issues multiplying/adding float! and integer! (hence the above use of float!)
Red/Rebol
You can also take a look at compose as a higher level way to optimize your code writing. I am unsure of the effect in terms of optimizing speed. What compose does is take a block and evaluate whatever is in parenthesis and not evaluate other elements in the block.
See the Rebol2 help definition for compose
>> help compose
USAGE:
COMPOSE value /deep /only
DESCRIPTION:
Evaluates a block of expressions, only evaluating parens, and returns a block.
COMPOSE is a native value.
ARGUMENTS:
value -- Block to compose (Type: any)
REFINEMENTS:
/deep -- Compose nested blocks
/only -- Inserts a block value as a block
This may be what you're looking for in terms of building expressions
red>> x: 1
== 1
red>> compose [3 + 2 + (x)]
== [3 + 2 + 1]
An example from the Rebol2 documentation:
>> probe compose [time: (now/time) date: (now/date)]
[time: 12:48:53 date: 5-Mar-2014]
== [time: 12:48:53 date: 5-Mar-2014]
Related
We should use square brackets when flattering all levels in list:
q)b:(1 2;(3 4;5 6);7;8)
q)raze/[b] / flatten all levels
1 2 3 4 5 6 7 8
q)raze/b
'/
[0] raze/b
But why one forced to use raze/[b] for Converge syntax instead of simple raze/b?
Upd
Why this syntax works in k, for example {x+y}/1 2 3 but doesn't work in q?
My assumption that it's been made to prevent qbies errors when using / adverb instead of %. I think there may be a discussion about it in some dev channel, but I've found only Shakti discussion group for now at https://groups.google.com/forum/#!forum/shaktidb, and kx.com also shutted down community wiki, so I don't know where to find an additional info - asking here
Upd2
The / is quite overloaded in k too: see (not official ref though) https://github.com/JohnEarnest/ok/blob/gh-pages/docs/Manual.md#over - over, fixedpoint, for and while. Pretty the same as in q, right? But why the interpreter 'ban' the k syntax in q context, - is there a technical reason why q can't recognise a user intention as it k does?
The reason that, say, cos/1 works in k but not q is that q has no ambivalence. That is to say that all q operators are not overloaded on valence, as noted in section 6.1.2 in q4m.
With any of q's adverbs (each:', over:/ scan:\, prior::, eachright:/:, eachleft:\:) the resulting derivative function is interpreted by q to be dyadic, unless you uses []'s to specifically pass one argument.
For the example above q interprets cos/ as do rather than converge and so requires the left argument specifying the number of iterations (Note the results of 0 cos/ 1, 1 cos/ 1, 2 cos/ 1, etc.). The preferred way to resolve is to use []'s: cos/[1].
(cos/) 1 works because user defined functions can never use infix notation, so the expression is automatically interpreted as applying monadically. This is also why 2 (cos/) 1 fails. To resolve this you would again have to use []'s: (cos/)[2;1].
You don't necessarily need square brackets here. You could use
(raze/)b
if you do not want to use square brackets around b. The way you are using over ( or /) without the brackets around b requires the parenthesis around raze/b if you do not specify the initial value of the accumulator. This is because the q interpreter needs to know that you are applying raze/ to the list b rather than applying / to the list first (which is why a '/ error is thrown) then raze after (reading the code from right to left).
More info on using / can be found here: https://code.kx.com/q4m3/6_Functions/#676-over-for-accumulation
Some LISP expressions evaluate to themselves (examples are MIT-Scheme REPL, though GNU Common Lisp agrees):
1 ]=> 3
;Value: 3
And are in normal form. Evaluation of an expression (such as (+ 2 1)) thus can properly be said to be conversion to normal form. That's nice, because that's how I've always understood evaluation formally.
But with lists we're in trouble:
1 ]=> (list 3 2)
; Value 16: (3 2)
1 ]=> (3 2)
;The object 3 is not applicable.
;To continue, call RESTART with an option number:
; (RESTART 2) => Specify a procedure to use in its place.
; (RESTART 1) => Return to read-eval-print level 1.
Am I right in thinking that:
(many[0]) LISPs don't have normal forms for (non-empty) lists, and
(many) LISPs do not have the property that evaluation is reduction to normal form?
If so, isn't this somewhat at odds with formalisms in PLT such as abstract rewriting systems? What alternative formalisms do capture evaluation in LISPs?
[0] Or perhaps more accurately, "most of the prominent LISPs", such as CL, Clojure, and Scheme. But I'd be interested in less well-known counter-examples!
Lisp can be defined in terms of only a few primitive operators. How many primitives does it take to build a LISP machine? Ten, seven or five? So you could consider there to be a normal form for what you get from expanding to them.
But Lisp isn't the lambda calculus. What type of lambda calculus would Lisp loosely be an example of?
And Lisp wasn't designed to be like the lambda calculus:
To use functions as arguments, one needs a notation for functions, and it seems natural to use the lambda-notation of Church. I didn’t understand the rest of the book, so I wasn’t tempted to try to implement his more general mechanism for defining functions.
-- History of Lisp, Stanford AI Laboratory memo 1979 by J. McCarthy, page 6
I am interested in extending the syntax in emacs-lisp, but I have not found any hints anywhere about the feasibility of this or how to achieve it. I want to try some things that are illustrated here, so that in Emacs, for example, I could type {1 + 2 + 3} and have it interpreted in a program as (+ 1 2 3). I am familiar with some projects to use syntax like ($ 1 + 2 + 3) for this purpose, but I want to try modifying the syntax, not create a new infix function like that.
I did find some documentation on changing syntax tables, but this seems to be more for the editor, and not the lisp parser.
Any pointers?
Emacs reader is not as flexible as that of Common Lisp, so you cannot make it read {a + b + c} as (+ a b c).
Moreover, the experience has shown that doing so is a waste of time: no one ever writes Lisp like that; projects like "readable" you quoted remain a curious demonstration of CL's power rather than something actually usable.
I'd like to change the syntax of the following expression:
(> 2 1)
to something like:
(2 greater 1)
My first try is the following macro:
(define-syntax greater
(lambda (x)
(syntax-case x (greater)
[(a greater b)
(syntax (> a b))])))
Using this macro fails with: "bad syntax in: greater"
I've been surfing some Scheme docs, but I was not able to find the way to do it.
In Racket, there already exists a reader feature to allow for general infix notation: write a dot before and after the function or macro name: (2 . > . 1) It's a little verbose (the dots have to be surrounded by spaces), but I like it and use it a lot. See the documentation for more information.
The expression (2 greater 1) is an application. It expands to (#%app 2 greater 1). You must define your own version of #%app and call it, say, my-%app. If greater is present swap the first and second argument, otherwise just expand to the standard #%app.
To use your new application you must export it from the file (module) in which you define it, and then import it in the module where your want your special application syntax.
You might that the "curly-infix" notation is what you want. Just surround a list with {...}, and you can write the list contents in infix order instead of prefix order (the reader transforms it). So if you write {x + ,y} the reader maps it to (+ x ,y).
Curly-infix is defined in SRFI-105: http://srfi.schemers.org/srfi-105/
I know that the current version of GNU guile, at least, implements it.
The "sweet-expression" notation of SRFI-110 ( http://srfi.schemers.org/srfi-110/ ) builds on top of SRFI-105.
There are languages other than Lisp (ruby, scala) that say they use REPL (Read, Eval, Print, Loop), but it is unclear whether what is meant by REPL is the same as in Lisp. How is Lisp REPL different from non-Lisp REPL?
The idea of a REPL comes from the Lisp community. There are other forms of textual interactive interfaces, for example the command line interface. Some textual interfaces also allow a subset of some kind of programming language to be executed.
REPL stands for READ EVAL PRINT LOOP: (loop (print (eval (read)))).
Each of the four above functions are primitive Lisp functions.
In Lisp the REPL is not a command line interpreter (CLI). READ does not read commands and the REPL does not execute commands. READ reads input data in s-expression format and converts it to internal data. Thus the READ function can read all kinds of s-expressions - not just Lisp code.
READ reads a s-expression. This is a data-format that also supports encoding source code. READ returns Lisp data.
EVAL takes Lisp source code in the form of Lisp data and evaluates it. Side effects can happen and EVAL returns one or more values. How EVAL is implemented, with an interpreter or a compiler, is not defined. Implementations use different strategies.
PRINT takes Lisp data and prints it to the output stream as s-expressions.
LOOP just loops around this. In real-life a REPL is more complicated and includes error handling and sub-loops, so-called break loops. In case of an error one gets just another REPL, with added debug commands, in the context of the error. The value produced in one iteration also can be reused as input for the next evaluation.
Since Lisp is both using code-as-data and functional elements, there are slight differences to other programming languages.
Languages that are similar, those will provide also similar interactive interfaces. Smalltalk for example also allows interactive execution, but it does not use a data-format for I/O like Lisp does. Same for any Ruby/Python/... interactive interface.
Question:
So how significant is the original idea of READing EXPRESSIONS, EVALuating them and PRINTing their values? Is that important in relation to what other languages do: reading text, parsing it, executing it, optionally print something and optionally printing a return value? Often the return value is not really used.
So there are two possible answers:
a Lisp REPL is different to most other textual interactive interfaces, because it is based on the idea of data I/O of s-expressions and evaluating these.
a REPL is a general term describing textual interactive interfaces to programming language implementations or subsets of those.
REPLs in Lisp
In real implementations Lisp REPLs have a complex implementation and provide a lot of services, up to clickable presentations (Symbolics, CLIM, SLIME) of input and output objects. Advanced REPL implementations are for example available in SLIME (a popular Emacs-based IDE for Common Lisp), McCLIM, LispWorks and Allegro CL.
Example for a Lisp REPL interaction:
a list of products and prices:
CL-USER 1 > (setf *products* '((shoe (100 euro))
(shirt (20 euro))
(cap (10 euro))))
((SHOE (100 EURO)) (SHIRT (20 EURO)) (CAP (10 EURO)))
an order, a list of product and amount:
CL-USER 2 > '((3 shoe) (4 cap))
((3 SHOE) (4 CAP))
The price for the order, * is a variable containing the last REPL value. It does not contain this value as a string, but the real actual data.
CL-USER 3 > (loop for (n product) in *
sum (* n (first (second (find product *products*
:key 'first)))))
340
But you can also compute Lisp code:
Let's take a function which adds the squares of its two args:
CL-USER 4 > '(defun foo (a b) (+ (* a a) (* b b)))
(DEFUN FOO (A B) (+ (* A A) (* B B)))
The fourth element is just the arithmetic expression. * refers to the last value:
CL-USER 5 > (fourth *)
(+ (* A A) (* B B))
Now we add some code around it to bind the variables a and b to some numbers. We are using the Lisp function LIST to create a new list.
CL-USER 6 > (list 'let '((a 12) (b 10)) *)
(LET ((A 12) (B 10)) (+ (* A A) (* B B)))
Then we evaluate the above expression. Again, * refers to the last value.
CL-USER 7 > (eval *)
244
There are several variables which are updated with each REPL interaction. Examples are *, ** and *** for the previous values. There is also + for the previous input. These variables have as values not strings, but data objects. + will contain the last result of the read operation of the REPL. Example:
What is the value of the variable *print-length*?
CL-USER 8 > *print-length*
NIL
Let's see how a list gets read and printed:
CL-USER 9 > '(1 2 3 4 5)
(1 2 3 4 5)
Now let's set the above symbol *print-length* to 3. ++ refers to the second previous input read, as data. SET sets a symbols value.
CL-USER 10 > (set ++ 3)
3
Then above list prints differently. ** refers to the second previous result - data, not text.
CL-USER 11 > **
(1 2 3 ...)
Seeing as the concept of a REPL is to just Read, Eval, Print & Loop it's not too suprising that there are REPLs for many languages:
C/C++
C#/LINQ
Erlang
Haskell (on windows)
Java
Javascript
Julia
Perl
Python
Ruby
Scala
Smalltalk -- I learned it on a REPL!
I think it is interesting to compare two approaches. A bare bones REPL loop in a Lisp system would look like this:
(loop (print (eval (read))))
Here are two actual Forth implementations of a REPL loop. I'm leaving nothing out here -- this is the full code to these loops.
: DO-QUIT ( -- ) ( R: i*x -- )
EMPTYR
0 >IN CELL+ ! \ set SOURCE-ID to 0
POSTPONE [
BEGIN \ The loop starts here
REFILL \ READ from standard input
WHILE
INTERPRET \ EVALUATE what was read
STATE # 0= IF ." OK" THEN \ PRINT
CR
REPEAT
;
: quit
sp0 # 'tib !
blk off
[compile] [
begin
rp0 # rp!
status
query \ READ
run \ EVALUATE
state # not
if ." ok" then \ PRINT
again \ LOOP
;
Lisp and Forth do completely different things, particularly in the EVAL part, but also in the PRINT part. Yet, they share the fact that a program in both languages is run by feeding its source code to their respective loops, and in both cases code is just data (though in Forth case it is more like data is also code).
I suspect what anyone saying only LISP has a REPL is that the READ loop reads DATA, which is parsed by EVAL, and a program is created because CODE is also DATA. This distinction is interesting in many respects about the difference between Lisp and other languages, but as far as REPL goes, it doesn't matter at all.
Let's consider this from the outside:
READ -- returns input from stdin
EVAL -- process said input as an expression in the language
PRINT -- print EVAL's result
LOOP -- go back to READ
Without going into implementation details, one can't distinguish a Lisp REPL from, for example, a Ruby REPL. As functions, they are the same.
I guess you could say that Scala's "REPL" is an "RCRPL": Read, Compile, Run, Print. But since the compiler is kept "hot" in memory, it's pretty fast for ongoing interactions--it just takes a few seconds to start up.
There are a number of people that consider a REPL to needs to behave exactly like it does in LISP, or it's not a true REPL. Rather, they consider it something different, like a CLI (command line interpreter). Honestly, I tend to think that if it follows the basic flow of:
read input from the user
evaluate that input
print the output
loop back to the read
then it's a REPL. As noted, there are a lot of languages that have the above capability.
See this reddit thread for an example of such a discussion.
How is Lisp REPL different from non-Lisp REPL?
Let's compare Common Lisp's REPL with Python's IPython.
The main two points are:
Lisp is an image-based language. There is no need to restart the process/the REPL/the whole app after a change. We compile our code function by function (with compiler warnings etc).
we don't loose state. Even more, when we update class definitions, our objects in the REPL are also updated, following rules we have control upon. That way we can hot-reload code in a running system.
In Python, typically, you start IPython or you are dropped into ipdb. You define some data until you try out your new function. You edit your source, and you want to try again, so you quit IPython and you start the whole process again. In Lisp (Common Lisp mainly), not at all, it's all more interactive.
There's a nice project called multi-repl which exposes various REPLs via Node.JS:
https://github.com/evilhackerdude/multi-repl
If you look at the list of supported languages, it's quite clear that not only Lisp has the concept of a REPL.
clj (clojure)
ghci (ghc)
ipython
irb (ruby)
js (spidermonkey)
node
python
sbcl
v8
In fact implementing a trivial one in Ruby is fairly easy:
repl = -> prompt { print prompt; puts(" => %s" % eval(gets.chomp!)) }
loop { repl[">> "] }