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.
Bob
if (*ra4 != 0xffc78948) { return false; }
On 6 Feb 2012, at 16:28, Tom MacWright wrote:
> 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).
>
> The example you give is incorrect: the carto syntax will be something like
> #way { line-width: [lanes]; }, not #way { line-width: lanes; }, so #way {
> width: casing-width; } is invalid. If you want that behavior, you'd do #way {
> width: [casing] - [width]; }
>
> On Mon, Feb 6, 2012 at 11:18 AM, Thomas Davie <[email protected]> wrote:
> On 6 Feb 2012, at 15:47, Tom MacWright wrote:
>
> > > it makes parsing the language significantly harder
> >
> > 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 ').
>
> Previously, one could parse the MapCSS, using a rule along the lines of:
> evalSpecifier ::= 'eval' '(' 'String' ')';
> 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.
>
> Finally, I found that ambiguity that I suspected existed:
> way[highway]
> {
> width: casing-width;
> }
>
> 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.
>
> Personally, even if it weren't ambiguous, I would consider the eval('...')
> solution much cleaner anyway.
>
>
> _______________________________________________
> Mapcss mailing list
> [email protected]
> http://lists.openstreetmap.org/listinfo/mapcss
>
> _______________________________________________
> Mapcss mailing list
> [email protected]
> http://lists.openstreetmap.org/listinfo/mapcss
_______________________________________________
Mapcss mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/mapcss
