[Ur] Several patches and questions

[Adam Chlipala]

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.