On 9 Mar 2013, at 18:43, Martin Vonwald <[email protected]> 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. Agreed > 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. Thanks Tom Davie _______________________________________________ Mapcss mailing list [email protected] http://lists.openstreetmap.org/listinfo/mapcss
