"Dylan … abandoned in favor of C++.” is not accurate, at least for the Newton. As the Newton shrank down from its original planned size to the small size it shipped with, Dylan was replaced by NewtonScript. A lot of the primitives were written in C++.

“C syntax … makes macros nearly impossible.” is also not accurate. We came up with a way to do hygienic macros, based on a more flexible notion of parsing, and template ideas from Dybvig and Hieb. http://www.cs.indiana.edu/~dyb/pubs/LaSC-5-4-pp295-326.pdf

Unfortunately we were only able to implement a limited version of the syntax, before the Apple project was shut down. And we never wrote up any of the design. The phrase “fragment grammar” comes to mind, but I really don’t recall the details. Jonathan Bachrach has used these ideas to add macros to Java, but I’m not sure how far he went with making the syntax flexible. Look for “Java Syntactic Extender”.

And yes, sealing was the way to tell the compiler it could do some interesting optimization with generics. We implemented some of that. I’m not sure if it survives today.

On Jul 10, 2014, at 1:12 PM, Steve Haflich shaflich@gmail.com wrote:

Hans is correct.

In more detail, there are some liabilities of the late-binding strategies that pervade Common Lisp. If you declaim a function to be inlined, then you are promising that you will never change it. While a very smart implementation could track all the other functions that have inlined that function, and automatically recompile them, I'm unaware of any implementation that has provided the mass of bookkeeping this would require.

A generic-function is unlike a regular function in that it has an implementation that is typically distributed across many top-level forms, and often distributed across many source files. This makes the bookkeeping all the more dificult.

Some may remember ultimately unsuccessful Apple's Newton project in the late 1990's. During part of that project they intended the major platform programming language to be Dylan, which was recognized as a Lisp derivative benefitting from the recent completion of ANSI CL standard but with a number of new ideas. (It was extremely disappointing that Apple eventually decided to use C syntax rather than Lisp, because that makes macros nearly impossible.) Dylan was ultimately unsuccessful -- mo mature implementations -- and abandoned in favor of C++.

But Dylan had one really great potential feature CL lacks: It has protocols for declaring a class tree of a gf to be sealed. That was a promise that these entities would never after be modified, which include extensions! Once a bunch of stuff has been sealed, a "block compiler" could in principle (and probably also in practice) walk over an entire application and do lots of inlining and degenerifying of function calls, without changing the semantics of a correctly-declared program. Sealing is something I would like to have seen added to CL, but machines are so fast these days that inlining and degenerifying aren't what the Lisp market is concerned about these days.

On Thu, Jul 10, 2014 at 9:20 AM, Hans Hübner hans.huebner@gmail.com wrote: Jean-Claude,

you can expect your compiler to ignore your "inline" declaration. Or do something else with it. It is just a hint. [1]

A sufficiently smart compiler might use compile-time type inference to find a method matching some set of argument types and then replace the function invocation by the body of that method. To me, it appears to be questionable whether such a smart compiler would depend on inline declarations.

I am just a user, though, and maybe one of the compiler writers on this list want to add some of the fine points surrounding this :)

-Hans

[1] http://clhs.lisp.se/Body/d_inline.htm

2014-07-10 0:00 GMT+02:00 Jean-Claude Beaudoin jean.claude.beaudoin@gmail.com: Hello CL pros,

I am trying to figure out the meaning of the inline declaration when the so qualified function happens to be a generic function. As in:

(declaim (inline foo)) (defgeneric foo (a b))

What can be expected of a compiler when it then faces a call to foo while the above is in effect?

Is this an obvious no-op or did some find something useful to do in such a context?

Thanks for your help,

JCB

---

pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro

---

pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro

---

pro mailing list pro@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/pro