Re: Woohoo! My macros are now (semi) hygienic

On Feb 23, 8:50 am, Ron Garret <rNOSPA...@xxxxxxxxxxx> wrote:
In article
<31ee5725-d999-4306-9ce0-114e2e3fa...@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
"Leslie P. Polzer" <leslie.pol...@xxxxxxx> wrote:

Could you make up a quick comparison of what package problems it will
solve?

There are two main problems (or maybe I should call them annoyances)
with packages that Lexicons were designed to solve:

1. The need to manually build and maintain exported symbol lists

Automatically bringing together arbitrary symbols from different
namespaces into one scope is braindamaged. Only in rare situations
where the source namespace is very stable can you do a wholesale
import of its bindings without naming the specific names that you
want.

It sounds like you're basically reinventing something which has the
semantics of the Modula-2 WITH statement.

VAR foo : foo_record, bar : bar_record;

WITH foo DO
WITH bar DO
(* ... access members of bar and foo using short names ... *)
END;
END;

Above, there is also no need to maintain any export lists. Why?
Because all of the members of a record are considered ``exported''
under the WITH operator. When you add a new member to the record type
definition, it's automatically visible in all WITH statements which
involve that record type, everywhere in the program. Both foo_record
and bar_record each in fact constitute a lexicon where certain names
have bindings; these are instantiated in the instances instances foo
and bar. Thus WITH performs an import of these namespaces into the
current scope.

Suppose foo has a member x that you access in the DO block, and bar
doesn't have any member called x. So in that lexical scope, the name x
refers to foo.x. Suppose that someone now edits the type definition of
bar_record such that it acquires a member called x. Now when you
recompile the WITH statement above, the expression x suddenly refers
to bar.x! If bar.x is suitably typed, there will be no compiler
error. Unintentional shadowing of a local variable can also take
place: bad hygiene.

Modula-3 has a completely different WITH, a sane form which resembles
SYMBOL-MACROLET. The Modula-3 with creates lexical aliases for
expressions; only those names are introduced into the scope which are
explicitly listed in the WITH construct.

It's C++ that's carrying the torch now for the braindamaged WITH, in
the form of class scope.

int x;

int abc::foo()
{
// ``lexicon'' of abc class ``imported'' here.
return x + y; // y is abc::y, x is ::x.
}

If class is edited so that x is a member, now the expression returns
the member x. If you want the global x, you have to discover this
problem and then add the qualification ::x. You can also be clear that
you really want the member by writing this->x or abc::x.

Python and CL get this right; the object is passed explicitly, and you
write some expression that requests its member explicitly. No
automatic lexicon-munging.

The Common Lisp WITH-SLOTS is also sane, since you explicitly list the
bindings that you are importing.
.

Relevant Pages

  • Re: Woohoo! My macros are now (semi) hygienic
    ... with packages that Lexicons were designed to solve: ... namespaces into one scope is braindamaged. ... mean you don't have any control of the visibility of bindings. ... Suppose foo has a member x that you access in the DO block, ...
    (comp.lang.lisp)
  • Re: Why connot declare a static member of STRUCT or UNION?
    ... scope, or function prototype scope. ... but a member of that object to have internal linkage (or vice ... the struct definition is visible. ... dynamically allocated instance is free'd, ...
    (comp.lang.c)
  • Re: Getters and setters
    ... A read-only member should have no setter. ... In this case they should be read-only in the public contract. ... of the record type which can be read/written as a whole. ...
    (comp.object)
  • Re: LDAP Query Members
    ... Search Base: Whereever you know that the group is under, if you know the dn for ... Search Scope: Depends on base ... Filter: ... attribute to return: member ...
    (microsoft.public.exchange2000.active.directory.integration)
  • Re: CLass members; public, private, protected and ???
    ... > member scope in classes. ... > class abc { ... I see friend functions used frequently in responses to your original ...
    (comp.lang.cpp)