<br><br><div class="gmail_quote">On Tue, Mar 12, 2013 at 3:17 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2013-03-12, at 02:26, Colin Putney <<a href="mailto:colin@wiresong.com">colin@wiresong.com</a>> wrote:<br>
<br>
> On Mon, Mar 11, 2013 at 5:59 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
>> 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.<br>
>><br>
> 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.)<br>
<br>
</div>Isn't #value too general to serve as a specially treated token in the decompiler? It might easily appear in code.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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?<br></blockquote><div><br></div>
<div>No need.</div></div>-- <br>best,<div>Eliot</div>