Earlier quoted context omitted.
It's not something we ever really think about. That list of closing parentheses just signals termination of the top-level S-expression. And there's virtually nobody coding in a Lisp that doesn't use a structural editing mode (like Paredit or SmartParens). E.g., any time you type "(", you get "()", enforcing balance. What we rely on is proper indentation to indicate the important groupings.
Exactly. IMHO, this is quite similar to Python indentation rules, except it is up to writers of Lisp code to be disciplined enough to maintain the proper indentation.
Not Lisp again (2009)
251–260 of 276 posts
Re: Not Lisp again (2009)
#252The real power of this isn't just differentiating a given function; as others have pointed out, you can do this in, e.g., C with function pointers. Having first-class procedures and closures means you can actually return the derivative as a function. This lets you do things that the simple example doesn't show. For a physics example, see https://mitpress.mit.edu/sites/default/files/titles/content/... : given a Hamilt…
Re: Not Lisp again (2009)
#253Earlier quoted context omitted.
Almost all Lisp code will put the closing parens all together at the end. And the idea is to not care about how many there are by using an editor that provides the appropriate assistance.
> by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.
It's such a shame because the development environment for Lisp could be so much better than other languages. It could be mindblowingly futuristic, instead of mindblowingly archaic.
Re: Not Lisp again (2009)
#254Earlier quoted context omitted.
> by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.
To any lisp enthusiasts who wonder why the language family isn't more popular: this is 99% of why. You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w". Any attempt to use any other tool will be met with incredulous responses to "just use Emacs". It's such a shame because the development environment for Lisp could be so much better than other languages. It could be mindblowingly…
You are misinformed. I'm using a GNU Emacs (-> Aquamacs) on the Mac and cut/paste/copy are invoked with the usual command keys. But usually I use the LispWorks editor, which is also in the Emacs family, and even there cut/copy/paste is the usual command sequence... Both editors are built with excellent Lisp support. One is written in C + Emacs Lisp and the other one in Common Lisp.
> mindblowingly archaic
You haven't even understood the old part, how would you be able to deal with the futuristic part?
Re: Not Lisp again (2009)
#255Earlier quoted context omitted.
It's not something we ever really think about. That list of closing parentheses just signals termination of the top-level S-expression. And there's virtually nobody coding in a Lisp that doesn't use a structural editing mode (like Paredit or SmartParens). E.g., any time you type "(", you get "()", enforcing balance. What we rely on is proper indentation to indicate the important groupings.
Exactly. IMHO, this is quite similar to Python indentation rules, except it is up to writers of Lisp code to be disciplined enough to maintain the proper indentation.
Wait, even Lisp does that for me, because it has a built-in source code pretty printer:
Call the pretty printer to format this mess:
CL-USER 41 > (let ((*print-case* :downcase))
(pprint '(defun add-text-padding
(str &key padding newline)
"Add padding to text STR. Every line except for the first one, will be
prefixed with PADDING spaces. If NEWLINE is non-NIL, newline character will
be prepended to the text making it start on the next line with padding
applied to every single line."
(let ((str (if newline (concatenate 'string (string #\Newline) str) str)))
(with-output-to-string (s) (map 'string (lambda (x) (princ x s) (when (char= x #\Newline)
(dotimes (i padding) (princ #\Space s)))) str))))
))
It prints wonderfully formatted and indented code: (defun add-text-padding (str &key padding newline)
"Add padding to text STR. Every line except for the first one, will be
prefixed with PADDING spaces. If NEWLINE is non-NIL, newline character will
be prepended to the text making it start on the next line with padding
applied to every single line."
(let ((str
(if newline
(concatenate 'string (string #\Newline) str)
str)))
(with-output-to-string (s)
(map 'string
(lambda (x)
(princ x s)
(when (char= x #\Newline)
(dotimes (i padding) (princ #\Space s))))
str))))
Now one would only need to fix this beginner level code.Re: Not Lisp again (2009)
#256Earlier quoted context omitted.
To me, that's a sign that maybe a language has too little syntax. I can read C++, Javascript and PHP just as well in plain text because the other non-paren elements provide necessary contextual cues, along with nesting. Syntax coloring is helpful, but it shouldn't be necessary. I can at least understand nesting closing parens on their own lines, the way Roboprog did above, but throwing all of them on a single line ju…
It's not something we ever really think about. That list of closing parentheses just signals termination of the top-level S-expression. And there's virtually nobody coding in a Lisp that doesn't use a structural editing mode (like Paredit or SmartParens). E.g., any time you type "(", you get "()", enforcing balance. What we rely on is proper indentation to indicate the important groupings.
Re: Not Lisp again (2009)
#257Earlier quoted context omitted.
Naggum has a pretty good answer for that, linked in the other comment branch: http://www.xach.com/naggum/articles/3224964049435643@naggum.... You could also argue based on things like Common Lisp can run LISP code from 1960 with a very small driver, or the general history of code porting and sharing, as done here: https://news.ycombinator.com/item?id=9387131#9404543
I read that answer, I didn't find it helpful on two points. 1. There's this really nice analogy about German and English languages, but it doesn't have any specifics. In particular, the crux of his entire argument is in this statement > The two languages and their attendant communities have drifted so far apart that there is nothing of value in their intersection. Which he simply states as fact without any sort of fo…
It's the lineage of Lisps where Common Lisp is in, which is Lisp:
Lisp I, Lisp 1.5, Standard Lisp, Interlisp, Maclisp, New Implementation of Lisp, ZetaLisp, Spice Lisp, Common Lisp, Emacs Lisp, ISLisp, ...
Those are all compatible to some extent and share a common core. Code moved a lot along these dialects. Macsyma had been written in Maclisp, moved to Zetalisp, then to Common Lisp. Reduce was written in Standard Lisp and then was ported to Common Lisp (without adoption). Hemlock was written in Spice Lisp and moved to Common Lisp. LOOPS was written in Interlisp and then moved to Zetalisp and later Common Lisp. CLOS was written in Common Lisp and was moved to Emacs Lisp and ISLisp. Even much of Common Lisp was moved to Emacs Lisp. ISLisp can be implemented as a package in Common Lisp relatively easily (Kent Pitman did this to check that ISLisp is compatible and has nothing which is not 'easily' implementable).
It was also usual that some Lisp implementations ran multiple Lisp dialects side by side, sharing everything: data, memory, I/O, ... For example Interlisp-D had a Common Lisp implementation side-by-side with Interlisp. The Symbolics Lisp Machine ran Zetalisp and four variants of Common Lisp side-by-side.
Then there are a lot of derived languages which either have different syntax, different semantics, different data structures, etc.
Examples are Logo, MDL, Scheme, Racket, Dylan, ML, Clojure, Javascript and a bunch of other languages.
Scheme initially shared some code with Lisp. Dylan tried it with a Lisp transpiler, ML initially was written in Lisp, ...
> Scheme can also run LISP code from 1960 with a very small driver.
The old Scheme is relatively near the Lisp mainstream, the newer Scheme less and less. Twenty years ago there was some code sharing between Lisp and Scheme, now almost none.
For me there are two definitions of Lisp:
* the main line compatible and sharing Lisps
* the general abstract family of Lisp which share an undefine subset of a set of features: lists, s-expressions, lambdas, parentheses, ... But you can find lots of languages in the larger Lisp family which have only a rough subset of this, like Javascript or Logo.
Re: Not Lisp again (2009)
#258Earlier quoted context omitted.
Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods? Maybe Racket (or Chicken or Chez or Guile or...) has all of these things, Racket is pretty awesome, but those things aren't standardized, whereas I can get those things in Lisp regardless of if I use SBCL/Clozure/clisp/etc. Maybe it's cl…
>Is it that absurd? Where is Scheme's CLOS, condition system, built-in debugging framework, and batteries-included standard library? Type declarations? Dynamic scoping? Multi-methods? Does Lisp from 1960 have these things? Then I guess it isn't really Lisp?
Re: Not Lisp again (2009)
#259Earlier quoted context omitted.
> by using an editor that provides the appropriate assistance. To spell it out: this means Emacs with Paredit, or an imitation thereof.
To any lisp enthusiasts who wonder why the language family isn't more popular: this is 99% of why. You have to use an editor where "copy" is called "Kill-ring-save" is invoked with "Meta-w". Any attempt to use any other tool will be met with incredulous responses to "just use Emacs". It's such a shame because the development environment for Lisp could be so much better than other languages. It could be mindblowingly…
Re: Not Lisp again (2009)
#260Earlier quoted context omitted.
Why? (And what language do you use where you don't have to rely on the editor to format your code?)
To me, that's a sign that maybe a language has too little syntax. I can read C++, Javascript and PHP just as well in plain text because the other non-paren elements provide necessary contextual cues, along with nesting. Syntax coloring is helpful, but it shouldn't be necessary. I can at least understand nesting closing parens on their own lines, the way Roboprog did above, but throwing all of them on a single line ju…