On 11/28/2012 02:45 PM, Austin Seipp wrote:
As for the questions, here are some things I might hack on if they are
deemed OK:
1.) I would like to be able to have the Ur/Web compiler build basic .c
files.
Sounds completely reasonable, as it's an easy feature to ignore if unwanted.
I have an in flight patch that almost does this. It will add 2
directives to .urp files:
'CSource file.c'
[...]
'COptions ...'
Sounds reasonable, except that I'd prefer lowercase directive names, to
match the convention already in use for .urp files.
Awesome. I'll change the name to lowercase and try and get it emailed
in tonight. This is also the time for further bikeshedding over the
name of the option itself (coptions/csources,) before I submit the
patch. :)
'coptions' and 'csource' sound fine to me.
2.) Is it reasonable to support ad-hoc tags in the compiler, defined
by the user? Previously I proposed some tags as compiler patches, but
I realize this is inflexible. Instead, I would like to be able to
write a syntactic form similar to the basis library. Say:
tag audio : ...
I can support this easily with a small patch to allow tags to be defined in
FFI modules beside [Basis]. The core tags don't have actual implementations
anywhere, and it's easy to enable the same possibilities for tags in further
FFI modules. I.e., no need to define a C function returning a string. (The
identifier is used to figure out the tag name.)
Sound good?
This would be really great, and would make it easy to ship something
like a small library with HTML5 tags + full attribute support.
OK, I've just pushed that support, with a small new manual section
explaining it (and a small test case).
One extra request if it's not too much of a burden: in the default
case, I think using the identifier to infer the tag name is correct.
However, would it be too much to ask if I could also somehow specify
via FFI opts what the identifier desugars to?
[...more explanation...]
It'd be nice if instead I could just say 'val customTag : ...' and
then say customTag=audio in my urp file or something, and when I say:
<customTag attr1={...} .../>
I get:
<audio attr1="..." .../>
in the result.
You should be able to get this effect using Ur-level bindings, e.g. [val
customTag = audio] in a .ur file. The optimizer will inline all short
definitions of this kind, giving you the behavior you want, I think.
(Tag names are rendered to HTML after the optimizer has had a chance to
inline.)
In fact, I don't even know if you can refer to a tag by it's qualified
name when using XML syntactic sugar, so if this wasn't the case, you'd
not only have to fully qualify, you couldn't use the sugar.
Currently only identifiers in the top-level namespace can be referenced
with the literal XML syntax, though you can bring any FFI module into
that namespace with [open].
FYI, I have at least 1 other patch I'll throw up tonight when I get
home (which adds OpenSSL-powered base64 encoding/decoding to Basis.)
OK, that's probably reasonable, though I do start to worry about heading
toward a Huge Standard Library like a lot of scripting languages have,
and like I'd rather avoid.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
