Evolution of Software Languages 1 Evolution of Software Languages Theo D'Hondt Bachelor of Computer Science Faculty of Sciences and Bio-Engineering Sciences Vrije Universiteit Brussel Academic Year 2015-2016 Section 10: LISP to Scheme 10: LISP to Scheme
46
Embed
Section 10 - LISP to Scheme - Vrije Universiteit Brusselsoft.vub.ac.be/~tjdhondt/ESL/LISP_to_Scheme_files/Section 10 - LISP...Section 10: LISP to Scheme 10: LISP to Scheme. Evolution
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Evolution of Software Languages 1
Evolution of
Software Languages
Theo D'Hondt
Bachelor of Computer Science Faculty of Sciences and Bio-Engineering Sciences
Vrije Universiteit Brussel Academic Year 2015-2016
(defun draw-world () (loop for y below *height* do (progn (fresh-line) (princ "|") (loop for x below *width* do (princ (cond ((some (lambda (animal) (and (= (animal-x animal) x) (= (animal-y animal) y))) *animals*) #\M) ((gethash (cons x y) *plants*) #\*) (t #\space)))) (princ "|"))))
Evolution of Software Languages 13
LISP example5
10: LISP to Scheme
(defun evolution () (draw-world) (fresh-line) (let ((str (read-line))) (cond ((equal str "quit") ()) (t (let ((x (parse-integer str :junk-allowed t))) (if x (loop for i below x do (update-world) if (zerop (mod i 1000)) do (princ #\.)) (update-world)) (evolution))))))
(define fact (NEW Factorial)) (SEND (NEW User fact) doit 10) (SEND (NEW User fact) doit 4)
Evolution of Software Languages 26
The Actor Model5
10: LISP to Scheme
(define Fibonacci (BEHAVIOR (first second) (METHOD (fib customer number) (BECOME Fibonacci first second) (cond ((= number 0) (SEND customer result first)) ((= number 1) (SEND customer result second)) (else (let ((x (NEW FibCust customer))) (SEND SELF fib x (- number 1)) (SEND SELF fib x (- number 2))))))))
(define fib (NEW Fibonacci 1 1)) (SEND (NEW User fib) doit 6) (SEND (NEW User fib) doit 4)
Evolution of Software Languages 27
The Actor Model6
10: LISP to Scheme
• Very high-level view on concurrency • Most famous offshoot: Erlang • Basis for process calculi • Imperative (see BECOME) • Asynchronous • No (evident) global state • Inherently concurrent • (Unbounded) non deterministic
• Researchers at MIT • Built "Scheme" ←Common Lisp →SICP →PhD with Seymour
Papert ←PhD with →
Evolution of Software Languages 29
The case of Scheme
10: LISP to Scheme
from AIM-848
Evolution of Software Languages 30
Scheme and Actors
10: LISP to Scheme
Sussman and Steele December 22 1875 48 leeentatlon of the in ter r e t e r
Acknowledgements
This work developed out of an initial attempt to understand the .
This paper would not have happened if Sussman had not been forced tothink about lambda calculus by having to teach 6,031, nor would it havehappened had not Steele been forced to understand PLASNA by morbid curiosity.
actorness of actors. Steele thought he understood it, but couldn't explainit; Sussman suggested the experimental approach of actually building an"ACTORS interpreter". This interpreter attempted to intermix the use ofactors and LISP lambda expressions in a clean manner. When it was completed,we discovered that the "actors" and the lambda expressions were identical inimplementation. Once we had discovered this, all the rest fell into place,and it was only natural to begin thinking about actors in terms of lambdacalculus. The original interpreter was call-by-name for various reasonshaving to do with 6.031; we subsequently experimentally discovered how call-by-name screws iteration, and rewrote it to use call-by-value. Note well that,we did not bring forth a clean implementation in one brilliant flash ofunderstanding; we used an experimental and highly empirical approach tobootstrap our knowledge.
precipitating this intellectual adventure. Carl Hewitt spent many hoursexplaining the innards and outards of PLASI'IA to Steele over the course ofseveral months; Narilyn McClennan was also helpf'ul in this respect. BrianSmith and Richard Zippel helped a lot. We wish to thank Seymour Papert, BenKuipers, Narvin Ninsky, and Vaughn Pratt for their excellent suggestions.
We wish to thank the staff of 6.031, Nike Dertouzos, and Steve Ward, for
from AIM-349
Evolution of Software Languages 31
A timeline for Scheme1
10: LISP to Scheme
43pp
35pp
76pp
Evolution of Software Languages 32
A timeline for Scheme2
10: LISP to Scheme
2007
DRAFT
1991
1986
1998
+ IEEE Standard 1178-1990
43pp
55pp
90pp
50pp
88pp
Evolution of Software Languages 33
Semantics for Scheme1
10: LISP to Scheme
AIM-349
AIM-848 (RRRS)
AIM-452
R3RS
R4RS
R5RS
R6RS
R7RS
informal lambda-calculus substitution semantics
⤑
⤑
⤑
⤑
⤑
⤑
⤑
⤑
informal
... a formal definition of the semantics of Scheme will be included in a separate report ...
denotational semantics + rewrite rules
denotational semantics + rewrite rules + macros (added support for immutables)
denotational semantics + syntactic forms
operational semantics
denotational semantics + syntactic forms (added support for dynamic-wind)
Evolution of Software Languages 34
Semantics for Scheme2
10: LISP to Scheme
Pa
ge
33
fro
m R
3R
S
Evolution of Software Languages 35
e.g. argument evaluation
10: LISP to Scheme
I
value when considered as an identifier.
. may be lexically bound by lambda-expressions. There is a global environmentcontai.ning values for (some} free variables. Nany of the variables in thisglobal environment initially have as their values primitive operations suchas, for example, cAR, coMs, and pLUs. SCHENE dif'fers from most LISP systems int hat t h e atom cat iS not itself an operation (in the sense of b e i n g a ninvocable object, e.g. a valid first argument to AvvLY), but only has one as a
Non-atomic forms are divided by the evaluator into two classes:combinations and "magic (special) forms". T he BNF given above i s ambiguous;any magic form c an also be p a r se d a s a combination. The e valuator a l w a y st reats an ambiguous case 'as a magic form. Nagic forms are recognized by thepresence of a "magic (reserved) word" in the car position of the form. Allnon-atomic forms which are not magic forms are considered to be combinations.The system has a small initial set of magic words; there is also a mechanismfor creating new ones (Note FUMCALL is a Pain).
are all evaluated. The first value must be a procedure; it is applied to theother values to get the value of the combination. There are four importantp oints he re :
(I) T he procedure p o s i t i o n is always evaluated just l ike an y o t he rposit ion . (This is why the primitive operators are . the v a l u e s o f globa lidentifiers.)
( <) The procedure is never " re -evaluated"; if the first subfoi m fails toe valuate t o an applicable procedure, it is an error . Thu s , u n l i k e mostLISP systems, SCHENE always evaluates the first subform of a combinationexactly once .
(3) The arguments are all completely evaluated before the procedure isapplied; that is, SCHENE, like most LISP systems, is an applicative-orderlanguage. Nany SCHENE programs exploit this fact.
(4) The argument forms (and procedure f'orm) may in principle be evaluatedi n any o r d e r . This is unlike the usual LISP left-to-right order . (AllSCHEI'lE interpreters implemented so far have in fact performed left-to-rightevaluation, but we do not wish programs to depend on this fact. Indeed,the~e are some reasons why a clever interpreter might want to evaluate themright-to-left, e.g. to get things on a stack in the correct order.}
A combination is considered to be a list of subforms. These subforms
AIM-452
AIM-848
The Revised Revised Report on Scheme
(operator operandf . . . ) essential special formA list whose first element is not the keyword of a special form indicates a
procedure eall. The operator and operand expressions are evaluated and the
resulting procedure is passed the resulting arguments. In contrast to otherdialects of Lisp the order of evaluation is not specified, and the operatorexpression and the operand expressions are always evaluated with the same
evaluation rules.
(+ 3 4)( (11.' 0!false + +) 3 4 )
(quote datum) essential special formdatum essential special form
Evaluates to datum. This notation is used to include literal constants inScheme code.
(quote a)(quote 0(a b c ) )(quote (+ 1 2 ) )
a.4(a b c)(+ 1 2)
(quote datum) may be abbreviated as 'datum. The two notations are equiv-alent in all respects.
'a'4(a b c)'(+ 1 2)'(quote a)
C(a b c)(+ 1 2)(quote a)(quote a)
Numeric constants, string constants, character constants, vect;or constants,and the constants 0! t rue , 0 ! f a l s e , and 0 ! nu l l n e e d no t be qu o t ed .
> IIgb(. IIII abC'146932146932'0!truet !t rue
II gb( II
II gb(. II
1459321469320!true0!true
(lambda (earl .. .) ezpr) essential special formEach ear must be an identifier. The lambda expression evaluates to a pro-
cedure with formal argument list (uar1 ... ) and procedure body ezpr Th e .environment in effect when the lambda expression was evaluated is rernem-bered as part of the procedure. When the procedure is later called with some
The order of evaluation within a call is unspecified. We mimic that here by applying arbitrary permutations permute and unpermute, which must be inverses, to the arguments in a call before and after they are evaluated. This {still requires | is not quite right since it suggests, incorrectly, } that the order of evaluation is constant throughout a program (for any given number of arguments), but it is a closer approximation to the intended semantics than a left-to-right evaluation would be.
Evolution of Software Languages 36
Glitches1
10: LISP to Scheme
Welcome to DrScheme, version 372 [3m]. Language: Standard (R5RS) custom. > (define (f) '(1 . 2)) > (define z (f)) > (set-car! z 3) > z (cons 3 2) > (f) (cons 3 2) >
Evolution of Software Languages37
Glitches2
10: LISP to Scheme
Welcome to DrScheme, version 372 [3m]. Language: Standard (R5RS) custom. > (define (f) (define x 1) (define y x) y) > (f) 1
Evolution of Software Languages38
Glitches2
10: LISP to Scheme
Welcome to DrScheme, version 372 [3m]. Language: Standard (R5RS) custom. > (define (f) (define x 1) (define y x) y) > (f) 1
Welcome to DrScheme, version 6.0 [3m]. Language: Standard (R5RS) custom. > (define (f) (define x 1) (define y x) y) > (f) #<undefined>
Evolution of Software Languages39
Glitches2
10: LISP to Scheme
Welcome to DrScheme, version 372 [3m]. Language: Standard (R5RS) custom. > (define (f) (define x 1) (define y x) y) > (f) 1
Welcome to DrScheme, version 6.0 [3m]. Language: Standard (R5RS) custom. > (define (f) (define x 1) (define y x) y) > (f) #<undefined>
Welcome to DrScheme, version 6.0 [3m]. Language: Standard (R5RS) custom. > (define (f) (define x 1) (define y x) y) > (f) 1