On 9/4/10 9:20 AM, Jonathan S. Shapiro wrote: > On Fri, Sep 3, 2010 at 9:29 PM, wren ng thornton<[email protected]> wrote: > >> In particular, it's fine to define >> the *function* _+_ by saying it's equal to add (and then >> specifying/relying on inlining to remove the indirection); but having >> _+_ belong to a separate ontological category from add is just begging >> for problems. > > I tend to agree. Unfortunately there is a moderately bad problem with this: > it ties the name of the syntactic element to the name of the function. > > So now, if I want to define a completely new syntax in which _+_ means > something else entirely, I get tied up in namespace issues...
That's part of the reason I brought up Dyna. Since you're already planning on having modules that can be "opened" into the local context, doesn't that subsume syntax tables? A syntax is just (the names for) a collection of operations; a module is just a collection of operations[1]. If you want _+_ to mean something different in the current context, then just define a local _+_ and don't open import the _+_ from other modules--- use the non-local versions with qualified names instead. If you want a local non-qualified name you can always define something like _<+>_ = M._+_ or _++_ = M._+_ or whatever. [1] In both cases taking "operation" to mean functions, constants, types (which are just type-level functions or constants),... -- Live well, ~wren _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
