[plt-scheme] Identity of literals in macros

On Fri, Mar 03, 2006 at 10:31:14AM -0800, Ryan Culpepper wrote:
> When a subterm of a macro's input can be *either* a normal
> expression/definition *or* a new tagged thing (the second use above),
> then define the keyword as an error-raising macro and use
> module-identifier=? for comparison.

> By that rule, Scheme's "unquote" needs to be defined as syntax, and
> you should not rebind it.

No, unquote cannot appear in expression context: it appears inside a
quotation, in a literal datum context.

> Also, "else" should have been defined as syntax, too, because it
> occupies the same context as other expressions. The contract system's
> "any", though, is perfect the way it is; it prevents you from defining
> your own "any" contract that never gets used because the contract
> system magically interprets "any" as something else.

You're right: "any" can indeed be used in the same position as an
expression can, so my argument about disjoint contexts was false.

Incidentally, following the same principle, => (for cond) should also be
special syntax, since it appears in a context where an expression could,
too. However, currently it is not bound in the mzscheme module and the
cond macro uses the top-level identifier.

But apart from unquote your point is good. I guess I'll just have to
accept that special literals that may appear in expression contexts have
to be treated as identifiers that may need to be renamed at times.

It seems to me, though, that in the PLT Scheme community there's no
established principle for the naming of exported identifiers. In ML, for
instance, the convention is that each module uses short names that are
unique only within that module, and you're expected to always import
modules with some prefix to avoid collisions. And in languages like C,
where there's no module system, identifiers are named carefully to make
them globally unique.

Scheme, however, is slowly evolving from a moduleless language to one
with modules, and the naming doesn't follow any real principle:
identifiers are usually named so that they'll be reasonably unique even
if imported without prefixes, but there's no real effort to guarantee
this.

So we have the traditional "length" and "vector-length" while SML has
List.length and Vector.length that may be easily abbreviated to e.g.
L.length and V.length, whereas there's no way to abbreviate the Scheme
functions whose name starts with vector-.

Likewise, contract.ss has lots of identifiers with /c suffixes so they
can be imported without prefixes without mixing them with their
suffixless counterparts, and we cannot get rid of the suffixes. But then
there's a name like "any" which of course conflicts easily with some
other import, and then we have to use a prefix. It's the worst of both
worlds.

Personally, I think that since we have a module system, the ML style is
the way to go: get rid of all direct "C-style" prefixes like vector- or
string-, and move the identifiers without prefixes to separate modules
which may then be imported with whatever prefixes the importer deems
suitable.


Lauri