Open yossigil opened 2 years ago
@gur111 @orel-adivi: what do you think?
Hi,
For dealing with the questions, I have run some test cases on the SBCL (Steel Bank Common Lisp) interpreter and have checked the way that Scheme deals with these issues.
I think that since Mini-Lisp dialect is meant for an academic-educational purpose, it has to be based on some widespread dialects of Lisp, simplifying them but not creating a new, independent dialect with new features. Therefore, Scheme (the language in which the "Intro to CS" in Tel-Aviv University was taught till 2012) and Common Lisp (which is closer to Mini-Lisp) fit for that purpose.
Regarding the issues:
LAMBDA
keyword and NLAMBDA
keyword: SBCL does not differentiate between the keywords (as I understand, it is normal by default), and Scheme uses a totally different mechanism, using delay
and force
keywords. Especially, I did not find a dialect that uses the NLAMBDA
keyword - is it based on a specific dialect? Additionally, why to differentiate between these two keywords, and not merging them (normal by default)? Evaluation order should not affect the result in Lambda-Calculus, regarding the evaluations in all evaluation orders have halted.NLAMBDA
keyword: I think that LAMBDA"
is unclear (adding quotes does not indicate what it does), and that LAMBDAN
is less clear than NLAMBDA
(since it stands for "normal lambda", due to word order in English; or maybe LAMBDAN
is better since it represents similar functionality of LAMBDA
, kind of subtyping (?)).I would like to read your opinion about what I wrote; maybe there are things I did not think about.
Well, I am not sure at all. The attempt is not to make a “programming language”, but rather a simple “case study”. there is no point in supporting anything except what is essential to the course. Punctuations are currently allowed in atoms, and so they should be. This makes it possible to define a function such as as(>1 X)
which returns t iff the x is a list of length 1 or more.
This is also important for educational purposes. Punctuations are just like any other character, and the only punctuation I borrowed is of the essential quote and comment.
As to LAMBDA - the name will stay. It is part of the theory of lambda expressions.
NLAMBDA is different. It was found in archaic versions of LISP. Now, it more or less MACRO. It is short of NORMAL lambda, a lambda expression with normal evaluation order.
I think the name LAMBDA”
will make it clearer. It is possible to change he grammar a bit, so that identifiers containing quotes are recognised, then we can write LAMBDA’
. The name is to say that the evaluation of the arguments is not done. The arguments are sort of quoted.
Hi,
I think that I understand better what you meant to after reading your comment. I think that we both agree that the dialect is a simplified version of Lisp, meant to demonstrate the basic features of functional programming, Lisp, lambda functions, pattern matching (cond/if expressions), and so on. Despite it should not be an independent, full programming language, I think it is important to create a dialect that takes the keywords and features from dialects in common use.
Regarding the punctuation issue - I agree with you that punctuations should be fully allowed (even despite it is not allowed in Common Lisp), it does make the language clearer and more useful for its educational purposes.
Regarding the existence of NLAMBDA
keyword - I am not sure that the distinction between LAMBDA
and NLAMBDA
has a benefit for the dialect's educational purpose. Should the change of the evaluation order affect the result of the evaluation (especially in a functional language, with no side-effects for its functions)? Defining (define NLAMBDA (a b) (LAMBDA a b))
should affect any code? It worths noticing that (as I understand) Mini-Lisp does not support throwing of exceptions, both by the user (Common Lisp supports it) and by faulty calculations (division by zero is not a problem when there are no numbers).
Regarding the name of NLAMBDA
keyword - I think that NLAMBDA
is better than MACRO
since it demonstrates to the students the difference between the functionality of this keyword and of LAMBDA
keyword. About LAMBDA”
and LAMBDA’
- I think they are less clear than NLAMBDA
since they indicate an order or a kind of grading system, not referring equally to LAMBDA
and to them. About LAMBDAN
- I am not sure which one is better.
I hope that now my opinion is clearer, and I would like to read your opinion about the new issues.
In PL we teach the difference between normal and eager evaluation. Eager evaluation is easy, since this is the common parameter passing method. Normal is challenging since it is not present in mainstream languages, yet is very important.
An ancient version of LISP used the term NDEFUN and NLAMBDA, but these were changed over the years to macros in LISP. The term macro is confusing since it reminds students of macros in C. The two kinds of macros are similar, but different enough to create confusion. This is the reason the term macro is not used in mini-lisp.
The semantics of normal order evaluation is a bit similar to quotation. In normal functions, the arguments are not evaluated prior to calling the function. To make this clear the suggestion it that eager functions are denoted by LAMBDA and DEFUN as in CL, and that normal functions are denoted by LAMBDA' and DEFUN'.
OK, I see. Thanks for the explanations!
Mini-LISP allows atoms that contain punctuation. The name
LAMBDA"
seems to be more "meaningful".Likewise, change the name "NLAMBDA" to "LAMBDAN" in the implementations?
Change the name 'NDEFUN' to 'DEFMAC', the definition of a macro as in lisp?