[r6rs-discuss] [Formal] Replacing the import's "for" syntax with implicit phasing

From: Felix Klock <pfr6rs>
Date: Fri Nov 17 01:38:33 2006

On Nov 16, 2006, at 9:21 PM, Abdulaziz Ghuloum wrote:

>
> On Nov 16, 2006, at 12:50 PM, Felix Klock wrote:
>
>> On Nov 15, 2006, at 1:03 AM, Abdulaziz Ghuloum wrote:
>>
>>> Now that we have defsyntax, we can use it in another library:
>>>
>>> (library definlined
>>> (export definlined)
>>> (import (for defsyntax ???))
>>> (defsyntax#0 (definlined name value)
>>> (defsyntax#1 (name) value)))
>>>
>>> Spend a minute or two to try to puzzle out the import phases for
>>> defsyntax.
>>
>> My initial thought is that the import phase for defsyntax is just
>> 'run'; yes, defsyntax appears in the right hand side of the macro
>> definition of definlined, but only as part of something that is
>> going to go into the produced code when the use of definlined is
>> expanded, not something that is going to be run at expansion time
>> of definlined.
>
> I believe you are right--it could've been just 'run'; I think,
> though I don't remember my initial reason. Maybe my mind was out
> of phase at that time! But now that my phases are inferred
> correctly, I don't have to worry anymore. :-)

Okay, so I think we agree that this example could have been just
(import (for defsyntax run)). The compilation of D is much simpler
than we thought, yada yada yada.

This means that, at the moment:

1.) Your formal comment does not have an example of your first
difficulty:
        "** The phased model fails to capture the users' intentions"
The onus is on you to provide a new example of this issue.

2.) I agree with your second difficulty:
        "** Macro helpers are unexpressible"
and I agree that this should be fixed.

But this issue does not justify the introduction of phase inference;
that is like saying "The simply-typed lambda calculus can't express
polymorphic functions. Let's fix it by adding type inference." Why
is this response incorrect? Because if all you do is infer the same
simple types you had before, you haven't fixed the problem. The
solution is to extend the type language with a polymorphic type
constructor!

In general, when the problem is insufficient inexpressiveness, then
you should first deal with the expressiveness problem directly.

If the solution to the expressiveness problem involves the addition
of unwieldy syntactic constructs in order to be able to express what
we want, then sure, we should attack the problem of inferring those
constructs. But we need to agree on the semantics of the library
construct; I would prefer that we finish that job before attacking
surface syntax issues, if possible.

3.) As for your third difficulty:
        "** Manual derivation of import phases is complex"
we have direct evidence that it can be subtle, in the form of the
mistake that you made in your first example.

I do think that the semantics of phases are not specified in a
sufficiently clear manner in R^{5.91}RS. I get a better idea of what
phases are for when reading Flatt's "Composable and Compilable
Macros" paper [1]. This as a sign that the text related to phases
needs revision, independently of whether phase inference is added.
(It might also be a sign that the semantics of phases needs revision,
which is a related but distinct issue.)


As for my opinion on your formal comment:

I strongly prefer that R6RS retain the ability of a developer to
express explicitly which phase a library is to be imported at, rather
than switch to a model where all phases are only implicitly specified.

Continuing with the analogy to languages with type inference: I do
not like working with languages that do not allow me to write down
the type I expect an expression to have. If I want to write a type
expression down, the system should allow me to do so, and then check
that the type I have written is appropriate [2].

I am ambivalent about whether phase inference should be introduced as
an option for those who want to use it. But I am not convinced that
explicit phase specification should be removed entirely.

-Felix

[1] Question for the editors: why was Flatt's paper not referenced in
section 6.2? The only reason I can think of is that the system of R^
{5.91}RS does not exactly match that of his paper; but the paper
still offers valuable intuitions about why anyone might care about
phases.

[2] Being able to write down type expressions explicitly can help
narrow down where the source of type error occurs during the checking
process. I would not be surprised if a similar issue arises with
trying to debug macro definition bugs when using Aziz's phase-
inferring prototype, but obviously I will not be able to justify that
claim with a concrete example until after I have had a chance to work
with Aziz's prototype system.
Received on Fri Nov 17 2006 - 01:37:26 UTC