Why Lisp?

Post by the_af » Fri, May 08, 2015, 12:18 AM UTC

zck wrote: post #130

the_af wrote: post #118

Earlier quoted context omitted.

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

Post by pugio » Fri, May 08, 2015, 12:31 AM UTC

chaoky wrote: post #53

Xophmeister wrote: post #26

Earlier quoted context omitted.

Could someone please explain the difference between Lisp macros and, say, languages that have first-class functions? I get that a Lisp macro will be expanded into the respective code, while a function's execution is different. However, at the practical (i.e., developer's) level, are there any additional benefits? Can, say, a Lisp macro be 'partially formed', in the sense that it can expand into some boilerplate that…

A higher order function doesn't serve the same purpose as a macro. A higher order function is meant to be applied, called, composed etc. A lisp macro is a different type of abstraction. For example, many people think that macros are just hiding lambda's of higher order functions. This is wrong. A macro abstracts over implementation details of a construct to make it read naturally. For example, you can write a functio…

  with_open_file filename do |f|
    do stuff with file
  end

  # our 'macro' function
  def defclass(name, parent, &blk)
    k = Class.new(parent)
    k.instance_eval(&blk)
    Kernel.const_set(name, k)
  end

  defclass :Tiger, Animal do
    attr_accessor :age, :name
  end

Post by GFK_of_xmaspast » Fri, May 08, 2015, 12:41 AM UTC

snikeris wrote: post #64

Xophmeister wrote: post #26

Earlier quoted context omitted.

Could someone please explain the difference between Lisp macros and, say, languages that have first-class functions? I get that a Lisp macro will be expanded into the respective code, while a function's execution is different. However, at the practical (i.e., developer's) level, are there any additional benefits? Can, say, a Lisp macro be 'partially formed', in the sense that it can expand into some boilerplate that…

My favorite example for this is the lame idiom you see in Java code: if (log.isDebugEnabled()) { log.debug("expensive" + debug + message); } This is "better" than just log.debug(...) because with the latter, your expensive log message argument needs to be evaluated even if debug is disabled. However, in a language w/ macros, you just say: (debug (str "expensive" debug message)) and these considerations are already ta…

Post by GFK_of_xmaspast » Fri, May 08, 2015, 12:43 AM UTC

ScottBurson wrote: post #113

Xophmeister wrote: post #26

Earlier quoted context omitted.

Could someone please explain the difference between Lisp macros and, say, languages that have first-class functions? I get that a Lisp macro will be expanded into the respective code, while a function's execution is different. However, at the practical (i.e., developer's) level, are there any additional benefits? Can, say, a Lisp macro be 'partially formed', in the sense that it can expand into some boilerplate that…

It's true, as others have explained, that for many of the most common uses of macros, you can get the same effect with a higher-order function. But since macros operate at the syntax level, they can do things functions can't do. For example, they can generate and manipulate declarations. Say you're working with abstract syntax trees (assembly trees in a CAD app might be another example). These trees are built from no…

Post by GFK_of_xmaspast » Fri, May 08, 2015, 12:49 AM UTC

frou_dh wrote: post #60

ThrustVectoring wrote: post #40

Earlier quoted context omitted.

This is only ~90% likely to be correct, since it's second-hand information and I don't use LISP actively. A LISP macro is a syntax transformation. It lets you write code in the way you want to, instead of whatever level of abstraction you used to have. I'm not sure about 'partially formed' code output, but 'partially formed' input is definitely possible. The way to invoke a LISP macro need not be valid LISP. In short…

In my Lisp-esque language I use a temporary macro to automate the creation of some similar standard library procedures. This happens at runtime in the stdlib source file that is loaded: # Define procedures named int? float? etc that test the type of a value. (def def-type-predicate (mac (type-name) `(def ,(string-to-symbol (join "" $type-name "?")) (proc (x) (eq? (type x) ',type-name))))) (def-type-predicate int) (de…