[Ur] Minimal modification to Crud1: Moved a `@foldR` call *before* the `return`, no longer compiles.

Ziv Scully ziv at mit.edu
Mon Aug 31 13:02:33 EDT 2015


I see two problems at least:

1) The type signatures (e.g. [colMeta] in the .urs file) haven't been
updated to reflect the fact that the widget field will be a transaction.

2) The accumulating function passed to [foldR] doesn't treat its arguments
like transactions. What you have now stitched together xml fragments, but
we really want to string together transactions and stitch together the
resulting xml. This will look something like this:

fn xTrans accTrans =>
  x <- xTrans;
  acc <- accTrans;
  return <xml>{x}{accTrans}</xml>

The above code is a sketch. In particular, it doesn't deal with the
possibly different types (e.g. you probably need a [useMore] somewhere).

A completely different approach might use something like Monad.exec or
Monad.foldR. The latter may be a particularly good fit, but I haven't used
it before. (You can find type signatures for these in lib/ur/monad.urs in
the Ur/Web directory).


On Monday, August 31, 2015, Stefan Scott <stefanscottalexx at gmail.com> wrote:

> [Note: The following message can also be seen as a README on GitHub - with
> better formatting: https://github.com/StefanScott/UrWeb-Crud1-move-foldR ]
>
> I am attempting make a minimal modification to the Crud1 demo, by moving
> the call to `@foldR` in `list()` to *before* the `return` statement.
>
> The modified version now gives a kind unification error, apparently
> involving the 2nd argument to `@foldr` - `[ fn cols => xml form [] (map snd
> cols) ]`.
>
> I am trying to figure out how such a minimal modification could result in
> a compile error.
>
> The "diff" between the "before" and "after" can be seen at this link -
> also excerpted here below:
>
>
> https://github.com/StefanScott/UrWeb-Crud1-move-foldR/commit/04ca85962a5c95e8144c6e2a29df729d631b6187#diff-74e1ef1a69438025793099ad624ad8bcR63
>
> BEFORE:
>
>   return <xml> (* <= the `return` *)
>   ...
>   {@foldR  (* <= call to `@foldR`, will be moved *above* the `return` *)
>       [ colMeta ]
>       [ fn cols => xml form [] (map snd cols) ]
>       ( fn [nm :: Name] [t ::_] [rest ::_] [[nm] ~ rest] (col : colMeta t)
> acc =>
>         <xml>
>           <li> {cdata col.Nam}: {col.Widget [nm]}</li>
>           {useMore acc}
>         </xml> )
>       <xml/>
>       M.fl
>       M.cols}
>   ...
>   </xml>
>
> AFTER:
>
> formFields <- @foldR (* <= call to `@foldR`, now moved *above* the
> `return` *)
>   [ colMeta ]
>   [ fn cols => xml form [] (map snd cols) ]
>   ( fn [nm :: Name] [t ::_] [rest ::_] [[nm] ~ rest] (col : colMeta t) acc
> =>
>     <xml>
>       <li> {cdata col.Nam}: {col.Widget [nm]}</li>
>       {useMore acc}
>     </xml> )
>   <xml/>
>   M.fl
>   M.cols;
>   return <xml> (* <= the `return` *)
>   ...
>   {formFields} (* <= call to `@foldR` was originally here *)
>   ...
>   </xml>
>
> I created a GitHub with just 2 commits, to illustrate the modification:
>
>   - commit 0: the original Crud1 (simplified to only do SELECT and
> INSERT);
>
>   - commit 1: the modified Crud1 - now, in function `list()`, the call to
> `@foldR` which computes the form fields has been moved to *before* the
> `return`. This gives following compile error:
>
>
> https://github.com/StefanScott/UrWeb-Crud1-move-foldR/blob/master/ERR.001.crudWidgetTxn1.ur
>
> The modified version gives a kind unification failure:
>
>   Have con:
>
>   xml ([Dyn = (), Body = (), Form = ()]) ([])
>    (map (fn t :: (Type * Type) => t.2) M.cols)
>
>   Need con:
>
>   <UNIF:U408::Type -> Type> <UNIF:U409::Type>
>
>   Kind unification failure
>
>   Have:  {Type} -> Type
>   Need:  Type -> Type
>
> This appears to involve the second argument to `@foldR`, which is:
>
>   [ fn cols => xml form [] (map snd cols) ]
>
> I thought that merely moving a chunk of code before a `return` statement
> like this wouldn't change much, so I don't understand what might be causing
> this kind unification failure in the modified version.
>
> Thanks for any help!
>
> ###
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20150831/5749a16e/attachment.html>


More information about the Ur mailing list