[Ur] Abstract type for 'id' attributes?

Adam Chlipala adamc at impredicative.com
Wed Aug 31 20:03:51 EDT 2011


Karn Kallio wrote:
> On Tuesday, August 30, 2011 06:45:10 PM Adam Chlipala wrote:
>    
>> Currently, Ur/Web supports an 'id' attribute on any XML element.  I
>> added this when someone requested support for the<label>  tag.
>>
>> Currently, 'id' attributes have type [string].  This freaks me out
>> somewhat, since it's anti-modular; different functions written by
>> different people might need to coordinate to avoid duplicating IDs.  The
>> use of IDs is convenient for FFI JavaScript code that wants to get
>> handles to DOM nodes.
>>
>> So, I'm thinking of adding an abstract type of IDs, with only one
>> built-in operation: "generate fresh ID."  Every tag's 'id' attribute
>> would change to take a value of this type.  Under the hood, these would
>> just be strings, making for easy FFI integration.
>>
>> Does anyone object to the idea?  Any other feedback?
>>      
> No objection, I think it is a good idea.  For integration with external CSS
> and FFI Ecmascript, would it be possible to have a second operation that takes
> a "suggestion" string and generates an id having that as the under the hood
> value if it is not already taken?  Already taken "suggestions" then cause an
> error if given again, or alternatively are ignored or modified.  Without some
> sort of mechanism for controlling or mapping id string values I think it will
> generally be impossible to use external resources (eg style sheets on another
> server or under control of some other team).
>    

Stylesheets don't need to mention IDs; you can do everything you can do 
with IDs using "singleton classes."  So, presumably you're talking about 
integrating with stylesheets not written with the Ur/Web application in 
mind.  I wasn't planning to make an effort to support that.

Allowing arbitrary string values suggested by the programmer 
significantly complicates a sound implementation.  If IDs are abstract 
in the Ur semantics, then IDs can be generated with a simple counter.  
That's my current plan.



More information about the Ur mailing list