[Ur] Invalid Link expression (again)

[Sergey Mironov]

Confirm. The code really works with patched compiler. I've moved this
fixed and slightly enhanced example to

https://github.com/grwlf/foocms/tree/master/tst/first-class-link-expr-5

The final step towards true real-world use-case is to teach the
compiler to descend into the records which contain functions. That is
needed because template function often has many tweakable arguments
and the record is the best place for them since we don't need to fix
all the calls to template when add or delete another parameter. I've
tried a hack - 'unpack' the record before passing it to real_template,
but no, only direct arguments are valid currently. Is it hard to add
such feature? My failed record-based approach is here:

https://github.com/grwlf/foocms/blob/master/tst/first-class-link-expr-6

Regards,
Sergey

2013/8/10 Adam Chlipala <adamc at csail.mit.edu>:
> 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.
>>
>
>