Re: Beyond CL?

paulgraham wrote:
> We have to invent genuinely new things. Things,
> moreover, that people like John McCarthy, Gerry Sussman, and
> Guy Steele didn't think of. That's not so easy.

I agree. Luckily, we have an advantage: we are standing on their
shoulders. Man of 10,000 years ago had the same brain, and thus the
same intelligence as we do now. Cultural evolution alone has brought us
to this point, and it will, I believe, carry us forward.

One promising idea is to move towards the greater ability to poke
around in the internals of the language. How about this: Lisp is known
as the programmable programming language; what we lack is a
programmable *compiler*. Imagine being able to define one's own code
generation optimizations when you have identified a bottleneck in your
program. Eventually a bank of many users' optimizations could be
collected together, resulting in something that might asymptotically
approach the fabled "sufficiently smart compiler".

However, such things can only be done when the language itself is
defined completely transparently from a small number of basic axioms.
As you say, source code often makes the best spec. It also gives
serious hackers the ability to get down and dirty into the internals of
the language.

Perhaps the compiler should be defined in the spec of the language;
that is, there exists a well-defined translation of source code to
primitive low-level constructs. (I don't mean anything like a
translation to a particular architecture, such as x86.) This should
allow the programmable compiler to become a realistic possibility.

One way to generate new ideas is to think of all the strangest things
we could possibly want to do, and make them possible. In one of your
essays, you said you wanted to iterate through the fields of a struct,
but Common Lisp wouldn't let you. That should be possible. What else
should be?

o Perhaps it should be possible to define (2 (pr "hi")) to print "hi"
twice. (Not that anyone would want to do that - or would they? - but
such a thing should, in principle, be possible. Note that this cannot
be done with a code walker since the number in the first position could
actually be a variable. Now that I think of it, a more realistic
suggestion would be for (2 (fn () (pr "hi"))) to print "hi" twice.
Nevertheless.)

o Perhaps it should always be possible to interrogate a closure, and
retrieve its code and its environment. (Yes, there exists
FUNCTION-LAMBDA-EXPRESSION. The point is, it's not guaranteed to work.)

o Perhaps it should be possible to define extremely high-level
optimizations as well as the low-level ones I mentioned. As an example,
consider automatically memoizing all functions determined to be purely
functional, or automatically compiling partially specialized versions
of functions (e.g. in a raytracer, a ray-sphere-intersect method
specialized for a certain sphere) when it is determined that this would
improve execution speed. Yes, we have methods to do things like this in
CL, but we don't have clean ways of making the magic happen on its own.
In CL, you have to *think* about doing either of these things.

This approach seems promising. It seems to me that Lisp-space is an
infinite domain in which we can see but a small distance away from
where we are standing. Even heading in the wrong direction is better
than stubbornly staying in the same place, although it seems many are
comfortable there and resent being poked by those who have seen a small
glimpse of the treasures that lie around them.

"I do not know what I may appear to the world; but to myself I seem to
have been only like a boy playing on the seashore, and diverting myself
in now and then finding a smoother pebble or a prettier shell than
ordinary, whilst the great ocean of truth lay all undiscovered before
me." - Isaac Newton

Tron3k

.

Relevant Pages

  • Re: WaitForSingleObject() will not deadlock
    ... represent an incorrect implementation of the language. ... the *compiler* does not guarantee this. ... but to state it in terms of the execution instead of the formal semantics of the language ... as long as the optimizations do not change the semantics of the language). ...
    (microsoft.public.vc.mfc)
  • Re: [EGN] Numerical Accuracy
    ... The advice worked because in fact the Microsoft compiler had a bug. ... The capabilities of the optimizer are not so ... The language standard itself says ... of "programming" as a nonprofession. ...
    (comp.programming)
  • Re: Learning C++?
    ... >> abide such rules or there are people who don't know the rules. ... > programming is excellent, and its object-oriented support is quite ... code, like Java or Ada or what else, but no language can prevent the ... This is also something the compiler should be ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Error message about my user defined type
    ... write a compiler that allow a true VB7 to run on the .Net platform ... > COM programming all day long. ... > wide available to any programming language who wants to use them. ... > other than using the CLR and the MSIL. ...
    (microsoft.public.vb.general.discussion)
  • Re: Error message about my user defined type
    ... the type lib delivers to the compiler all necessary information ... COM programming all day long. ... wide available to any programming language who wants to use them. ... CLR and the MSIL. ...
    (microsoft.public.vb.general.discussion)