On Tue, Mar 12, 2013 at 3:17 AM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 2013-03-12, at 02:26, Colin Putney <colin at wiresong.com> wrote:
>
> > On Mon, Mar 11, 2013 at 5:59 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> >> No.  Its arguably a bug but a binding will print itself as the Symbol
> key.  So what's happening is that the binding for DateAndTime is printing
> itself as #DateAndTime.  So the problem is that the Decompiler is not
> mapping the sequence pushLiteral: aBinding, send #value back into an
> appropriate LiteralVariableNode instance.  The Decompiler needs to
> special-case this.
> >>
> > Yeah, that should probably be fixed. The new Alias bindings will
> generate #value sends, which I don't think we've used before. (We've used
> #value: for assignment to globals, but not #value for reads.)
>
> Isn't #value too general to serve as a specially treated token in the
> decompiler? It might easily appear in code.
>

No.  The way the decompiler works when value is sent there is a ParseNode
on the stack.  The only context in which the ParseNode can be a kind of
variable binding is in the case where #value and/or #value: is being sent
to a global variable.   In all other cases it'll be some other kind of node.


>
> I'd think it would be better if the compiler emitted a unique message
> selector that the decompiler could reliably recognize. Maybe #pvtValue,
> which cannot be used in regular code anyway?
>

No need.
-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130313/f957e06d/attachment.htm