On 03/14/2015 08:55 AM, Gabriel Riba wrote:
El 13/03/15 a les 18:07, Adam Chlipala ha escrit:
Specially the type constructor "tag" it is confound with the value
"tag" (that builds up xml subtrees with specific tag) but the
different parameters they take augments the confusion.

The idea of separate namespaces for types and values is pretty common;
Ur/Web inherits it from SML.  You see the same thing with, e.g., class
constructors in C++.  I don't think it's inherently confusing, and
usually it even improves understanding, by avoiding the need to add some
extra nonsense prefix or suffix to an identifier for disambiguation.


I expressed my self wrongly. I just wanted to say that when things are complex to understand, the eyes go from one definition to the other incrementing mind boggling.

Namespaces are not mentioned in the manual.

Scope resolution rules /may/ reasonably be considered to be implicit in the typing rules from the manual, but I recognize that most Ur/Web users won't be familiar with the notation used there. The /real/ reason I don't feel bad about not giving more explicit explanation in documentation is that various places warn that it would be good to know ML (OCaml, etc.) before starting with Ur/Web. >:)

One easy-to-implement workaround is to use a /separate tag/ for nested
SVG, with a different name.  Then modify src/monoize.sml to add a
special case renaming that tag to <svg> in compiled code, for instance
by copying the code in the place that maps "tabl" to "table" right now.


If we change the main container tag (which appears only once) instead of the maybe many nested svg fragment tags, we will preserve fidelity to the specification for the majority of the code.

I propose <SVGML> for the main SVG container (since SVGIMG or SVGOBJ may suggest other tags attributes)

Since there is no legacy code base to be broken by any reasonable proposal for SVG, I'd be happy to accept a patch going whichever way sounds best to you.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Reply via email to