Arc Forumnew | comments | leaders | submitlogin
2 points by lark 4440 days ago | link | parent

It's surprising that macros destroy functions rather than generate them.

Thanks for vau. It seems it's defun (and def) that are redundant. Compile-time can be modeled as run-time where t = 0, which means one could have macros at run-time. Some such macros could choose to not evaluate their results.



1 point by Pauan 4440 days ago | link

I don't understand what you mean by macros "destroying" functions. They are completely different concepts. They behave differently and they are used for very different purposes: they are orthogonal.

---

It is possible to design a Lisp that doesn't have a function/macro distinction. Such a Lisp would just use vau for everything. An example is the language Kernel:

http://web.cs.wpi.edu/~jshutt/kernel.html

So, to answer your original question: no, it is not necessary to have both mac and def, but that's how most Lisps (including Arc) do it. I think the primary reason is historical, since I think the speed argument is actually bogus for most programs.

-----

2 points by lark 4439 days ago | link

I meant the biggest casualty of vau (which is the ultimate macro) is def.

-----

1 point by Pauan 4439 days ago | link

Well, I'm not sure I'd say that... what vau does is remove the need for mac, but def is still there, to make it more convenient to define functions.

That does mean that functions can be implemented in user-land, which is very nice, but it doesn't really change functions very much.

---

Also, I prefer to not think of vau as being "the ultimate macro", I prefer to see it as a construct which is very different from macros, but happens to serve the same purpose in most cases, which is why vau can replace macros in most (but not all!) cases.

Then again, I also prefer to see functions as being separate from vaus, even if they're implemented using vau... So take what I say with a grain of salt.

-----

2 points by akkartik 4439 days ago | link

It took me a while to realize that I shouldn't think of vau as a macro-like thing. Macros and functions are different kinds of evaluation policies; vau just lets you construct arbitrary evaluation policies. It's like discovering the quarks that all fundamental particles are made up of; quarks don't preferentially constitute an electron more than a neutron.

The challenge now is to build a runtime where vau can have performance comparable to existing lisp systems.

-----

1 point by Pauan 4439 days ago | link

"It took me a while to realize that I shouldn't think of vau as a macro-like thing."

Welcome to the club. Glad you could join us.

---

"The challenge now is to build a runtime where vau can have performance comparable to existing lisp systems."

Yeah. I think a Lisp without implicit late binding (like Nulan) should have a much easier time at it, though.

-----