[Ur] Invalid Link expression (again)

[Adam Chlipala]

OK, I couldn't get your original code to work without implementing a 
fancier program analysis than I have time for now, but a simple 
variation does work.

It's necessary to remove the mutual recursion between [template] and 
[main'], which confuses the program analysis that justifies function 
specialization.  I changed your code to define [template] separately, 
without recursion, before [main'].  To do this, I added [main'] as an 
extra explicit argument to [template].

Even this requires a small patch to the compiler, which you can find now 
in the public Mercurial repository.

Your later message says that you decided that [template] shouldn't 
depend on [main'] anyway, in which case the whole original program might 
work now!  You wrote that the original error came back, which may be 
because there are arguments to [template] _before_ the first-class 
function argument that change across recursive calls.  Only prefixes of 
arguments are specialized at compile time, and it is important to get 
specialization here to remove run-time first-class functions, which are 
too hard to serialize safely in page links.

On 08/08/2013 05:24 PM, Sergey Mironov wrote:
> 2013/8/9 Sergey Mironov<grrwlf at gmail.com>:
>    
>> 2013/8/9 Adam Chlipala<adamc at csail.mit.edu>:
>>      
>>> On 08/08/2013 04:33 PM, Sergey Mironov wrote:
>>>        
>>>> Hi. I've run into the same problem when passing link generator as an
>>>> argument (see 'template' function at [1]). Is there any way to help Ur
>>>> in generating correct link without using functors? Maybe build<a></a>
>>>> explicitly using xml values like
>>>>
>>>> fun makeLink f =
>>>>     let a = xml ... black magic .. in a
>>>>
>>>> [1]  - https://github.com/grwlf/foocms/blob/master/tst/room2/main.ur
>>>>
>>>>          
>>>
>>> There's a good chance this will work fine if you just swap the order of the
>>> first two arguments to [template].  The compiler auto-specializes functions
>>> to statically known _prefixes_ of their arguments, so if the [state] isn't
>>> statically known, your current version will fail to get specialized to a
>>> form without first-class function arguments, while the swapped version might
>>> succeed.
>>>        
>> (sorry for not replying to all)
>>
>> No, no luck here. I've updated [1] to the version with arguments swapped
>>
>> *update*
>>
>> I've just noticed that my version of urweb was not the latest
>> (20120807). After updating to latest, urweb no longer unifies [1]. It
>> says (*see below*). Do we have some canges there ?
>>
>>
>> [grwlf at greyblade ~/proj/foocms/tst/room2 ]$ urweb -dbms sqlite -dumpTypes app
>> /home/grwlf/proj/foocms/tst/room2/main.ur:13:27: (to 13:33) Unification failure
>> Expression:
>> fn reload :
>>   {Lang : string} ->  transaction (xml ([Html = ()]) ([]) ([])) =>
>>   fn st : {Lang : string} =>
>>    fn body :
>>     {} ->
>>      tag<UNIF:U149::{Type}>  ([Html = ()])
>>       (([Body = ()]) ++<UNIF:U216::{Unit}>)<UNIF:U152::{Type}>
>>       <UNIF:X::{Type}>  =>
>>     ...
>>      
> Fix it by changing template's argument name from 'body' to 'b' helps,
> looks new compiler introduces some name clash. Original problem still
> exist. I can't use first-class function as a link expression.
>