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