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

Why Lisp?

blog.rongarret.info

Post reply on HN
Print view View original

121–130 of 248 posts

Re: Why Lisp?

#121

Post by snikeris »

dragonwriter wrote: post #100
TenDecigrams wrote: post #98

Earlier quoted context omitted.

Edit: Ohhh! I see! The message isn't evaluated until after! Got it. I don't understand why this is special? Why can't you rewrite log.debug to include the check? func debug(m string) { if log.isDebugEnabled() { log.debug(m); } } What makes macros special in this case?

The point was that "debug" and "message" parts in the example were arbitrarily complex expressions which were computationally expensive to evaluate. Your wrapping of log debug would still require evaluating them to get the message string unconditionally, even when debug logging is not enabled. Of course, with support for first-class functions, you could do something like: func debug(produceMessage ()->string) { if lo…

And then what would I need to type to write a log message?

Re: Why Lisp?

#122

Post by kazinator »

the_af wrote: post #118
kazinator wrote: post #108

Earlier quoted context omitted.

> Which definition of "macro" are you using, if you equate lazy evaluation with a kind of "hardcoded macro"? That definition of "macro" equivalent with "phrase structure rule in your functional language's compiler" which takes the input structure and generates whatever code brings about the lazy semantics (which is not inherent in the x86 instruction set or what have you). > example where these "macros" are not enoug…

> An example is any instance of language extension where, say, the maintainers of the compiler for a functional language have to ship a new compiler to the users to get them to use the new feature. > Functional languages with lazy evaluation are not finished, right? They are developed actively. Agreed, they are actively developed. Correct me if I'm wrong, but you seem to be saying "many interesting features can be im…

> Correct me if I'm wrong, but you seem to be saying "many interesting features can be implemented in a Lisp language with a macro, therefore Lisp programmers don't need to wait for a new release of their programming language when they want these features".

That is correct. However, macros have to translate to something. From time to time you need an upgraded something for some macros to be feasible.

E.g. it's hard to "macro your way" into having first-class continuations, if they aren't in the substrate.

That is to say, without the macro treating all of its arguments as a self-contained language.

You usually want the code which is in the macro forms to smoothly interoperate with outside code, such as make lexical references to surrounding bindings.

This is the fuzzy limit. Macros have to write stuff in some language, which is no longer macro-expandable. That language has to be reasonably expressive in its semantics for what the macros want to do.

Re: Why Lisp?

#123

Post by p4bl0 »

platz wrote: post #52
beeworker wrote: post #49

Earlier quoted context omitted.

One difference is flow control. When you call a function, all the arguments are evaluated before being passed into the function. If you want to delay evaluation, you have to wrap the argument values in a function. When you call a macro, the text forms get passed with no evaluation. Say Clojure forgot to ship with the boolean "or". "or" should evaluate its arguments one at a time (to allow for short circuiting) and re…

I wonder how much macros are necessary one you add call-by-name parameters e.g. scala.

You should have a look at Kernel, vau-calculus and F-expressions. Kernel merges the notions of first-order functions and macros by having lexically scoped definition of Fexprs which takes their argument by name and also receives the call-site environment so that you can eval the argument in it if needed.

I find it a very elegant way of having everything clean, "lambda" does not even have to be a primitive anymore.

Re: Why Lisp?

#124

Post by orthecreedence »

dmux wrote: post #117
weavie wrote: post #61

Earlier quoted context omitted.

Even better you can attach the repl to a remote instance. I had a problem a little while ago that could only be reproduced on the server. I could connect to the repl over ssh and evaluate and modify code directly. Compare that to a similar problem I had with a C# app we had. For that I had to stick in a load of logging code, check it in then wait half an hour for the CI server to deploy before running and checking th…

Do you know if the attaching to a remote instance is available in Racket? I spent some time learning racket a year or two ago, but was under the impression they took out some of the really cool features (or I never discovered them)

Not a racket user, but I'm almost certain that you can do this with Racket. Your editor doesn't care whether your REPL session is local/remote...it just connects to a an address/port. You can set this to be 127.0.0.1 or whatever remote server you want to connect to.

Re: Why Lisp?

#125

Post by ScottBurson »

lisper wrote: post #14
WalterGR wrote: post #12

The article doesn't discuss macros, which is one of the answers to "Why Lisp?" I didn't "get" macros until I read a footnote in the (freely available) book Practical Common Lisp . In chapter 7, it introduces the `dolist` macro. DOLIST loops across the items of a list, executing the loop body with a variable holding the successive items of the list. This is the basic skeleton (leaving out some of the more esoteric opt…

And if you want Python-style iterators, that's easy too: http://blog.rongarret.info/2008/02/joy-of-iterators.html

So, that thing I mentioned yesterday that I wrote 35 years ago? It might interest you:

  https://github.com/slburson/misc-extensions
Look in src/gmap.lisp.

I admit it wouldn't work that well for 'n-at-a-time', but here's a closely related example:

  (defun alist-to-plist (alist)
    (gmap :plist nil (:alist alist)))
There are some idiosyncrasies here: 'nil' is shorthand for the identity function (in this case, the two-argument, two-value identity function), and the use of keyword symbols is weird and potentially problematic, though I've never run into a problem with it in practice.

This is the map-reduce model of iteration -- obviously not with support for distributed computation, but nonetheless useful for programming in the small. And far more elegant, to my eyes, than that LOOP monstrosity :-)

Re: Why Lisp?

#126

Post by rapala »

the_af wrote: post #118
kazinator wrote: post #108

Earlier quoted context omitted.

> Which definition of "macro" are you using, if you equate lazy evaluation with a kind of "hardcoded macro"? That definition of "macro" equivalent with "phrase structure rule in your functional language's compiler" which takes the input structure and generates whatever code brings about the lazy semantics (which is not inherent in the x86 instruction set or what have you). > example where these "macros" are not enoug…

> An example is any instance of language extension where, say, the maintainers of the compiler for a functional language have to ship a new compiler to the users to get them to use the new feature. > Functional languages with lazy evaluation are not finished, right? They are developed actively. Agreed, they are actively developed. Correct me if I'm wrong, but you seem to be saying "many interesting features can be im…

One could write a macro that allows infix notation for arithmetics: (arithmetics 1 + 2 - 3) = (- (+ 1 2) 3) These kind of syntactic transformations are what macros enable.

Re: Why Lisp?

#127

Post by CJefferson »

lisper wrote: post #111
munificent wrote: post #80

> The reason that code represented as XML or JSON looks horrible is not because representing code as data is a bad idea, but because XML and JSON are badly designed serialization formats. By that same token, a Volkswagen Beetle is a badly-designed boat. XML was never designed as a data serialization format. It's a markup language . It was designed to sprinkle structure and metadata into large human-readable plaintext…

> 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…

Is there any loss less binding of XML to s expressions? I've never seen one.

Usually example where I see people rewrite XML to s expressions (like in this thread) are very lossy -- its easy to be pretty by throwing away most of the information!

Re: Why Lisp?

#128

Post by quacker »

kazinator wrote: post #104
Dewie3 wrote: post #71

Earlier quoted context omitted.

I guess the "problem" with understanding this perspective for us non-lisp people is that we may not be able to imagine all the places that we could have used macros (or something equivalent) if we haven't even learnt it. You don't know what you don't know, or in this case, you don't know how to use something you haven't used. But this seems to be the same for boatload of programming features that many people aren't t…

Macros are easy to understand if you are shown that whatever language you are using already has them . The difference is that they are locked in and wrapped behind at least two layers. Firstly, there rigid surface syntax which customizes the look of every macro at the character level. For instance, in C, the do ... while(); loop must have a trailing semicolon. (No Lisp macro has such requirements.) Secondly, that sur…

This doesn't really address the issue of readability or understanding though. You still have to go through someone else's uncommented code and figure out what their weirdo macros actually do versus having standard, documented language features that you already understand.

Because there's not a ton of standardization (and for other reasons) you end up with a million different dialects of lisp and a fragmented community, in comparison to other language families.

And you can do open, community-driven standardization and language enhancement. Python is a decent example of this.

Re: Why Lisp?

#129

Post by ScottBurson »

lisper wrote: post #111
munificent wrote: post #80

> The reason that code represented as XML or JSON looks horrible is not because representing code as data is a bad idea, but because XML and JSON are badly designed serialization formats. By that same token, a Volkswagen Beetle is a badly-designed boat. XML was never designed as a data serialization format. It's a markup language . It was designed to sprinkle structure and metadata into large human-readable plaintext…

> 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…

>> XML was never designed as a data serialization format. It's a markup language.

> Those two things are not mutually exclusive.

I beg to differ. I just replied to someone else about this: https://news.ycombinator.com/item?id=9509110

I agree with your last paragraph, though. There is a timelessness about S-expressions.

As a side point, I would add that the distinction between strings and symbols is important, and neither XML nor JSON has it.

Re: Why Lisp?

#130

Post by zck »

the_af wrote: post #118
kazinator wrote: post #108

Earlier quoted context omitted.

> Which definition of "macro" are you using, if you equate lazy evaluation with a kind of "hardcoded macro"? That definition of "macro" equivalent with "phrase structure rule in your functional language's compiler" which takes the input structure and generates whatever code brings about the lazy semantics (which is not inherent in the x86 instruction set or what have you). > example where these "macros" are not enoug…

> An example is any instance of language extension where, say, the maintainers of the compiler for a functional language have to ship a new compiler to the users to get them to use the new feature. > Functional languages with lazy evaluation are not finished, right? They are developed actively. Agreed, they are actively developed. Correct me if I'm wrong, but you seem to be saying "many interesting features can be im…

So you think of a feature you'd like in your language. Let's consider the process you'd have to go through to use that feature.

In most languages, you have to write the maintainers about the feature. You then have to convince them that the idea is good -- and this is by no means guaranteed; if they think your idea is bad, you're out of luck, and can never use the feature you'd like. Then someone has to implement it. Then you have to wait for a release containing the feature. Then you have to test your code with the new version. Then you have to upgrade all your deploys, development environments, and testing machines to the new version. Then you can use the new feature.

In a Lisp with macros, you have to implement the feature. Then you can use it.

This is why macros are useful. You get to modify the language you're using, but still cut out the entire loop of the maintainers of that language.

Post reply on HN