Re: Sacla loop: a new loop implementation

From: Antonio Menezes Leitao (Antonio.Leitao_at_evaluator.pt)
Date: 10/19/04 

Date: Tue, 19 Oct 2004 09:19:44 +0100

Gareth McCaughan <gareth.mccaughan@pobox.com> writes:

> A good CL compiler (CMU CL, say) can do a *lot* of type
> inference. Sometimes it can work out a lot about what type
> something has, sometimes not. What it's able to work out
> is enough to let it produce some very decent code, even
> without explicit type declarations.

We agree on that.

> So we have an example of a system where not-always-available
> type information is helpful. Why do you "seriously doubt"
> that there might be other examples?

If we return to the original issue that started this subthread, we
will remember that we were looking for a macro that could encapsulate
different iteration forms without requiring the creation of iterator
objects or closures. For this to be possible, I still don't see any
way without demanding that the necessary type information is available
at compile time. Now, given the multitude of different ways that we
can use in Common Lisp to produce an object that we want to iterate
(e.g., on a local variable, from a function parameter, the dynamic
value of a special variable, the result of a yet unknown function
call, the result of a read operation, the result of a generic function
call, etc), I'm afraid that not even the most clever type inference
mechanism available in Common Lisp will be able to always produce the
necessary information for the macro to expand. I suspect (based on my
own, obviously limited, experience) that this will be a frequent
situation.

Now, we all agree that it is possible to expand according to the lack
of type information but that will require that our iterator macro must
be able to expand into something that will decide at run time. If the
macro writer still wants to avoid iterators or closures he might
choose an expansion that uses a typecase form or some such. The
interesting thing is that if there was type information available that
would allow him to not expand into the typecase, that exact same
information is available now to the normal code optimization phases of
compiler and it can achieve the same effect on the typecase form.
Given the fact that code optimization is done at a latter phase than
macro expansion I also suspect (based on my own, obviously limited,
experience) that there will be more type information available that
will allow it to make a better job.

> You've used the term "statically typed language" a lot,
> and you've defined it in terms that are ambiguous because
> a crucial quantifier is missing. Could you please say
> which of the following (if any) is your definition?
>
> 1 "A language in which type information is always
> available at compile time"
>
> 2 "A language in which type information is usually
> available at compile time"
>
> 3 "A language in which type information is often
> available at compile time"
>
> 4 "A language in which type information is sometimes
> available at compile time, no matter how rarely"
>

I guess that point 1 is the most appropriate definition. I do
consider the following definitions:

A statically typed language is a language where types are known at
compile time. A dynamically typed language is a language where types
are discovered at runtime.

Obviously, there are languages that can be both statically and
dynamically typed (Common Lisp is one example). All I'm saying is
that to have useful type information available at macroexpansion time
in general, your language or (as Duane already pointed it out) the
programs that you can write in that language must be statically typed,
at least, in the fragments that use those macros.

I think the best thing I can do now is to shut up and wait until those
macros are available. I'll then see what kind of restrictions they
will entail.

Thanks for your comments,

António Leitão.

Relevant Pages

  • Re: Sacla loop: a new loop implementation
    ... >> portably in common lisp, because the facilities just aren't there. ... No, macro expansion is a macroexpand-time operation, which occurs at ... > information must be produced at compile time. ... type information. ...
    (comp.lang.lisp)
  • Re: Sacla loop: a new loop implementation
    ... the compiler is able to deduce enough about the type of thing ... That requires only that type information is *sometimes* ... > necessary information for the macro to expand. ... "statically typed language". ...
    (comp.lang.lisp)
  • Re: Sacla loop: a new loop implementation
    ... > No, macro expansion is a macroexpand-time operation, which occurs at ... I'm more concerned with the compile time. ... > type information. ...
    (comp.lang.lisp)
  • Re: Sacla loop: a new loop implementation
    ... > the impression that you wanted a macro which expands into different ... > impossible in general due to lack of type information at compile time ...
    (comp.lang.lisp)
  • Re: Sacla loop: a new loop implementation
    ... > information must be produced at compile time. ... > useful type information at compile time, then you are working with a ... > statically typed language. ...
    (comp.lang.lisp)