[racket-dev] A basic package system

On Thu, Jul 28, 2011 at 12:35 AM, Jay McCarthy <jay.mccarthy at gmail.com> wrote:
> On Wed, Jul 27, 2011 at 8:12 PM, Carl Eastlund <cce at ccs.neu.edu> wrote:
>> On Wed, Jul 27, 2011 at 11:32 AM, Eli Barzilay <eli at barzilay.org> wrote:
>>> 10 minutes ago, Robby Findler wrote:
>>>> They have more similarities than your message suggests I believe.
>>>> And it is probably worth exploring that.  As far as I can see a
>>>> facet/modulet has less stuff than a package and possibly a different
>>>> story vis a vis files in the filesystem.
>>>
>>> They're really unrelated -- the new thing with
>>> facets/modulets/whatever name they get is a kind of a separately
>>> loadable sub-module.  What we were talking about is basically making
>>> the `foo' in (require foo) be an identifier that you could define to
>>> actually point to some random file.
>>
>> Would a binding for foo affect uses like foo/bar?  And would this mean
>> going to a semantics for require specs where unbound identifiers have
>> one meaning, and bound identifiers have another?  That leads to issues
>> with silent failures, where you try to refer to a binding but a typo
>> leads to the wrong require instead of a syntax error.  Also, right now
>> I can do (define racket "Racket") and then (require racket) and it
>> works fine.  If require starts looking at bindings, suddenly the
>> collection namespace becomes part of the normal Racket namespace.
>
> I just want id-require-transformers. Right now we have
> require-transformers but there's no reason we couldn't/shouldn't have
> id macros too.

I would say that the silent failure mode is a reason not to.  The only
other place I can think of where we allow both bound and unbound
identifiers, and interpret them differently, is syntax templates.  I
don't think of a require spec as a template -- mostly data with a few,
special, overriding references -- I generally expect each name to have
a single unambiguous meaning.

> (define racket "Racket") is not problem because it's a phase-0,
> non-require-transformer binding.

Require transformers are at phase 0, too.  Or are you suggesting that
we interpret bound names if they are require transformers, but not if
they're something else?  Once again, only templates behave that way.
It would be very odd to me to treat require specs as mostly data, with
a few special, overriding bindings, rather than as a type of
expression where each name has a single meaning.

> Using these macros this way is just a nice way to implement the
> package system. It's not really a new feature (as my example shows...
> we already have it.)

We already have require macros for application positions because all
application positions in require specs are interpreted as bindings.
All identifier-only positions are interpreted as data and used as
collection names.  In general, Racket macros avoid mixing data and
expressions (anything that interprets bindings), because it leads to
very confusing behavior.  This is similar to why cond has a binding
for else rather than using its symbolic name, and even more directly
similar to why match does not have id transformers either.

--Carl