[Ur] Ur record types as sets of fields

[Anthony Clayden]

Hi citizens of Ur,

A long while back, Adam responded in a discussion about Ur's record system  
http://blog.ezyang.com/2012/04/how-urweb-records-work-and-what-it-might-mean-for-haskell/#comment-3705

I'm wondering whether Ur's disjointness constraint might be used to build a 
record merge operator -- as needed for Relational Algebra Natural Join.

(I'm finding it a bit weird using `~` for disjointness: I'm so used to it being 
a type equality constraint in Haskell. So apologies if I stuff up. Also in the 
Ur materials I looked at, I don't see how to express type equality? For 
equality of record types I mean same set of field names, and same type of each 
corresponding field.)

Given two records of type t1, t2 with (some) fields in common, some private; 
let's chop their fields into projections:
t1' -- fields private to t1
t1_2 -- fields in common
t2' -- fields private to t2

Then we can say (treating `++` as union of fields): 
t1 is [ t1' ++ t1_2 ]; 
t2 is [ t1_2 ++ t2' ]; 
the result of Natural Join is [ t1' ++ t1_2 ++ t2' ].

We also require those projections to be disjoint: 
[ t1' ~ t1_2 ], [ t1' ~ t2' ], [ t1_2 ~ t2' ]

Those constraints uniquely 'fix' all those record types modulo ordering of 
names/fields in the records. Is that going to work?

It also feels weird using `++` for record union: again it strongly suggests 
Haskell's list concatenation, which is non-commutative. Perhaps Ur's `++` is 
non-commutative(?) It's the inbuilt semantics for `$( )`, `!` that make `++` 
commutative in effect(?)

Thank you
AntC___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur

Re: [Ur] RPC call line throwing error

[Adam Chlipala]

I like Benjamin's solution.  To me, it clearly leads to better code, 
even independently of this issue.  I always try to avoid querying SQL 
row data that won't be used.


The problem has to do with embedding of server-side values in 
client-side code.  The type [client] should only appear in server-side 
code, so it's proper for the compiler to signal an error when 
[client]-containing variable [row] is mentioned in a GUI event handler.  
The error message arises because this faulty embedding prevents the 
compiler from translating code to JavaScript, and therefore the code to 
get the mouse-event info remains in server-side code, which isn't 
allowed, because only client code can call that function.


Clearly not a nice error message, but I don't plan to fix it, per se.  I 
have longer-term plans to reimplement Ur/Web or a similar system in a 
nicer way that avoids the problem with static typing.


On 10/25/2017 10:33 PM, Benjamin Barenblat wrote:

On Tue, Oct 24, 2017 at 7:56 PM, Nitin Surana  wrote:

I'll really appreciate if someone can help us. It shouldn't take more
than a few minutes - https://github.com/urweb/urweb/issues/94

This took a bit more than a few minutes, and I'm still not entirely sure
what's going on, but I eventually figured out how to fix your particular
problem. I ran the compiler with the `-explainEmbed` flag, which gives
more information about errors like this, and got

 Can't embed
 loc:  peers.ur:20:20-21:3
   e:  UNBOUND_1.Peers.A
   t:  FFI(Basis.client)
 peers.ur:20:20: (to 21:3) Server-side code uses client-side-only identifier 
"Basis.mouseEvent"

So I tried changing your `onclick` handler to avoid capturing
`row.Peers.A` - i.e., I changed your `SELECT` statement to

 SELECT Peers.C FROM peers WHERE peers.A > {[me]} OR peers.A < {[me]}

and it compiled.

This is definitely a case of a bad error message, but there may be more
in play here. It sounds like the compiler is trying to evaluate the body
of the `onclick` handler on the server instead of on the client, which
seems wrong to me. This may also be related to Ur/Web's apparent
inability to handle client IDs on the client side [1]. In any case,
though, if anybody else has experienced issues like this, please speak
up.

As an unrelated aside, you can simplify your `SELECT` statement further
- Ur uses `<>` as the inequality operator, so you can say

 SELECT Peers.C FROM peers WHERE peers.A <> {[me]}

with the same semantics.

Best,
Benjamin


[1] https://github.com/urweb/urweb/issues/96

___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur



___
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur