[Mapcss] Development of MapCSS?

Tom Davie tom.davie at gmail.com
Sat Mar 9 19:20:43 UTC 2013

On 9 Mar 2013, at 18:43, Martin Vonwald <imagic.osm at gmail.com> wrote:
> Shouldn't the design philosophy be targeted at the use-cases?

Yes, and the use case here is a language that can apply styles to map objects rapidly.  An absolute requirement for that is the ability to run the stylesheet in parallel, and hence referential transparency.  Imperative languages simply can not do this job.

>> MapCSS is a declarative language.  That means, you say "given this input, the result is this", not "to compute the result from this input do this then this then this".  This has significant benefits to implementors, and to clarity of stylesheets.  If you want to invent MapJavascript, do so, but MapCSS is not the place to put it.
> I don't want to invent MapJavascript. I - and I guess some others -
> need more processing power. Why should we invent something new (did I
> already mention I don't like to reinvent the wheel again?) instead of
> taking something that works and add what is needed?

Because what you think works, does not work in this instance.
>> For reference, OpenStreetPad already supports nested selectors, allowing you to do things like this (in a declarative form):
>> .........
> Nice but too less.


> Where are loops and arrays?

We do not need loops – instead, functions, and recursion are able to do everything needed here while maintaining referential transparency.  That is, what's needed is an extension to the eval syntax, not an imperative language embedded in a declarative one.


Tom Davie

More information about the Mapcss mailing list