Why Lisp?

Post by kazinator » Fri, May 08, 2015, 1:23 PM UTC

comex wrote: post #185

lisper wrote: post #111

Earlier quoted context omitted.

> XML was never designed as a data serialization format. It's a markup language. Those two things are not mutually exclusive. > Likewise, JSON is a subset of a general-purpose programming language's literal notation that happened to be very fast to parse in a browser by virtue of the browser implementing that language. That's true. That is not in conflict with anything I said. > The problem is that there's no one-siz…

One downside to S-exprs compared to, say, JSON: they do not have direct support for unordered mappings (hash tables, dictionaries, whatever you want to call them). You can represent them as trees, but basically every language these days (including, of course, Lisps) has a mapping type as a core concept; requiring the user to figure out what parts of the input data should be converted to that type is annoying, and mak…

  $ txr -p "(let ((x (hash))) (set [x 'a] 1) (set [x 'b] 2) x)"
  #H(() (b 2) (a 1))

  #(1 2 3)     ;; this is a vector
  #C(3.0 4.9)  ;; this is the complex number 3.0 + 4.9i

  $ txr -p "(let ((keys '(a b c)) (vals '(1 2 3)))
               ^#H(() ,*(zip keys vals)))"
  #H(() (c 3) (b 2) (a 1))

Post by dllthomas » Fri, May 08, 2015, 2:35 PM UTC

wtetzner wrote: post #181

dllthomas wrote: post #119

Earlier quoted context omitted.

One thing to note is that you're using the macro or lambda to delay evaluation. In a lazy-by-default language, that's unnecessary (which is a part of why macros are less useful in Haskell).

There's a class of things that don't require macros in Haskell, but I don't think that means macros are less useful in Haskell. There are plenty of things you might want them for, like generating new definitions.

Post by lisper » Fri, May 08, 2015, 3:16 PM UTC

igravious wrote: post #179

(I have a subtle optimization for S-expression syntax)(I am surprised nobody ever thought of it)(When S-expressions are in a sequence use an extra (special) delimiter plus the regular token separator to separate expressions)(Maybe use dot? (period I think some call it)) Like so. I think it could catch on. And you get rid of so many round bracket block delimiters (at least for S-expressions on the same level. for nest…

Post by the_af » Fri, May 08, 2015, 3:26 PM UTC

blueblob wrote: post #208

LanceH wrote: post #161

Earlier quoted context omitted.

One that helped some Java friends understand is passing blocks of code, but still having it look like just writing code. Imagine instead of try/catch/finally, a transaction/commit/rollback in Java: transaction { // everything in here is in one transaction } commit { // do stuff if the commit is successful } rollback { // do stuff if we rollback } All the try's and catch's can be stuff into the macro. It can be made t…

I find this argument pretty unconvincing too. >For all practical purposes, you can't add that to Java. You'll always have to wrap up your transactions in boilerplate. Aren't you wrapping the lisp code in boilerplate when doing the macro too? This appears to be the same as your other example. Java has lambda expressions (since Java 8) that could do this. If you are wrapping it in a macro, how is it different than wrap…

Post by soegaard » Fri, May 08, 2015, 4:39 PM UTC

the_af wrote: post #147

zck wrote: post #143

Earlier quoted context omitted.

Because macros let you control code in a way libraries don't^1. Java now has this way to iterate over a collection of things: for(String exclamation: exclamations) { System.out.println("I yell " + exclamation + " at you"); } But this was only added in 2004!^2 So for almost 10 years, you had to manually iterate over stuff. How would you implement this as a library? Well, you could write a function that lets you write:…

Agreed about your Java example. However, for the purpose of this discussion, let's assume we're talking about modern, well-designed languages without ugly kludges and with access to nice features such as lazy evaluation and real closures. > Macros can be viewed as libraries that act on the language itself. There isn't a difference between language-level features and "library functions" in a language with macros. I si…