[plt-scheme] Context-specific namespaces

On Mon, Jan 09, 2006 at 03:57:22AM -0800, Noel Welsh wrote:
> How about we differentiate between variable and functions,
> and we can use a #' operator to turn the latter into the
> former?

Ah, the "But Scheme is a Lisp-1!" -argument. I did intend to say
something about it.

The difference to Common Lisp (and other Lisp-2's) behaviour is that
functions are first class values. Lisp-2 has two namespaces for what are
essentially the same things: names of run-time values. In contrast,
structure type names are bound to _expansion-time_ values that have no
run-time existence.

Of course, the same thing is true about macros: macros are
expansion-time values, yet they occupy the same namespace as run-time
values. But this is justified, since the syntactic context for macro
identifiers is almost exactly the same as for variable identifiers.

(Though one could argue that this is confusing and macro invocations
should be syntactically distinguished from function calls, but that is
neither here nor there...)

And, of course, mzscheme already has two distinct namespaces:

> (define-for-syntax foo 1)
> (define foo 2)
> foo
2
> (let-syntax ((bar (lambda (stx) (datum->syntax-object stx foo)))) bar)
1

I just want some more.

>   - the struct type value has uses outside of structures
> (e.g. pattern matching, introspection)

There is no "struct type value" (apart from the structure type
descriptor, which is not at issue here). If it were a _value_, it could
just be given an ordinary variable.

In any case, I don't see what your argument is. Yes, the struct type
identifier is used in other contexts besides define-struct, but in all
contexts the expander explicitly expects a struct identifier in that
position, and an ordinary variable is not allowed there. Likewise, a
struct identifier is not allowed anywhere where an ordinary variable is
expected.

>   - that way madness lies

So are you saying that e.g. C and ML are "mad" since they have distinct
namespaces for variables, type names and field names? You _can_ use this
to create obfuscated code (especially in C, where parsing is directed by
the symbol table, which is a _really_ bad idea), but in ordinary use it
doesn't create any problems. Is "x = p.x" mad?

In any case, you are free to dislike the idea. I'm not saying that the
standard PLT libraries should be changed (though I _would_ like it). I'm
just asking whether separating identifiers into multiple syntactic
contexts _can_ be done without resorting to prefix hacks.


Lauri