<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Well, this is assuming that you bring in the changes you were proposing too, which don't look too bad. I had been addressing Paul's points primarily.<div><br></div><div>Bob<br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div><span class="Apple-style-span" style="font-family: Arial; "><pre>if (*ra4 != 0xffc78948) { return false; }</pre></span></div></span>
</div>
<br><div><div>On 6 Feb 2012, at 16:28, Tom MacWright wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hmm, okay - I get that it makes some sense to separate eval syntax from language syntax, though I'm not going that route personally (as to better validate operations, rather than have vague eval errors coming from Mapnik).<div>
<br></div><div>The example you give is incorrect: the carto syntax will be something like <span style="">#way { line-width: [lanes]; }, </span><span style="">not </span><span style="">#way { line-width: </span><span style="">lanes; }, </span><span style="color:rgb(34,34,34);font-family:arial,sans-serif">so </span>#way { width: casing-width; } is invalid. If you want that behavior, you'd do #way { width: [casing] - [width]; }</div>
<div><span style=""><br></span></div><div><div class="gmail_quote">On Mon, Feb 6, 2012 at 11:18 AM, Thomas Davie <span dir="ltr"><<a href="mailto:tom.davie@gmail.com">tom.davie@gmail.com</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 6 Feb 2012, at 15:47, Tom MacWright wrote:<br>
<br>
> > it makes parsing the language significantly harder<br>
><br>
> Could you be more specific there? I don't see much of a difference. In fact, [ and ] are almost direct stand-ins for tag(' and ').<br>
<br>
</div>Previously, one could parse the MapCSS, using a rule along the lines of:<br>
evalSpecifier ::= 'eval' '(' 'String' ')';<br>
you could then take the string, and run a seperate parser over it, allowing the behaviour of MapCSS and the behaviour of eval to be 100% independent, you did not need to worry about tokenising eval constructs while dealing with MapCSS, instead just a string; etc.<br>
<br>
Finally, I found that ambiguity that I suspected existed:<br>
way[highway]<br>
{<br>
width: casing-width;<br>
}<br>
<br>
Is this text is set to the value of casing-width, or is it set to the value of casing minus the value of width? The fact that - and + are admissable in identifiers makes this ambiguous.<br>
<br>
Personally, even if it weren't ambiguous, I would consider the eval('...') solution much cleaner anyway.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
Mapcss mailing list<br>
<a href="mailto:Mapcss@openstreetmap.org">Mapcss@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/mapcss" target="_blank">http://lists.openstreetmap.org/listinfo/mapcss</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>Mapcss mailing list<br><a href="mailto:Mapcss@openstreetmap.org">Mapcss@openstreetmap.org</a><br>http://lists.openstreetmap.org/listinfo/mapcss<br></blockquote></div><br></div></body></html>