New private names proposal

Dave Herman dherman at
Thu Dec 23 00:14:19 PST 2010

[having trouble with my phone. Trying again]

This doesn't have anything to do with new revisions of the names proposal. Every version, including the original, extended [[Get]] and [[Set]] and hence effectively overloaded the square bracket notation.


----- Original Message -----
From: Mark S. Miller <erights at>
To: Dave Herman <dherman at>
Cc: David-Sarah Hopwood <david-sarah at>, es-discuss at
Sent: Wed, 22 Dec 2010 23:56:46 -0800 (PST)
Subject: Re: New private names proposal
On Wed, Dec 22, 2010 at 11:30 PM, Dave Herman <dherman at> wrote:
> MarkM's desugaring doesn't look correct to me at all. Given that names can
> always be looked up in objects, regardless of whether they are bound with
> 'private', it is not amenable to simulation via local desugaring. You'd have
> to change the way square brackets are treated universally. Did you see my
> message about this earlier in the thread?
I agree. I have not revisited the [] issue specifically in light of the new
names syntax except for the section where I refer to the previous []
discussion as a kludge. (Just noting again that my "kludge" admission there
predates this thread.) Depending on what pair of syntax and semantics we
desire, if we do want to use [] with soft fields, then I agree -- you cannot
do so by desugaring. Instead, I would change the [[Get]] and [[Put]]
operations to test if their argument is a SoftField, in a precisely
analogous to how Names would change these to check whether the argument is a
Name. This would make SoftFields necessarily built-in rather than equivalent
to a library, just as Names are. I consider this a demerit but not fatal --
I prefer proposals that can be explained as equivalent to a library. YMMV.
Nevertheless, if we decide this use with square brackets is important, I
would not object to making this change to [[Get]] and [[Put]].
My current preference is that, rather than extend the use of [] for either
proposal, that we adopt some alternate syntax, such as sigils or @, that
preserves the analogy with public properties but maintains a distinction
between the two. This is not a deeply held or thought through position. I
look forward to an exploration of possible syntaxes. As several have
suggested, both publicly and privately (thanks), I no longer recuse myself
from syntax. But I will strive to keep these discussions separate until
someone shows a compelling coupling between the two.

More information about the es-discuss mailing list