Hacker News Reader

Comment by rileyphone | Hacker News Reader

The irony of the 2 + 3 = 5 example is that it shows how domain-specific languages work best with iconic forms. Paralinguistic symbols as constituency tends toward mismatched metaphors and visual sameness. However, crafted carefully, such tools represent the best available to tame complexity.

There is a level of metaprogramming even more fundamental than Lisp macros - the ancient and maligned fexpr [0]. They are almost as if you took lambda and just didn't evaluate the args when called by default. In fact, this is what Kernel [1] elegantly showed, bringing along with it the pure notion of a vau calculus, which can help restore optimization techniques who's absence resulted in the original defamation of the fexpr.

[0] https://fexpr.blogspot.com/2011/04/fexpr.html

[1] https://web.cs.wpi.edu/%7Ejshutt/kernel.html

View on HN

I think you will be more successful communicating your ideas if you use less obscure language. Assuming of course that you are actually trying to communicate ideas and not just trying to virtue signal intelligence or education by being intentionally obfuscated.

"Paralinguistic symbols as constituency"

You mean constituents? Or operands?

"Paralinguistic"

I think you mean syncategoremata?

"Iconic forms"

"vau calculus"

Interesting. For the interested, see: https://web.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unr...

> "Paralinguistic"

> I think you mean syncategoremata?

I think this is the most HN thing I've ever read on this site. :D

So what's the difference between fexprs and macros? Can you give an example that illustrates it?

I think the main difference is that macros statically evaluate their inputs ie. at compile-time. fexprs can selectively eval their inputs at runtime ie. dynamically.

This has given the impression of slowness and difficulty to grok with fexprs, as dynamic eval foregoes certain optimisations, and scoping the fexpr bindings is hard (variable capture is a problem).

https://web.wpi.edu/Pubs/ETD/Available/etd-090110-124904/unr... is a good paper on this stuff (see p41/42 for a discussion).

Another version of fexprs/vau is open composition https://www.piumarta.com/freeco11/freeco11-piumarta-oecm.pdf

I guess the main issue is handling dynamic binding cleanly. Koka https://koka-lang.github.io/koka/doc/book.html#why-handlers handles this well with static (HM) type inferrence.

Shen and Maude (https://shenlanguage.org/TBOS/tbos_255.html, https://maude.lcc.uma.es/maude321-manual-html/maude-manual.h...) are the only languages that I know that can do dynamic type checking, and thus a full handling of dynamic binding, the Shen calculus syntax is a bit clunky though.

> macros statically evaluate their inputs ie. at compile-time

Unless one uses an interpreter.

  CL-USER 1 > (defmacro my-if (test a b)
                (print "Hi, I'm the executing MY-IF macro")
                `(if ,test ,a , b))
  MY-IF

  CL-USER 2 > (defun foo (a)
                (my-if (> a 10) 'big 'small))
  FOO

  CL-USER 3 > (foo 11)

  "Hi, I'm the executing MY-IF macro" 
  "Hi, I'm the executing MY-IF macro" 
  BIG

  CL-USER 4 > (foo 2)

  "Hi, I'm the executing MY-IF macro" 
  "Hi, I'm the executing MY-IF macro" 
  SMALL

In this Lisp implementation, the macro even runs twice on each runtime invocations.

SBCL to the rescue. It compiles everything you enter in the REPL.

Unless one uses an interpreter:

  $ /usr/local/bin/sbcl

  This is SBCL 2.2.1, an implementation of ANSI Common Lisp.
  More information about SBCL is available at <http://www.sbcl.org/>.

  SBCL is free software, provided as is, with absolutely no warranty.
  It is mostly in the public domain; some portions are provided under
  BSD-style licenses.  See the CREDITS and COPYING files in the
  distribution for more information.
  *  *evaluator-mode*
  :COMPILE
  * (setf  *evaluator-mode* :interpret)
  :INTERPRET
  * (defmacro my-if (test a b)
      (print "Hi, I'm the executing MY-IF macro")
      `(if ,test ,a , b))
  MY-IF
  * (defun foo (a)
      (my-if (> a 10) 'big 'small))
  FOO
  * (foo 11)
  (foo 11)

  "Hi, I'm the executing MY-IF macro" 
  BIG

Fair enough :) At least the macro is only evaluated once, not twice.

Note that not the generated code ran twice (in LispWorks twice, in the specific SBCL interpreter once), just the code generation. In Common Lisp it's unspecified how often the code generation runs.

> This has given the impression of slowness and difficulty to grok with fexprs, as dynamic eval foregoes certain optimisations, and scoping the fexpr bindings is hard (variable capture is a problem).

And yet, Javascript, possibly the most widespread language on the planet, does exactly this and has been optimized for speed to hell and back several times.

The problem wasn't unsolvable. The problem was that there wasn't enough money behind solving it.

JavaScript has Fexprs?

JavaScript has highly dynamic eval with lots of scoping issues very similar to the issues that everybody thought were dealbreakers with fexprs.

And, yet, somehow a lot of very clever people made Javascript one of the fastest languages around.

and that "fast" JavaScript code is using eval?

OTOH, typically Lisp code uses zillions of macros, incl. most of control flow constructs.

Consider this answer from lispm as to what fexprs can do that macros cannot, namely being first-class objects in the language that can be stored and passed as values, just as a number or a function can be.

https://stackoverflow.com/questions/13393673/how-do-you-stor...

I see, thanks! Is that the only additional capability or is there more?

They have the advantage of making macro writing a good deal simpler, by providing a higher-level control over metaprogramming. The effect is almost like CLOS-style classes in comparison to C++ classes - a more complete metaphor (metaprogramming/OOP) is more difficult to implement and optimize, but makes up for in improved programmability.

Of course this is all highly subjective. Perhaps fexpr was just a weird language construct that introduced more problems than it solved. I think it is an unexplored avenue that was brought to light again by Kernel. You really need fexprs to get a true programmable programming language in the sense their are no exceptions. Maybe the cost can become reasonable.

I mean I'm asking about concrete differences in how they fundamentally work, since I'm not familiar with fexprs in the first place, and (as someone who doesn't use Lisp) not very familiar with macros either. I'm not asking about larger consequences like the sort you describe in this answer.

In that case, I would recommend reading this post. Shutt explains it much better than I can.

https://fexpr.blogspot.com/2011/04/fexpr.html

That post doesn't mention macros at all, so it does not seem to contain the macro-vs-fexpr contrast I'm looking for.

> Paralinguistic symbols

What’s that? I googled and am still confuzled.

I don't know either, but in English one definition/sense of para is "beyond", so it is "beyond language symbols", which shapes up to be something in the sense of a sort of programming paradigm where everything is subject to redefinition, particularly on the fly.

For our purposes we can call them 'glyphs' without much, if any, loss of generality.

Maybe he means "foo" and "bar", the canonical metasyntactic variables.

https://en.wikipedia.org/wiki/Metasyntactic_variable

Yeah, apologies for being a little obtuse. Things that look like words but don't act as typical verbal language.

Reply on news.ycombinator.com