Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Evolution of Lisp (1993) [pdf]

dreamsongs.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: The Evolution of Lisp (1993) [pdf]

#31

Post by owl57 »

PuercoPop wrote: post #17
0x445442 wrote: post #12

Earlier quoted context omitted.

I'm not slamming Emacs. I'm just pointing out that there are millions of developers that won't use it and making it a, more or less, requirement to get into Common Lisp is not good.

> I'm just pointing out that there are millions of developers that won't use You are just stating it. Without any reason. One can't argue against a statement, you have to provide reasons behind your statement for there to be an argument. For example: "Asking people to use an editor where C-c doesn't copy and they have to relearn the keybindings is an unnecessary barrier of entry". I would agree with that and note tha…

it is unreasonable to ask people to use Android Studio to develop for Android

Obviously interesting platforms can get away with much more ridiculous requests such as "buy a Mac" or "program in JavaScript".

Re: The Evolution of Lisp (1993) [pdf]

#32

Post by white-flame »

vindarel wrote: post #4

To refresh your ideas on CL (I know I needed it): https://github.com/CodyReichert/awesome-cl There may be more libraries than you think. Also recently some usual complaints have been fixed: - hard to set up environment ? -> http://portacle.github.io/ There's also Lem, and Atom is getting good. https://lispcookbook.github.io/cl-cookbook/editor-support.ht... - horrible website ? http://common-lisp.net/ (they fixed it l…

- library download manager ? -> https://www.quicklisp.org/ (over 1500 libs)

Re: The Evolution of Lisp (1993) [pdf]

#33

Post by camdenreslink »

tsimionescu wrote: post #24
dragonwriter wrote: post #23

Earlier quoted context omitted.

> I won't use Emacs because I want a smart editor or IDE, not an editor construction toolkit. I have no interest in micro-optimizing my editor. Pretty much all "smart editors or IDEs" that are available are editor construction toolkits bundled with add-ons which make completed editors using the toolkit for a variety of special purposes, and with an ecosystem (first party and/or community) of additional add-ons availa…

To be honest, when you install Visual Studio or IntelliJ, you have all you need to develop code in the language you chose, with 0 extra customization. Of course, some amount of extra customization will usually follow, but that can come after you are more confident with the environment. The same is definitely not true for VSCode, Emacs or vim, though perhaps bundles like portacle can offer a similar experience. I say…

VSCode usually requires downloading the officially supported language bindings, which takes 2 minutes to figure out and is very intuitive/easy.

Re: The Evolution of Lisp (1993) [pdf]

#34

Post by pmoriarty »

0x445442 wrote: post #12
newusertoday wrote: post #7

Earlier quoted context omitted.

why is emacs not a solution? the link provided by parent is excellent beginner friendly environment ( http://portacle.github.io/ ).

I'm not slamming Emacs. I'm just pointing out that there are millions of developers that won't use it and making it a, more or less, requirement to get into Common Lisp is not good.

There are millions of developers who won't use Windows, and millions who won't use MacOS.

I guess neither of those is worthy of using either because of this.

Re: The Evolution of Lisp (1993) [pdf]

#35

Post by kazinator »

lispm wrote: post #28
kmill wrote: post #21

Earlier quoted context omitted.

I'm not sure what the relationship between fexprs and homoiconicity is supposed to be. If anything, the arguments to an fexpr in a Lisp with lexical scoping are opaque and cannot be manipulated, since they are wrapped up in a closure by the interpreter. Plus, not every macro can be written as an fexpr (for example, LOOP). In contrast, fexprs seem to work well in PicoLisp because it uses dynamic scoping exclusively. T…

> One strange Lisp variant is Mathematica I wouldn't call Mathematica a Lisp, given that it is a runtime rewrite system and not based on a defined evaluator (which also makes Lisp relatively easy to compile and also compilable to relatively efficient code). > That way you could define both a macro and function version of a symbol if they both make sense. There is a variant of that in CL called 'compiler macro'. > The…

I fixed that in TXR Lisp. Macro bindings and function bindings in the global namespace are separate and coexist. The mboundp predicate is provided for testing for a macro binding, which can be undone with mmakunbound, analogous to fmakunbound

https://www.nongnu.org/txr/txr-manpage.html#N-0384A294

TXR comes with function complements of if and and and some others.

  1> (and (prinl 'foo) nil (prinl 'bar))
  foo
  nil
  2> (mapcar 'and '(nil t nil t) '(nil nil t t ))
  (nil nil nil t)
Unsurprisingly, TXR Lisp has no compiler macros. If you want to speed up a function using a macro, then just write a same-named macro.

TXR Lisp macros can decline to expand by returning an output that is eq to their input. If a macro declines to expand, and a function exists, then that form will be treated as a call to that function, naturally.

When a TXR Lisp lexical macro declines to expand, then a same-named macro in an outer scope (or else the global environment) is thereby effectively unshadowed and gets an opportunity to expand the input. This is very useful and exploited in the implementation of tagbody, which it simplifies. http://www.kylheku.com/cgit/txr/commit/share/txr/stdlib/tagb...

Re: The Evolution of Lisp (1993) [pdf]

#36

Post by lispm »

kmill wrote: post #30
lispm wrote: post #28

Earlier quoted context omitted.

> One strange Lisp variant is Mathematica I wouldn't call Mathematica a Lisp, given that it is a runtime rewrite system and not based on a defined evaluator (which also makes Lisp relatively easy to compile and also compilable to relatively efficient code). > That way you could define both a macro and function version of a symbol if they both make sense. There is a variant of that in CL called 'compiler macro'. > The…

> Mathematica It's derived from Wolfram's conception of Macsyma, and it is designed so that all code is made out of numbers, strings, symbols, and arrays (sure, not cons cells). I guess it's nice to know you wouldn't call Mathematica a Lisp, but I didn't say it was strictly in the Lisp family, just a strange variant. (Does this mean you do not consider PicoLisp a Lisp either, since it is not really compilable, as far…

> I guess it's nice to know you wouldn't call Mathematica a Lisp,

Thanks!

> but I didn't say it was strictly in the Lisp family, just a strange variant.

Right, that was my point, I don't consider term rewriting systems as Lisp variants, even though they may have numbers and strings as data types. The actual execution engine is too different.

Fexprs had the interesting property that it sees the actual source at runtime (which makes it very different from lazy evaluation or wrapping things in lambdas), which appeals especially to users/implementors of computer algebra systems (see Reduce written in Portable Standard Lisp, which provides Fexprs) or other math software dealing with formulas (like R, which has a feature similar to fexprs).

> Mathematica does have a built-in compiler, but granted it is unclear exactly what subset of the language it is compiling.

From what I read of its very unspecific documentation, I doubt that it does the term rewriting at compile time (like Lisp does macro expansion at compile time) - does it? To me it looks like the compiler targets numeric code and basic control flow...

They probably have better documentation of their language implementation, internally. Or is there an externally available document, which actually describes their implementation?

Mathematica as a rewrite language

https://www3.risc.jku.at/publications/download/risc_342/1996...

Re: The Evolution of Lisp (1993) [pdf]

#37

Post by vindarel »

m463 wrote: post #18
0x445442 wrote: post #5

Earlier quoted context omitted.

The lack of a really good open source IDE or IDE plugin is a real road block for a number of people. Pointing folks to Emacs or an Emacs derivative is is not the solution. I know there is a couple of IDE plugins for Clojure and I think it would help if there were similar options for Common Lisp. I know there used to be a plugin for Eclipse (Cusp) but that appears to have died.

I watched a fascinating presentation and when I saw the speaker typing (lambda ...) and having it change to (λ ...) and not having to deal with parens.. I was jealous. Does emacs do this? EDIT: the presentation: William Byrd on "The Most Beautiful Program Ever Written" https://www.youtube.com/watch?v=OyfBQmvr2Hc

You can also use shorter lambda forms: https://github.com/CodyReichert/awesome-cl#lambda-shorthands

Re: The Evolution of Lisp (1993) [pdf]

#38

Post by oblio »

agumonkey wrote: post #26
oblio wrote: post #22

Earlier quoted context omitted.

I won't use Emacs because I want a smart editor or IDE, not an editor construction toolkit. I have no interest in micro-optimizing my editor.

until very recently emacs was the only editor that felt "smart". visual studio didn't really recognized grammar the same way. emacs semi parsing meant that TAB was a way to syntax check my code on the fly (50% of why I kept using emacs in college)

Eclipse has had incremental Java compilation since at least 2007. That's 12 years.

Re: The Evolution of Lisp (1993) [pdf]

#39

Post by m463 »

dTal wrote: post #25
m463 wrote: post #18

Earlier quoted context omitted.

I watched a fascinating presentation and when I saw the speaker typing (lambda ...) and having it change to (λ ...) and not having to deal with parens.. I was jealous. Does emacs do this? EDIT: the presentation: William Byrd on "The Most Beautiful Program Ever Written" https://www.youtube.com/watch?v=OyfBQmvr2Hc

Some languages understand λ directly (and in all lisps that support unicode, you can explicitly alias it) - I've occasionally mapped AltGr+L to λ, when playing with those. It's really nice. APL perhaps goes a little far, but I'd like to see more standardized symbols in programming languages. Imagine how nice it would be to succinctly use things like the actual outer-product operator ⊗...

> APL perhaps goes a little far

When I learned APL long ago in a languages course, it was on a dedicated APL setup with an APL keyboard.

In that context, it was a "how SHOULD things be" sort of design decision. I know I started off quickly thinking in terms of math and the language, not composing symbols.

Of course, APL keyboards have gone the way of the dodo and so the language has a higher barrier to entry.

Re: The Evolution of Lisp (1993) [pdf]

#40

Post by agumonkey »

oblio wrote: post #38
agumonkey wrote: post #26

Earlier quoted context omitted.

until very recently emacs was the only editor that felt "smart". visual studio didn't really recognized grammar the same way. emacs semi parsing meant that TAB was a way to syntax check my code on the fly (50% of why I kept using emacs in college)

Eclipse has had incremental Java compilation since at least 2007. That's 12 years.

Yeah but eclipse had its share of wat. That made everything nice it brought insufferable.
Post reply on HN