summaryrefslogtreecommitdiff
path: root/doc/manual.tex
blob: 72360bb8a66770e95d556e86e085767a60a42a00 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
\documentclass{article}
\usepackage{fullpage,amsmath,amssymb,proof,url}

\newcommand{\cd}[1]{\texttt{#1}}
\newcommand{\mt}[1]{\mathsf{#1}}

\newcommand{\rc}{+ \hspace{-.075in} + \;}
\newcommand{\rcut}{\; \texttt{--} \;}
\newcommand{\rcutM}{\; \texttt{---} \;}

\begin{document}

\title{The Ur/Web Manual}
\author{Adam Chlipala}

\maketitle

\tableofcontents


\section{Introduction}

\emph{Ur} is a programming language designed to introduce richer type system features into functional programming in the tradition of ML and Haskell.  Ur is functional, pure, statically-typed, and strict.  Ur supports a powerful kind of \emph{metaprogramming} based on \emph{row types}.

\emph{Ur/Web} is Ur plus a special standard library and associated rules for parsing and optimization.  Ur/Web supports construction of dynamic web applications backed by SQL databases.  The signature of the standard library is such that well-typed Ur/Web programs ``don't go wrong'' in a very broad sense.  Not only do they not crash during particular page generations, but they also may not:

\begin{itemize}
\item Suffer from any kinds of code-injection attacks
\item Return invalid HTML
\item Contain dead intra-application links
\item Have mismatches between HTML forms and the fields expected by their handlers
\item Include client-side code that makes incorrect assumptions about the ``AJAX''-style services that the remote web server provides
\item Attempt invalid SQL queries
\item Use improper marshaling or unmarshaling in communication with SQL databases or between browsers and web servers
\end{itemize}

This type safety is just the foundation of the Ur/Web methodology.  It is also possible to use metaprogramming to build significant application pieces by analysis of type structure.  For instance, the demo includes an ML-style functor for building an admin interface for an arbitrary SQL table.  The type system guarantees that the admin interface sub-application that comes out will always be free of the above-listed bugs, no matter which well-typed table description is given as input.

The Ur/Web compiler also produces very efficient object code that does not use garbage collection.  These compiled programs will often be even more efficient than what most programmers would bother to write in C.  The compiler also generates JavaScript versions of client-side code, with no need to write those parts of applications in a different language.

\medskip

The official web site for Ur is:
\begin{center}
  \url{http://www.impredicative.com/ur/}
\end{center}


\section{Installation}

If you are lucky, then the following standard command sequence will suffice for installation, in a directory to which you have unpacked the latest distribution tarball.

\begin{verbatim}
./configure
make
sudo make install
\end{verbatim}

Some other packages must be installed for the above to work.  At a minimum, you need a standard UNIX shell, with standard UNIX tools like sed and GCC in your execution path; and MLton, the whole-program optimizing compiler for Standard ML.  To build programs that access SQL databases, you also need libpq, the PostgreSQL client library.  As of this writing, in the ``testing'' version of Debian Linux, this command will install the more uncommon of these dependencies:

\begin{verbatim}
apt-get install mlton libpq-dev
\end{verbatim}

It is also possible to access the modules of the Ur/Web compiler interactively, within Standard ML of New Jersey.  To install the prerequisites in Debian testing:

\begin{verbatim}
apt-get install smlnj libsmlnj-smlnj ml-yacc ml-lpt
\end{verbatim}

To begin an interactive session with the Ur compiler modules, run \texttt{make smlnj}, and then, from within an \texttt{sml} session, run \texttt{CM.make "src/urweb.cm";}.  The \texttt{Compiler} module is the main entry point.

To run an SQL-backed application, you will probably want to install the PostgreSQL server.  Version 8.3 or higher is required.

\begin{verbatim}
apt-get install postgresql-8.3
\end{verbatim}

To use the Emacs mode, you must have a modern Emacs installed.  We assume that you already know how to do this, if you're in the business of looking for an Emacs mode.  The demo generation facility of the compiler will also call out to Emacs to syntax-highlight code, and that process depends on the \texttt{htmlize} module, which can be installed in Debian testing via:

\begin{verbatim}
apt-get install emacs-goodies-el
\end{verbatim}

Even with the right packages installed, configuration and building might fail to work.  After you run \texttt{./configure}, you will see the values of some named environment variables printed.  You may need to adjust these values to get proper installation for your system.  To change a value, store your preferred alternative in the corresponding UNIX environment variable, before running \texttt{./configure}.  For instance, here is how to change the list of extra arguments that the Ur/Web compiler will pass to GCC on every invocation.

\begin{verbatim}
GCCARGS=-fnested-functions ./configure
\end{verbatim}

Some OSX users have reported needing to use this particular GCCARGS value.

The Emacs mode can be set to autoload by adding the following to your \texttt{.emacs} file.

\begin{verbatim}
(add-to-list 'load-path "/usr/local/share/emacs/site-lisp/urweb-mode")
(load "urweb-mode-startup")
\end{verbatim}

Change the path in the first line if you chose a different Emacs installation path during configuration.


\section{Command-Line Compiler}

\subsection{Project Files}

The basic inputs to the \texttt{urweb} compiler are project files, which have the extension \texttt{.urp}.  Here is a sample \texttt{.urp} file.

\begin{verbatim}
database dbname=test
sql crud1.sql

crud
crud1
\end{verbatim}

The \texttt{database} line gives the database information string to pass to libpq.  In this case, the string only says to connect to a local database named \texttt{test}.

The \texttt{sql} line asks for an SQL source file to be generated, giving the commands to run to create the tables and sequences that this application expects to find.  After building this \texttt{.urp} file, the following commands could be used to initialize the database, assuming that the current UNIX user exists as a Postgres user with database creation privileges:

\begin{verbatim}
createdb test
psql -f crud1.sql test
\end{verbatim}

A blank line always separates the named directives from a list of modules to include in the project; if there are no named directives, a blank line must begin the file.

For each entry \texttt{M} in the module list, the file \texttt{M.urs} is included in the project if it exists, and the file \texttt{M.ur} must exist and is always included.

A few other named directives are supported.  \texttt{prefix PREFIX} sets the prefix included before every URI within the generated application; the default is \texttt{/}.  \texttt{exe FILENAME} sets the filename to which to write the output executable; the default for file \texttt{P.urp} is \texttt{P.exe}.  \texttt{debug} saves some intermediate C files, which is mostly useful to help in debugging the compiler itself.  \texttt{profile} generates an executable that may be used with gprof.

\subsection{Building an Application}

To compile project \texttt{P.urp}, simply run
\begin{verbatim}
urweb P
\end{verbatim}
The output executable is a standalone web server.  Run it with the command-line argument \texttt{-h} to see which options it takes.  If the project file lists a database, the web server will attempt to connect to that database on startup.

To time how long the different compiler phases run, without generating an executable, run
\begin{verbatim}
urweb -timing P
\end{verbatim}


\section{Ur Syntax}

In this section, we describe the syntax of Ur, deferring to a later section discussion of most of the syntax specific to SQL and XML.  The sole exceptions are the declaration forms for tables, sequences, and cookies.

\subsection{Lexical Conventions}

We give the Ur language definition in \LaTeX $\;$ math mode, since that is prettier than monospaced ASCII.  The corresponding ASCII syntax can be read off directly.  Here is the key for mapping math symbols to ASCII character sequences.

\begin{center}
  \begin{tabular}{rl}
    \textbf{\LaTeX} & \textbf{ASCII} \\
    $\to$ & \cd{->} \\
    $\longrightarrow$ & \cd{-->} \\
    $\times$ & \cd{*} \\
    $\lambda$ & \cd{fn} \\
    $\Rightarrow$ & \cd{=>} \\
    $\Longrightarrow$ & \cd{==>} \\
    $\neq$ & \cd{<>} \\
    $\leq$ & \cd{<=} \\
    $\geq$ & \cd{>=} \\
    \\
    $x$ & Normal textual identifier, not beginning with an uppercase letter \\
    $X$ & Normal textual identifier, beginning with an uppercase letter \\
  \end{tabular}
\end{center}

We often write syntax like $e^*$ to indicate zero or more copies of $e$, $e^+$ to indicate one or more copies, and $e,^*$ and $e,^+$ to indicate multiple copies separated by commas.  Another separator may be used in place of a comma.  The $e$ term may be surrounded by parentheses to indicate grouping; those parentheses should not be included in the actual ASCII.

We write $\ell$ for literals of the primitive types, for the most part following C conventions.  There are $\mt{int}$, $\mt{float}$, and $\mt{string}$ literals.

This version of the manual doesn't include operator precedences; see \texttt{src/urweb.grm} for that.

\subsection{\label{core}Core Syntax}

\emph{Kinds} classify types and other compile-time-only entities.  Each kind in the grammar is listed with a description of the sort of data it classifies.
$$\begin{array}{rrcll}
  \textrm{Kinds} & \kappa &::=& \mt{Type} & \textrm{proper types} \\
  &&& \mt{Unit} & \textrm{the trivial constructor} \\
  &&& \mt{Name} & \textrm{field names} \\
  &&& \kappa \to \kappa & \textrm{type-level functions} \\
  &&& \{\kappa\} & \textrm{type-level records} \\
  &&& (\kappa\times^+) & \textrm{type-level tuples} \\
  &&& X & \textrm{variable} \\
  &&& X \longrightarrow k & \textrm{kind-polymorphic type-level function} \\
  &&& \_\_ & \textrm{wildcard} \\
  &&& (\kappa) & \textrm{explicit precedence} \\
\end{array}$$

Ur supports several different notions of functions that take types as arguments.  These arguments can be either implicit, causing them to be inferred at use sites; or explicit, forcing them to be specified manually at use sites.  There is a common explicitness annotation convention applied at the definitions of and in the types of such functions.
$$\begin{array}{rrcll}
  \textrm{Explicitness} & ? &::=& :: & \textrm{explicit} \\
  &&& ::: & \textrm{implicit}
\end{array}$$

\emph{Constructors} are the main class of compile-time-only data.  They include proper types and are classified by kinds.
$$\begin{array}{rrcll}
  \textrm{Constructors} & c, \tau &::=& (c) :: \kappa & \textrm{kind annotation} \\
  &&& \hat{x} & \textrm{constructor variable} \\
  \\
  &&& \tau \to \tau & \textrm{function type} \\
  &&& x \; ? \; \kappa \to \tau & \textrm{polymorphic function type} \\
  &&& X \longrightarrow \tau & \textrm{kind-polymorphic function type} \\
  &&& \$ c & \textrm{record type} \\
  \\
  &&& c \; c & \textrm{type-level function application} \\
  &&& \lambda x \; :: \; \kappa \Rightarrow c & \textrm{type-level function abstraction} \\
  \\
  &&& X \Longrightarrow c & \textrm{type-level kind-polymorphic function abstraction} \\
  &&& c [\kappa] & \textrm{type-level kind-polymorphic function application} \\
  \\
  &&& () & \textrm{type-level unit} \\
  &&& \#X & \textrm{field name} \\
  \\
  &&& [(c = c)^*] & \textrm{known-length type-level record} \\
  &&& c \rc c & \textrm{type-level record concatenation} \\
  &&& \mt{map} & \textrm{type-level record map} \\
  \\
  &&& (c,^+) & \textrm{type-level tuple} \\
  &&& c.n & \textrm{type-level tuple projection ($n \in \mathbb N^+$)} \\
  \\
  &&& [c \sim c] \Rightarrow \tau & \textrm{guarded type} \\
  \\
  &&& \_ :: \kappa & \textrm{wildcard} \\
  &&& (c) & \textrm{explicit precedence} \\
  \\
  \textrm{Qualified uncapitalized variables} & \hat{x} &::=& x & \textrm{not from a module} \\
  &&& M.x & \textrm{projection from a module} \\
\end{array}$$

We include both abstraction and application for kind polymorphism, but applications are only inferred internally; they may not be written explicitly in source programs.

Modules of the module system are described by \emph{signatures}.
$$\begin{array}{rrcll}
  \textrm{Signatures} & S &::=& \mt{sig} \; s^* \; \mt{end} & \textrm{constant} \\
  &&& X & \textrm{variable} \\
  &&& \mt{functor}(X : S) : S & \textrm{functor} \\
  &&& S \; \mt{where} \; \mt{con} \; x = c & \textrm{concretizing an abstract constructor} \\
  &&& M.X & \textrm{projection from a module} \\
  \\
  \textrm{Signature items} & s &::=& \mt{con} \; x :: \kappa & \textrm{abstract constructor} \\
  &&& \mt{con} \; x :: \kappa = c & \textrm{concrete constructor} \\
  &&& \mt{datatype} \; x \; x^* = dc\mid^+ & \textrm{algebraic datatype definition} \\
  &&& \mt{datatype} \; x = \mt{datatype} \; M.x & \textrm{algebraic datatype import} \\
  &&& \mt{val} \; x : \tau & \textrm{value} \\
  &&& \mt{structure} \; X : S & \textrm{sub-module} \\
  &&& \mt{signature} \; X = S & \textrm{sub-signature} \\
  &&& \mt{include} \; S & \textrm{signature inclusion} \\
  &&& \mt{constraint} \; c \sim c & \textrm{record disjointness constraint} \\
  &&& \mt{class} \; x :: \kappa & \textrm{abstract constructor class} \\
  &&& \mt{class} \; x :: \kappa = c & \textrm{concrete constructor class} \\
  \\
  \textrm{Datatype constructors} & dc &::=& X & \textrm{nullary constructor} \\
  &&& X \; \mt{of} \; \tau & \textrm{unary constructor} \\
\end{array}$$

\emph{Patterns} are used to describe structural conditions on expressions, such that expressions may be tested against patterns, generating assignments to pattern variables if successful.
$$\begin{array}{rrcll}
  \textrm{Patterns} & p &::=& \_ & \textrm{wildcard} \\
  &&& x & \textrm{variable} \\
  &&& \ell & \textrm{constant} \\
  &&& \hat{X} & \textrm{nullary constructor} \\
  &&& \hat{X} \; p & \textrm{unary constructor} \\
  &&& \{(x = p,)^*\} & \textrm{rigid record pattern} \\
  &&& \{(x = p,)^+, \ldots\} & \textrm{flexible record pattern} \\
  &&& (p) & \textrm{explicit precedence} \\
  \\
  \textrm{Qualified capitalized variables} & \hat{X} &::=& X & \textrm{not from a module} \\
  &&& M.X & \textrm{projection from a module} \\
\end{array}$$

\emph{Expressions} are the main run-time entities, corresponding to both ``expressions'' and ``statements'' in mainstream imperative languages.
$$\begin{array}{rrcll}
  \textrm{Expressions} & e &::=& e : \tau & \textrm{type annotation} \\
  &&& \hat{x} & \textrm{variable} \\
  &&& \hat{X} & \textrm{datatype constructor} \\
  &&& \ell & \textrm{constant} \\
  \\
  &&& e \; e & \textrm{function application} \\
  &&& \lambda x : \tau \Rightarrow e & \textrm{function abstraction} \\
  &&& e [c] & \textrm{polymorphic function application} \\
  &&& \lambda x \; ? \; \kappa \Rightarrow e & \textrm{polymorphic function abstraction} \\
  &&& e [\kappa] & \textrm{kind-polymorphic function application} \\
  &&& X \Longrightarrow e & \textrm{kind-polymorphic function abstraction} \\
  \\
  &&& \{(c = e,)^*\} & \textrm{known-length record} \\
  &&& e.c & \textrm{record field projection} \\
  &&& e \rc e & \textrm{record concatenation} \\
  &&& e \rcut c & \textrm{removal of a single record field} \\
  &&& e \rcutM c & \textrm{removal of multiple record fields} \\
  \\
  &&& \mt{let} \; ed^* \; \mt{in} \; e \; \mt{end} & \textrm{local definitions} \\
  \\
  &&& \mt{case} \; e \; \mt{of} \; (p \Rightarrow e|)^+ & \textrm{pattern matching} \\
  \\
  &&& \lambda [c \sim c] \Rightarrow e & \textrm{guarded expression abstraction} \\
  &&& e \; ! & \textrm{guarded expression application} \\
  \\
  &&& \_ & \textrm{wildcard} \\
  &&& (e) & \textrm{explicit precedence} \\
  \\
  \textrm{Local declarations} & ed &::=& \cd{val} \; x : \tau = e & \textrm{non-recursive value} \\
  &&& \cd{val} \; \cd{rec} \; (x : \tau = e \; \cd{and})^+ & \textrm{mutually-recursive values} \\
\end{array}$$

As with constructors, we include both abstraction and application for kind polymorphism, but applications are only inferred internally.

\emph{Declarations} primarily bring new symbols into context.
$$\begin{array}{rrcll}
  \textrm{Declarations} & d &::=& \mt{con} \; x :: \kappa = c & \textrm{constructor synonym} \\
  &&& \mt{datatype} \; x \; x^* = dc\mid^+ & \textrm{algebraic datatype definition} \\
  &&& \mt{datatype} \; x = \mt{datatype} \; M.x & \textrm{algebraic datatype import} \\
  &&& \mt{val} \; x : \tau = e & \textrm{value} \\
  &&& \mt{val} \; \cd{rec} \; (x : \tau = e \; \mt{and})^+ & \textrm{mutually-recursive values} \\
  &&& \mt{structure} \; X : S = M & \textrm{module definition} \\
  &&& \mt{signature} \; X = S & \textrm{signature definition} \\
  &&& \mt{open} \; M & \textrm{module inclusion} \\
  &&& \mt{constraint} \; c \sim c & \textrm{record disjointness constraint} \\
  &&& \mt{open} \; \mt{constraints} \; M & \textrm{inclusion of just the constraints from a module} \\
  &&& \mt{table} \; x : c & \textrm{SQL table} \\
  &&& \mt{sequence} \; x & \textrm{SQL sequence} \\
  &&& \mt{cookie} \; x : \tau & \textrm{HTTP cookie} \\
  &&& \mt{class} \; x :: \kappa = c & \textrm{concrete constructor class} \\
  \\
  \textrm{Modules} & M &::=& \mt{struct} \; d^* \; \mt{end} & \textrm{constant} \\
  &&& X & \textrm{variable} \\
  &&& M.X & \textrm{projection} \\
  &&& M(M) & \textrm{functor application} \\
  &&& \mt{functor}(X : S) : S = M & \textrm{functor abstraction} \\
\end{array}$$

There are two kinds of Ur files.  A file named $M\texttt{.ur}$ is an \emph{implementation file}, and it should contain a sequence of declarations $d^*$.  A file named $M\texttt{.urs}$ is an \emph{interface file}; it must always have a matching $M\texttt{.ur}$ and should contain a sequence of signature items $s^*$.  When both files are present, the overall effect is the same as a monolithic declaration $\mt{structure} \; M : \mt{sig} \; s^* \; \mt{end} = \mt{struct} \; d^* \; \mt{end}$.  When no interface file is included, the overall effect is similar, with a signature for module $M$ being inferred rather than just checked against an interface.

\subsection{Shorthands}

There are a variety of derived syntactic forms that elaborate into the core syntax from the last subsection.  We will present the additional forms roughly following the order in which we presented the constructs that they elaborate into.

In many contexts where record fields are expected, like in a projection $e.c$, a constant field may be written as simply $X$, rather than $\#X$.

A record type may be written $\{(c = c,)^*\}$, which elaborates to $\$[(c = c,)^*]$.

The notation $[c_1, \ldots, c_n]$ is shorthand for $[c_1 = (), \ldots, c_n = ()]$.

A tuple type $(\tau_1, \ldots, \tau_n)$ expands to a record type $\{1 = \tau_1, \ldots, n = \tau_n\}$, with natural numbers as field names.  A tuple pattern $(p_1, \ldots, p_n)$ expands to a rigid record pattern $\{1 = p_1, \ldots, n = p_n\}$.  Positive natural numbers may be used in most places where field names would be allowed.

In general, several adjacent $\lambda$ forms may be combined into one, and kind and type annotations may be omitted, in which case they are implicitly included as wildcards.  More formally, for constructor-level abstractions, we can define a new non-terminal $b ::= x \mid (x :: \kappa) \mid X$ and allow composite abstractions of the form $\lambda b^+ \Rightarrow c$, elaborating into the obvious sequence of one core $\lambda$ per element of $b^+$.  

For any signature item or declaration that defines some entity to be equal to $A$ with classification annotation $B$ (e.g., $\mt{val} \; x : B = A$), $B$ and the preceding colon (or similar punctuation) may be omitted, in which case it is filled in as a wildcard.

A signature item or declaration $\mt{type} \; x$ or $\mt{type} \; x = \tau$ is elaborated into $\mt{con} \; x :: \mt{Type}$ or $\mt{con} \; x :: \mt{Type} = \tau$, respectively.

A signature item or declaration $\mt{class} \; x = \lambda y \Rightarrow c$ may be abbreviated $\mt{class} \; x \; y = c$.

Handling of implicit and explicit constructor arguments may be tweaked with some prefixes to variable references.  An expression $@x$ is a version of $x$ where all implicit constructor arguments have been made explicit.  An expression $@@x$ achieves the same effect, additionally halting automatic resolution of type class instances and automatic proving of disjointness constraints.  The default is that any prefix of a variable's type consisting only of implicit polymorphism, type class instances, and disjointness obligations is resolved automatically, with the variable treated as having the type that starts after the last implicit element, with suitable unification variables substituted.  The same syntax works for variables projected out of modules and for capitalized variables (datatype constructors).

At the expression level, an analogue is available of the composite $\lambda$ form for constructors.  We define the language of binders as $b ::= x \mid (x : \tau) \mid (x \; ? \; \kappa) \mid X \mid [c \sim c]$.  A lone variable $x$ as a binder stands for an expression variable of unspecified type.

A $\mt{val}$ or $\mt{val} \; \mt{rec}$ declaration may include expression binders before the equal sign, following the binder grammar from the last paragraph.  Such declarations are elaborated into versions that add additional $\lambda$s to the fronts of the righthand sides, as appropriate.  The keyword $\mt{fun}$ is a synonym for $\mt{val} \; \mt{rec}$.

A signature item $\mt{functor} \; X_1 \; (X_2 : S_1) : S_2$ is elaborated into $\mt{structure} \; X_1 : \mt{functor}(X_2 : S_1) : S_2$.  A declaration $\mt{functor} \; X_1 \; (X_2 : S_1) : S_2 = M$ is elaborated into $\mt{structure} \; X_1 : \mt{functor}(X_2 : S_1) : S_2 = \mt{functor}(X_2 : S_1) : S_2 = M$.

A declaration $\mt{table} \; x : \{(c = c,)^*\}$ is elaborated into $\mt{table} \; x : [(c = c,)^*]$

The syntax $\mt{where} \; \mt{type}$ is an alternate form of $\mt{where} \; \mt{con}$.

The syntax $\mt{if} \; e \; \mt{then} \; e_1 \; \mt{else} \; e_2$ expands to $\mt{case} \; e \; \mt{of} \; \mt{Basis}.\mt{True} \Rightarrow e_1 \mid \mt{Basis}.\mt{False} \Rightarrow e_2$.

There are infix operator syntaxes for a number of functions defined in the $\mt{Basis}$ module.  There is $=$ for $\mt{eq}$, $\neq$ for $\mt{neq}$, $-$ for $\mt{neg}$ (as a prefix operator) and $\mt{minus}$, $+$ for $\mt{plus}$, $\times$ for $\mt{times}$, $/$ for $\mt{div}$, $\%$ for $\mt{mod}$, $<$ for $\mt{lt}$, $\leq$ for $\mt{le}$, $>$ for $\mt{gt}$, and $\geq$ for $\mt{ge}$.

A signature item $\mt{table} \; x : c$ is shorthand for $\mt{val} \; x : \mt{Basis}.\mt{sql\_table} \; c$.  $\mt{sequence} \; x$ is short for $\mt{val} \; x : \mt{Basis}.\mt{sql\_sequence}$, and $\mt{cookie} \; x : \tau$ is shorthand for $\mt{val} \; x : \mt{Basis}.\mt{http\_cookie} \; \tau$.


\section{Static Semantics}

In this section, we give a declarative presentation of Ur's typing rules and related judgments.  Inference is the subject of the next section; here, we assume that an oracle has filled in all wildcards with concrete values.

Since there is significant mutual recursion among the judgments, we introduce them all before beginning to give rules.  We use the same variety of contexts throughout this section, implicitly introducing new sorts of context entries as needed.
\begin{itemize}
\item $\Gamma \vdash \kappa$ expresses kind well-formedness.
\item $\Gamma \vdash c :: \kappa$ assigns a kind to a constructor in a context.
\item $\Gamma \vdash c \sim c$ proves the disjointness of two record constructors; that is, that they share no field names.  We overload the judgment to apply to pairs of field names as well.
\item $\Gamma \vdash c \hookrightarrow C$ proves that record constructor $c$ decomposes into set $C$ of field names and record constructors.
\item $\Gamma \vdash c \equiv c$ proves the computational equivalence of two constructors.  This is often called a \emph{definitional equality} in the world of type theory.
\item $\Gamma \vdash e : \tau$ is a standard typing judgment.
\item $\Gamma \vdash p \leadsto \Gamma; \tau$ combines typing of patterns with calculation of which new variables they bind.
\item $\Gamma \vdash d \leadsto \Gamma$ expresses how a declaration modifies a context.  We overload this judgment to apply to sequences of declarations, as well as to signature items and sequences of signature items.
\item $\Gamma \vdash S \equiv S$ is the signature equivalence judgment.
\item $\Gamma \vdash S \leq S$ is the signature compatibility judgment.  We write $\Gamma \vdash S$ as shorthand for $\Gamma \vdash S \leq S$.
\item $\Gamma \vdash M : S$ is the module signature checking judgment.
\item $\mt{proj}(M, \overline{s}, V)$ is a partial function for projecting a signature item from $\overline{s}$, given the module $M$ that we project from.  $V$ may be $\mt{con} \; x$, $\mt{datatype} \; x$, $\mt{val} \; x$, $\mt{signature} \; X$, or $\mt{structure} \; X$.  The parameter $M$ is needed because the projected signature item may refer to other items from $\overline{s}$.
\item $\mt{selfify}(M, \overline{s})$ adds information to signature items $\overline{s}$ to reflect the fact that we are concerned with the particular module $M$.  This function is overloaded to work over individual signature items as well.
\end{itemize}


\subsection{Kind Well-Formedness}

$$\infer{\Gamma \vdash \mt{Type}}{}
\quad \infer{\Gamma \vdash \mt{Unit}}{}
\quad \infer{\Gamma \vdash \mt{Name}}{}
\quad \infer{\Gamma \vdash \kappa_1 \to \kappa_2}{
  \Gamma \vdash \kappa_1
  & \Gamma \vdash \kappa_2
}
\quad \infer{\Gamma \vdash \{\kappa\}}{
  \Gamma \vdash \kappa
}
\quad \infer{\Gamma \vdash (\kappa_1 \times \ldots \times \kappa_n)}{
  \forall i: \Gamma \vdash \kappa_i
}$$

$$\infer{\Gamma \vdash X}{
  X \in \Gamma
}
\quad \infer{\Gamma \vdash X \longrightarrow \kappa}{
  \Gamma, X \vdash \kappa
}$$

\subsection{Kinding}

We write $[X \mapsto \kappa_1]\kappa_2$ for capture-avoiding substitution of $\kappa_1$ for $X$ in $\kappa_2$.

$$\infer{\Gamma \vdash (c) :: \kappa :: \kappa}{
  \Gamma \vdash c :: \kappa
}
\quad \infer{\Gamma \vdash x :: \kappa}{
  x :: \kappa \in \Gamma
}
\quad \infer{\Gamma \vdash x :: \kappa}{
  x :: \kappa = c \in \Gamma
}$$

$$\infer{\Gamma \vdash M.x :: \kappa}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{con} \; x) = \kappa
}
\quad \infer{\Gamma \vdash M.x :: \kappa}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{con} \; x) = (\kappa, c)
}$$

$$\infer{\Gamma \vdash \tau_1 \to \tau_2 :: \mt{Type}}{
  \Gamma \vdash \tau_1 :: \mt{Type}
  & \Gamma \vdash \tau_2 :: \mt{Type}
}
\quad \infer{\Gamma \vdash x \; ? \: \kappa \to \tau :: \mt{Type}}{
  \Gamma, x :: \kappa \vdash \tau :: \mt{Type}
}
\quad \infer{\Gamma \vdash X \longrightarrow \tau :: \mt{Type}}{
  \Gamma, X \vdash \tau :: \mt{Type}
}
\quad \infer{\Gamma \vdash \$c :: \mt{Type}}{
  \Gamma \vdash c :: \{\mt{Type}\}
}$$

$$\infer{\Gamma \vdash c_1 \; c_2 :: \kappa_2}{
  \Gamma \vdash c_1 :: \kappa_1 \to \kappa_2
  & \Gamma \vdash c_2 :: \kappa_1
}
\quad \infer{\Gamma \vdash \lambda x \; :: \; \kappa_1 \Rightarrow c :: \kappa_1 \to \kappa_2}{
  \Gamma, x :: \kappa_1 \vdash c :: \kappa_2
}$$

$$\infer{\Gamma \vdash c[\kappa'] :: [X \mapsto \kappa']\kappa}{
  \Gamma \vdash c :: X \to \kappa
  & \Gamma \vdash \kappa'
}
\quad \infer{\Gamma \vdash X \Longrightarrow c :: X \to \kappa}{
  \Gamma, X \vdash c :: \kappa
}$$

$$\infer{\Gamma \vdash () :: \mt{Unit}}{}
\quad \infer{\Gamma \vdash \#X :: \mt{Name}}{}$$

$$\infer{\Gamma \vdash [\overline{c_i = c'_i}] :: \{\kappa\}}{
  \forall i: \Gamma \vdash c_i : \mt{Name}
  & \Gamma \vdash c'_i :: \kappa
  & \forall i \neq j: \Gamma \vdash c_i \sim c_j
}
\quad \infer{\Gamma \vdash c_1 \rc c_2 :: \{\kappa\}}{
  \Gamma \vdash c_1 :: \{\kappa\}
  & \Gamma \vdash c_2 :: \{\kappa\}
  & \Gamma \vdash c_1 \sim c_2
}$$

$$\infer{\Gamma \vdash \mt{map} :: (\kappa_1 \to \kappa_2) \to \{\kappa_1\} \to \{\kappa_2\}}{}$$

$$\infer{\Gamma \vdash (\overline c) :: (\kappa_1 \times \ldots \times \kappa_n)}{
  \forall i: \Gamma \vdash c_i :: \kappa_i
}
\quad \infer{\Gamma \vdash c.i :: \kappa_i}{
  \Gamma \vdash c :: (\kappa_1 \times \ldots \times \kappa_n)
}$$

$$\infer{\Gamma \vdash \lambda [c_1 \sim c_2] \Rightarrow \tau :: \mt{Type}}{
  \Gamma \vdash c_1 :: \{\kappa\}
  & \Gamma \vdash c_2 :: \{\kappa'\}
  & \Gamma, c_1 \sim c_2 \vdash \tau :: \mt{Type}
}$$

\subsection{Record Disjointness}

$$\infer{\Gamma \vdash c_1 \sim c_2}{
  \Gamma \vdash c_1 \hookrightarrow C_1
  & \Gamma \vdash c_2 \hookrightarrow C_2
  & \forall c'_1 \in C_1, c'_2 \in C_2: \Gamma \vdash c'_1 \sim c'_2
}
\quad \infer{\Gamma \vdash X \sim X'}{
  X \neq X'
}$$

$$\infer{\Gamma \vdash c_1 \sim c_2}{
  c'_1 \sim c'_2 \in \Gamma
  & \Gamma \vdash c'_1 \hookrightarrow C_1
  & \Gamma \vdash c'_2 \hookrightarrow C_2
  & c_1 \in C_1
  & c_2 \in C_2
}$$

$$\infer{\Gamma \vdash c \hookrightarrow \{c\}}{}
\quad \infer{\Gamma \vdash [\overline{c = c'}] \hookrightarrow \{\overline{c}\}}{}
\quad \infer{\Gamma \vdash c_1 \rc c_2 \hookrightarrow C_1 \cup C_2}{
  \Gamma \vdash c_1 \hookrightarrow C_1
  & \Gamma \vdash c_2 \hookrightarrow C_2
}
\quad \infer{\Gamma \vdash c \hookrightarrow C}{
  \Gamma \vdash c \equiv c'
  & \Gamma \vdash c' \hookrightarrow C
}
\quad \infer{\Gamma \vdash \mt{map} \; f \; c \hookrightarrow C}{
  \Gamma \vdash c \hookrightarrow C
}$$

\subsection{\label{definitional}Definitional Equality}

We use $\mathcal C$ to stand for a one-hole context that, when filled, yields a constructor.  The notation $\mathcal C[c]$ plugs $c$ into $\mathcal C$.  We omit the standard definition of one-hole contexts.  We write $[x \mapsto c_1]c_2$ for capture-avoiding substitution of $c_1$ for $x$ in $c_2$, with analogous notation for substituting a kind in a constructor.

$$\infer{\Gamma \vdash c \equiv c}{}
\quad \infer{\Gamma \vdash c_1 \equiv c_2}{
  \Gamma \vdash c_2 \equiv c_1
}
\quad \infer{\Gamma \vdash c_1 \equiv c_3}{
  \Gamma \vdash c_1 \equiv c_2
  & \Gamma \vdash c_2 \equiv c_3
}
\quad \infer{\Gamma \vdash \mathcal C[c_1] \equiv \mathcal C[c_2]}{
  \Gamma \vdash c_1 \equiv c_2
}$$

$$\infer{\Gamma \vdash x \equiv c}{
  x :: \kappa = c \in \Gamma
}
\quad \infer{\Gamma \vdash M.x \equiv c}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{con} \; x) = (\kappa, c)
}
\quad \infer{\Gamma \vdash (\overline c).i \equiv c_i}{}$$

$$\infer{\Gamma \vdash (\lambda x :: \kappa \Rightarrow c) \; c' \equiv [x \mapsto c'] c}{}
\quad \infer{\Gamma \vdash (X \Longrightarrow c) [\kappa] \equiv [X \mapsto \kappa] c}{}$$

$$\infer{\Gamma \vdash c_1 \rc c_2 \equiv c_2 \rc c_1}{}
\quad \infer{\Gamma \vdash c_1 \rc (c_2 \rc c_3) \equiv (c_1 \rc c_2) \rc c_3}{}$$

$$\infer{\Gamma \vdash [] \rc c \equiv c}{}
\quad \infer{\Gamma \vdash [\overline{c_1 = c'_1}] \rc [\overline{c_2 = c'_2}] \equiv [\overline{c_1 = c'_1}, \overline{c_2 = c'_2}]}{}$$

$$\infer{\Gamma \vdash \mt{map} \; f \; [] \equiv []}{}
\quad \infer{\Gamma \vdash \mt{map} \; f \; ([c_1 = c_2] \rc c) \equiv [c_1 = f \; c_2] \rc \mt{map} \; f \; c}{}$$

$$\infer{\Gamma \vdash \mt{map} \; (\lambda x \Rightarrow x) \; c \equiv c}{}
\quad \infer{\Gamma \vdash \mt{map} \; f \; (\mt{map} \; f' \; c)
  \equiv \mt{map} \; (\lambda x \Rightarrow f \; (f' \; x)) \; c}{}$$

$$\infer{\Gamma \vdash \mt{map} \; f \; (c_1 \rc c_2) \equiv \mt{map} \; f \; c_1 \rc \mt{map} \; f \; c_2}{}$$

\subsection{Expression Typing}

We assume the existence of a function $T$ assigning types to literal constants.  It maps integer constants to $\mt{Basis}.\mt{int}$, float constants to $\mt{Basis}.\mt{float}$, and string constants to $\mt{Basis}.\mt{string}$.

We also refer to a function $\mathcal I$, such that $\mathcal I(\tau)$ ``uses an oracle'' to instantiate all constructor function arguments at the beginning of $\tau$ that are marked implicit; i.e., replace $x_1 ::: \kappa_1 \to \ldots \to x_n ::: \kappa_n \to \tau$ with $[x_1 \mapsto c_1]\ldots[x_n \mapsto c_n]\tau$, where the $c_i$s are inferred and $\tau$ does not start like $x ::: \kappa \to \tau'$.

$$\infer{\Gamma \vdash e : \tau : \tau}{
  \Gamma \vdash e : \tau
}
\quad \infer{\Gamma \vdash e : \tau}{
  \Gamma \vdash e : \tau'
  & \Gamma \vdash \tau' \equiv \tau
}
\quad \infer{\Gamma \vdash \ell : T(\ell)}{}$$

$$\infer{\Gamma \vdash x : \mathcal I(\tau)}{
  x : \tau \in \Gamma
}
\quad \infer{\Gamma \vdash M.x : \mathcal I(\tau)}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{val} \; x) = \tau
}
\quad \infer{\Gamma \vdash X : \mathcal I(\tau)}{
  X : \tau \in \Gamma
}
\quad \infer{\Gamma \vdash M.X : \mathcal I(\tau)}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{val} \; X) = \tau
}$$

$$\infer{\Gamma \vdash e_1 \; e_2 : \tau_2}{
  \Gamma \vdash e_1 : \tau_1 \to \tau_2
  & \Gamma \vdash e_2 : \tau_1
}
\quad \infer{\Gamma \vdash \lambda x : \tau_1 \Rightarrow e : \tau_1 \to \tau_2}{
  \Gamma, x : \tau_1 \vdash e : \tau_2
}$$

$$\infer{\Gamma \vdash e [c] : [x \mapsto c]\tau}{
  \Gamma \vdash e : x :: \kappa \to \tau
  & \Gamma \vdash c :: \kappa
}
\quad \infer{\Gamma \vdash \lambda x \; ? \; \kappa \Rightarrow e : x \; ? \; \kappa \to \tau}{
  \Gamma, x :: \kappa \vdash e : \tau
}$$

$$\infer{\Gamma \vdash e [\kappa] : [X \mapsto \kappa]\tau}{
  \Gamma \vdash e : X \longrightarrow \tau
  & \Gamma \vdash \kappa
}
\quad \infer{\Gamma \vdash X \Longrightarrow e : X \longrightarrow \tau}{
  \Gamma, X \vdash e : \tau
}$$

$$\infer{\Gamma \vdash \{\overline{c = e}\} : \{\overline{c : \tau}\}}{
  \forall i: \Gamma \vdash c_i :: \mt{Name}
  & \Gamma \vdash e_i : \tau_i
  & \forall i \neq j: \Gamma \vdash c_i \sim c_j
}
\quad \infer{\Gamma \vdash e.c : \tau}{
  \Gamma \vdash e : \$([c = \tau] \rc c')
}
\quad \infer{\Gamma \vdash e_1 \rc e_2 : \$(c_1 \rc c_2)}{
  \Gamma \vdash e_1 : \$c_1
  & \Gamma \vdash e_2 : \$c_2
  & \Gamma \vdash c_1 \sim c_2
}$$

$$\infer{\Gamma \vdash e \rcut c : \$c'}{
  \Gamma \vdash e : \$([c = \tau] \rc c')
}
\quad \infer{\Gamma \vdash e \rcutM c : \$c'}{
  \Gamma \vdash e : \$(c \rc c')
}$$

$$\infer{\Gamma \vdash \mt{let} \; \overline{ed} \; \mt{in} \; e \; \mt{end} : \tau}{
  \Gamma \vdash \overline{ed} \leadsto \Gamma'
  & \Gamma' \vdash e : \tau
}
\quad \infer{\Gamma \vdash \mt{case} \; e \; \mt{of} \; \overline{p \Rightarrow e} : \tau}{
  \forall i: \Gamma \vdash p_i \leadsto \Gamma_i, \tau'
  & \Gamma_i \vdash e_i : \tau
}$$

$$\infer{\Gamma \vdash \lambda [c_1 \sim c_2] \Rightarrow e : \lambda [c_1 \sim c_2] \Rightarrow \tau}{
  \Gamma \vdash c_1 :: \{\kappa\}
  & \Gamma \vdash c_2 :: \{\kappa'\}
  & \Gamma, c_1 \sim c_2 \vdash e : \tau
}$$

\subsection{Pattern Typing}

$$\infer{\Gamma \vdash \_ \leadsto \Gamma; \tau}{}
\quad \infer{\Gamma \vdash x \leadsto \Gamma, x : \tau; \tau}{}
\quad \infer{\Gamma \vdash \ell \leadsto \Gamma; T(\ell)}{}$$

$$\infer{\Gamma \vdash X \leadsto \Gamma; \overline{[x_i \mapsto \tau'_i]}\tau}{
  X : \overline{x ::: \mt{Type}} \to \tau \in \Gamma
  & \textrm{$\tau$ not a function type}
}
\quad \infer{\Gamma \vdash X \; p \leadsto \Gamma'; \overline{[x_i \mapsto \tau'_i]}\tau}{
  X : \overline{x ::: \mt{Type}} \to \tau'' \to \tau \in \Gamma
  & \Gamma \vdash p \leadsto \Gamma'; \overline{[x_i \mapsto \tau'_i]}\tau''
}$$

$$\infer{\Gamma \vdash M.X \leadsto \Gamma; \overline{[x_i \mapsto \tau'_i]}\tau}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{val} \; X) = \overline{x ::: \mt{Type}} \to \tau
  & \textrm{$\tau$ not a function type}
}$$

$$\infer{\Gamma \vdash M.X \; p \leadsto \Gamma'; \overline{[x_i \mapsto \tau'_i]}\tau}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{val} \; X) = \overline{x ::: \mt{Type}} \to \tau'' \to \tau
  & \Gamma \vdash p \leadsto \Gamma'; \overline{[x_i \mapsto \tau'_i]}\tau''
}$$

$$\infer{\Gamma \vdash \{\overline{x = p}\} \leadsto \Gamma_n; \{\overline{x = \tau}\}}{
  \Gamma_0 = \Gamma
  & \forall i: \Gamma_i \vdash p_i \leadsto \Gamma_{i+1}; \tau_i
}
\quad \infer{\Gamma \vdash \{\overline{x = p}, \ldots\} \leadsto \Gamma_n; \$([\overline{x = \tau}] \rc c)}{
  \Gamma_0 = \Gamma
  & \forall i: \Gamma_i \vdash p_i \leadsto \Gamma_{i+1}; \tau_i
}$$

\subsection{Declaration Typing}

We use an auxiliary judgment $\overline{y}; x; \Gamma \vdash \overline{dc} \leadsto \Gamma'$, expressing the enrichment of $\Gamma$ with the types of the datatype constructors $\overline{dc}$, when they are known to belong to datatype $x$ with type parameters $\overline{y}$.

This is the first judgment where we deal with constructor classes, for the $\mt{class}$ declaration form.  We will omit their special handling in this formal specification.  Section \ref{typeclasses} gives an informal description of how constructor classes influence type inference.

We presuppose the existence of a function $\mathcal O$, where $\mathcal O(M, \overline{s})$ implements the $\mt{open}$ declaration by producing a context with the appropriate entry for each available component of module $M$ with signature items $\overline{s}$.  Where possible, $\mathcal O$ uses ``transparent'' entries (e.g., an abstract type $M.x$ is mapped to $x :: \mt{Type} = M.x$), so that the relationship with $M$ is maintained.  A related function $\mathcal O_c$ builds a context containing the disjointness constraints found in $\overline s$.
We write $\kappa_1^n \to \kappa$ as a shorthand, where $\kappa_1^0 \to \kappa = \kappa$ and $\kappa_1^{n+1} \to \kappa_2 = \kappa_1 \to (\kappa_1^n \to \kappa_2)$.  We write $\mt{len}(\overline{y})$ for the length of vector $\overline{y}$ of variables.

$$\infer{\Gamma \vdash \cdot \leadsto \Gamma}{}
\quad \infer{\Gamma \vdash d, \overline{d} \leadsto \Gamma''}{
  \Gamma \vdash d \leadsto \Gamma'
  & \Gamma' \vdash \overline{d} \leadsto \Gamma''
}$$

$$\infer{\Gamma \vdash \mt{con} \; x :: \kappa = c \leadsto \Gamma, x :: \kappa = c}{
  \Gamma \vdash c :: \kappa
}
\quad \infer{\Gamma \vdash \mt{datatype} \; x \; \overline{y} = \overline{dc} \leadsto \Gamma'}{
  \overline{y}; x; \Gamma, x :: \mt{Type}^{\mt{len}(\overline y)} \to \mt{Type} \vdash \overline{dc} \leadsto \Gamma'
}$$

$$\infer{\Gamma \vdash \mt{datatype} \; x = \mt{datatype} \; M.z \leadsto \Gamma'}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{datatype} \; z) = (\overline{y}, \overline{dc})
  & \overline{y}; x; \Gamma, x :: \mt{Type}^{\mt{len}(\overline y)} \to \mt{Type} = M.z \vdash \overline{dc} \leadsto \Gamma'
}$$

$$\infer{\Gamma \vdash \mt{val} \; x : \tau = e \leadsto \Gamma, x : \tau}{
  \Gamma \vdash e : \tau
}$$

$$\infer{\Gamma \vdash \mt{val} \; \mt{rec} \; \overline{x : \tau = e} \leadsto \Gamma, \overline{x : \tau}}{
  \forall i: \Gamma, \overline{x : \tau} \vdash e_i : \tau_i
  & \textrm{$e_i$ starts with an expression $\lambda$, optionally preceded by constructor and disjointness $\lambda$s}
}$$

$$\infer{\Gamma \vdash \mt{structure} \; X : S = M \leadsto \Gamma, X : S}{
  \Gamma \vdash M : S
  & \textrm{ $M$ not a constant or application}
}
\quad \infer{\Gamma \vdash \mt{structure} \; X : S = M \leadsto \Gamma, X : \mt{selfify}(X, \overline{s})}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
}$$

$$\infer{\Gamma \vdash \mt{signature} \; X = S \leadsto \Gamma, X = S}{
  \Gamma \vdash S
}$$

$$\infer{\Gamma \vdash \mt{open} \; M \leadsto \Gamma, \mathcal O(M, \overline{s})}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
}$$

$$\infer{\Gamma \vdash \mt{constraint} \; c_1 \sim c_2 \leadsto \Gamma}{
  \Gamma \vdash c_1 :: \{\kappa\}
  & \Gamma \vdash c_2 :: \{\kappa\}
  & \Gamma \vdash c_1 \sim c_2
}
\quad \infer{\Gamma \vdash \mt{open} \; \mt{constraints} \; M \leadsto \Gamma, \mathcal O_c(M, \overline{s})}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
}$$

$$\infer{\Gamma \vdash \mt{table} \; x : c \leadsto \Gamma, x : \mt{Basis}.\mt{sql\_table} \; c}{
  \Gamma \vdash c :: \{\mt{Type}\}
}
\quad \infer{\Gamma \vdash \mt{sequence} \; x \leadsto \Gamma, x : \mt{Basis}.\mt{sql\_sequence}}{}$$

$$\infer{\Gamma \vdash \mt{cookie} \; x : \tau \leadsto \Gamma, x : \mt{Basis}.\mt{http\_cookie} \; \tau}{
  \Gamma \vdash \tau :: \mt{Type}
}$$

$$\infer{\Gamma \vdash \mt{class} \; x :: \kappa = c \leadsto \Gamma, x :: \kappa \to \mt{Type} = c}{
  \Gamma \vdash c :: \kappa \to \mt{Type}
}$$

$$\infer{\overline{y}; x; \Gamma \vdash \cdot \leadsto \Gamma}{}
\quad \infer{\overline{y}; x; \Gamma \vdash X \mid \overline{dc} \leadsto \Gamma', X : \overline{y ::: \mt{Type}} \to x \; \overline{y}}{
  \overline{y}; x; \Gamma \vdash \overline{dc} \leadsto \Gamma'
}
\quad \infer{\overline{y}; x; \Gamma \vdash X \; \mt{of} \; \tau \mid \overline{dc} \leadsto \Gamma', X : \overline{y ::: \mt{Type}} \to \tau \to x \; \overline{y}}{
  \overline{y}; x; \Gamma \vdash \overline{dc} \leadsto \Gamma'
}$$

\subsection{Signature Item Typing}

We appeal to a signature item analogue of the $\mathcal O$ function from the last subsection.

$$\infer{\Gamma \vdash \cdot \leadsto \Gamma}{}
\quad \infer{\Gamma \vdash s, \overline{s} \leadsto \Gamma''}{
  \Gamma \vdash s \leadsto \Gamma'
  & \Gamma' \vdash \overline{s} \leadsto \Gamma''
}$$

$$\infer{\Gamma \vdash \mt{con} \; x :: \kappa \leadsto \Gamma, x :: \kappa}{}
\quad \infer{\Gamma \vdash \mt{con} \; x :: \kappa = c \leadsto \Gamma, x :: \kappa = c}{
  \Gamma \vdash c :: \kappa
}
\quad \infer{\Gamma \vdash \mt{datatype} \; x \; \overline{y} = \overline{dc} \leadsto \Gamma'}{
  \overline{y}; x; \Gamma, x :: \mt{Type}^{\mt{len}(\overline y)} \to \mt{Type} \vdash \overline{dc} \leadsto \Gamma'
}$$

$$\infer{\Gamma \vdash \mt{datatype} \; x = \mt{datatype} \; M.z \leadsto \Gamma'}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{datatype} \; z) = (\overline{y}, \overline{dc})
  & \overline{y}; x; \Gamma, x :: \mt{Type}^{\mt{len}(\overline y)} \to \mt{Type} = M.z \vdash \overline{dc} \leadsto \Gamma'
}$$

$$\infer{\Gamma \vdash \mt{val} \; x : \tau \leadsto \Gamma, x : \tau}{
  \Gamma \vdash \tau :: \mt{Type}
}$$

$$\infer{\Gamma \vdash \mt{structure} \; X : S \leadsto \Gamma, X : S}{
  \Gamma \vdash S
}
\quad \infer{\Gamma \vdash \mt{signature} \; X = S \leadsto \Gamma, X = S}{
  \Gamma \vdash S
}$$

$$\infer{\Gamma \vdash \mt{include} \; S \leadsto \Gamma, \mathcal O(\overline{s})}{
  \Gamma \vdash S
  & \Gamma \vdash S \equiv \mt{sig} \; \overline{s} \; \mt{end}
}$$

$$\infer{\Gamma \vdash \mt{constraint} \; c_1 \sim c_2 \leadsto \Gamma, c_1 \sim c_2}{
  \Gamma \vdash c_1 :: \{\kappa\}
  & \Gamma \vdash c_2 :: \{\kappa\}
}$$

$$\infer{\Gamma \vdash \mt{class} \; x :: \kappa = c \leadsto \Gamma, x :: \kappa \to \mt{Type} = c}{
  \Gamma \vdash c :: \kappa \to \mt{Type}
}
\quad \infer{\Gamma \vdash \mt{class} \; x :: \kappa \leadsto \Gamma, x :: \kappa \to \mt{Type}}{}$$

\subsection{Signature Compatibility}

To simplify the judgments in this section, we assume that all signatures are alpha-varied as necessary to avoid including multiple bindings for the same identifier.  This is in addition to the usual alpha-variation of locally-bound variables.

We rely on a judgment $\Gamma \vdash \overline{s} \leq s'$, which expresses the occurrence in signature items $\overline{s}$ of an item compatible with $s'$.  We also use a judgment $\Gamma \vdash \overline{dc} \leq \overline{dc}$, which expresses compatibility of datatype definitions.

$$\infer{\Gamma \vdash S \equiv S}{}
\quad \infer{\Gamma \vdash S_1 \equiv S_2}{
  \Gamma \vdash S_2 \equiv S_1
}
\quad \infer{\Gamma \vdash X \equiv S}{
  X = S \in \Gamma
}
\quad \infer{\Gamma \vdash M.X \equiv S}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{signature} \; X) = S
}$$

$$\infer{\Gamma \vdash S \; \mt{where} \; \mt{con} \; x = c \equiv \mt{sig} \; \overline{s^1} \; \mt{con} \; x :: \kappa = c \; \overline{s_2} \; \mt{end}}{
  \Gamma \vdash S \equiv \mt{sig} \; \overline{s^1} \; \mt{con} \; x :: \kappa \; \overline{s_2} \; \mt{end}
  & \Gamma \vdash c :: \kappa
}
\quad \infer{\Gamma \vdash \mt{sig} \; \overline{s^1} \; \mt{include} \; S \; \overline{s^2} \; \mt{end} \equiv \mt{sig} \; \overline{s^1} \; \overline{s} \; \overline{s^2} \; \mt{end}}{
  \Gamma \vdash S \equiv \mt{sig} \; \overline{s} \; \mt{end}
}$$

$$\infer{\Gamma \vdash S_1 \leq S_2}{
  \Gamma \vdash S_1 \equiv S_2
}
\quad \infer{\Gamma \vdash \mt{sig} \; \overline{s} \; \mt{end} \leq \mt{sig} \; \mt{end}}{}
\quad \infer{\Gamma \vdash \mt{sig} \; \overline{s} \; \mt{end} \leq \mt{sig} \; s' \; \overline{s'} \; \mt{end}}{
  \Gamma \vdash \overline{s} \leq s'
  & \Gamma \vdash s' \leadsto \Gamma'
  & \Gamma' \vdash \mt{sig} \; \overline{s} \; \mt{end} \leq \mt{sig} \; \overline{s'} \; \mt{end}
}$$

$$\infer{\Gamma \vdash s \; \overline{s} \leq s'}{
  \Gamma \vdash s \leq s'
}
\quad \infer{\Gamma \vdash s \; \overline{s} \leq s'}{
  \Gamma \vdash s \leadsto \Gamma'
  & \Gamma' \vdash \overline{s} \leq s'
}$$

$$\infer{\Gamma \vdash \mt{functor} (X : S_1) : S_2 \leq \mt{functor} (X : S'_1) : S'_2}{
  \Gamma \vdash S'_1 \leq S_1
  & \Gamma, X : S'_1 \vdash S_2 \leq S'_2
}$$

$$\infer{\Gamma \vdash \mt{con} \; x :: \kappa \leq \mt{con} \; x :: \kappa}{}
\quad \infer{\Gamma \vdash \mt{con} \; x :: \kappa = c \leq \mt{con} \; x :: \kappa}{}
\quad \infer{\Gamma \vdash \mt{datatype} \; x \; \overline{y} = \overline{dc} \leq \mt{con} \; x :: \mt{Type}^{\mt{len}(\overline y)} \to \mt{Type}}{}$$

$$\infer{\Gamma \vdash \mt{datatype} \; x = \mt{datatype} \; M.z \leq \mt{con} \; x :: \mt{Type}^{\mt{len}(y)} \to \mt{Type}}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{datatype} \; z) = (\overline{y}, \overline{dc})
}$$

$$\infer{\Gamma \vdash \mt{class} \; x :: \kappa \leq \mt{con} \; x :: \kappa \to \mt{Type}}{}
\quad \infer{\Gamma \vdash \mt{class} \; x :: \kappa = c \leq \mt{con} \; x :: \kappa \to \mt{Type}}{}$$

$$\infer{\Gamma \vdash \mt{con} \; x :: \kappa = c_1 \leq \mt{con} \; x :: \mt{\kappa} = c_2}{
  \Gamma \vdash c_1 \equiv c_2
}
\quad \infer{\Gamma \vdash \mt{class} \; x :: \kappa = c_1 \leq \mt{con} \; x :: \kappa \to \mt{Type} = c_2}{
  \Gamma \vdash c_1 \equiv c_2
}$$

$$\infer{\Gamma \vdash \mt{datatype} \; x \; \overline{y} = \overline{dc} \leq \mt{datatype} \; x \; \overline{y} = \overline{dc'}}{
  \Gamma, \overline{y :: \mt{Type}} \vdash \overline{dc} \leq \overline{dc'}
}$$

$$\infer{\Gamma \vdash \mt{datatype} \; x = \mt{datatype} \; M.z \leq \mt{datatype} \; x \; \overline{y} = \overline{dc'}}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{datatype} \; z) = (\overline{y}, \overline{dc})
  & \Gamma, \overline{y :: \mt{Type}} \vdash \overline{dc} \leq \overline{dc'}
}$$

$$\infer{\Gamma \vdash \cdot \leq \cdot}{}
\quad \infer{\Gamma \vdash X; \overline{dc} \leq X; \overline{dc'}}{
  \Gamma \vdash \overline{dc} \leq \overline{dc'}
}
\quad \infer{\Gamma \vdash X \; \mt{of} \; \tau_1; \overline{dc} \leq X \; \mt{of} \; \tau_2; \overline{dc'}}{
  \Gamma \vdash \tau_1 \equiv \tau_2
  & \Gamma \vdash \overline{dc} \leq \overline{dc'}
}$$

$$\infer{\Gamma \vdash \mt{datatype} \; x = \mt{datatype} \; M.z \leq \mt{datatype} \; x = \mt{datatype} \; M'.z'}{
  \Gamma \vdash M.z \equiv M'.z'
}$$

$$\infer{\Gamma \vdash \mt{val} \; x : \tau_1 \leq \mt{val} \; x : \tau_2}{
  \Gamma \vdash \tau_1 \equiv \tau_2
}
\quad \infer{\Gamma \vdash \mt{structure} \; X : S_1 \leq \mt{structure} \; X : S_2}{
  \Gamma \vdash S_1 \leq S_2
}
\quad \infer{\Gamma \vdash \mt{signature} \; X = S_1 \leq \mt{signature} \; X = S_2}{
  \Gamma \vdash S_1 \leq S_2
  & \Gamma \vdash S_2 \leq S_1
}$$

$$\infer{\Gamma \vdash \mt{constraint} \; c_1 \sim c_2 \leq \mt{constraint} \; c'_1 \sim c'_2}{
  \Gamma \vdash c_1 \equiv c'_1
  & \Gamma \vdash c_2 \equiv c'_2
}$$

$$\infer{\Gamma \vdash \mt{class} \; x :: \kappa \leq \mt{class} \; x :: \kappa}{}
\quad \infer{\Gamma \vdash \mt{class} \; x :: \kappa = c \leq \mt{class} \; x :: \kappa}{}
\quad \infer{\Gamma \vdash \mt{class} \; x :: \kappa = c_1 \leq \mt{class} \; x :: \kappa = c_2}{
  \Gamma \vdash c_1 \equiv c_2
}$$

\subsection{Module Typing}

We use a helper function $\mt{sigOf}$, which converts declarations and sequences of declarations into their principal signature items and sequences of signature items, respectively.

$$\infer{\Gamma \vdash M : S}{
  \Gamma \vdash M : S'
  & \Gamma \vdash S' \leq S
}
\quad \infer{\Gamma \vdash \mt{struct} \; \overline{d} \; \mt{end} : \mt{sig} \; \mt{sigOf}(\overline{d}) \; \mt{end}}{
  \Gamma \vdash \overline{d} \leadsto \Gamma'
}
\quad \infer{\Gamma \vdash X : S}{
  X : S \in \Gamma
}$$

$$\infer{\Gamma \vdash M.X : S}{
  \Gamma \vdash M : \mt{sig} \; \overline{s} \; \mt{end}
  & \mt{proj}(M, \overline{s}, \mt{structure} \; X) = S
}$$

$$\infer{\Gamma \vdash M_1(M_2) : [X \mapsto M_2]S_2}{
  \Gamma \vdash M_1 : \mt{functor}(X : S_1) : S_2
  & \Gamma \vdash M_2 : S_1
}
\quad \infer{\Gamma \vdash \mt{functor} (X : S_1) : S_2 = M : \mt{functor} (X : S_1) : S_2}{
  \Gamma \vdash S_1
  & \Gamma, X : S_1 \vdash S_2
  & \Gamma, X : S_1 \vdash M : S_2
}$$

\begin{eqnarray*}
  \mt{sigOf}(\cdot) &=& \cdot \\
  \mt{sigOf}(s \; \overline{s'}) &=& \mt{sigOf}(s) \; \mt{sigOf}(\overline{s'}) \\
  \\
  \mt{sigOf}(\mt{con} \; x :: \kappa = c) &=& \mt{con} \; x :: \kappa = c \\
  \mt{sigOf}(\mt{datatype} \; x \; \overline{y} = \overline{dc}) &=& \mt{datatype} \; x \; \overline{y} = \overline{dc} \\
  \mt{sigOf}(\mt{datatype} \; x = \mt{datatype} \; M.z) &=& \mt{datatype} \; x = \mt{datatype} \; M.z \\
  \mt{sigOf}(\mt{val} \; x : \tau = e) &=& \mt{val} \; x : \tau \\
  \mt{sigOf}(\mt{val} \; \mt{rec} \; \overline{x : \tau = e}) &=& \overline{\mt{val} \; x : \tau} \\
  \mt{sigOf}(\mt{structure} \; X : S = M) &=& \mt{structure} \; X : S \\
  \mt{sigOf}(\mt{signature} \; X = S) &=& \mt{signature} \; X = S \\
  \mt{sigOf}(\mt{open} \; M) &=& \mt{include} \; S \textrm{ (where $\Gamma \vdash M : S$)} \\
  \mt{sigOf}(\mt{constraint} \; c_1 \sim c_2) &=& \mt{constraint} \; c_1 \sim c_2 \\
  \mt{sigOf}(\mt{open} \; \mt{constraints} \; M) &=& \cdot \\
  \mt{sigOf}(\mt{table} \; x : c) &=& \mt{table} \; x : c \\
  \mt{sigOf}(\mt{sequence} \; x) &=& \mt{sequence} \; x \\
  \mt{sigOf}(\mt{cookie} \; x : \tau) &=& \mt{cookie} \; x : \tau \\
  \mt{sigOf}(\mt{class} \; x :: \kappa = c) &=& \mt{class} \; x :: \kappa = c \\
\end{eqnarray*}
\begin{eqnarray*}
  \mt{selfify}(M, \cdot) &=& \cdot \\
  \mt{selfify}(M, s \; \overline{s'}) &=& \mt{selfify}(M, s) \; \mt{selfify}(M, \overline{s'}) \\
  \\
  \mt{selfify}(M, \mt{con} \; x :: \kappa) &=& \mt{con} \; x :: \kappa = M.x \\
  \mt{selfify}(M, \mt{con} \; x :: \kappa = c) &=& \mt{con} \; x :: \kappa = c \\
  \mt{selfify}(M, \mt{datatype} \; x \; \overline{y} = \overline{dc}) &=& \mt{datatype} \; x \; \overline{y} = \mt{datatype} \; M.x \\
  \mt{selfify}(M, \mt{datatype} \; x = \mt{datatype} \; M'.z) &=& \mt{datatype} \; x = \mt{datatype} \; M'.z \\
  \mt{selfify}(M, \mt{val} \; x : \tau) &=& \mt{val} \; x : \tau \\
  \mt{selfify}(M, \mt{structure} \; X : S) &=& \mt{structure} \; X : \mt{selfify}(M.X, \overline{s}) \textrm{ (where $\Gamma \vdash S \equiv \mt{sig} \; \overline{s} \; \mt{end}$)} \\
  \mt{selfify}(M, \mt{signature} \; X = S) &=& \mt{signature} \; X = S \\
  \mt{selfify}(M, \mt{include} \; S) &=& \mt{include} \; S \\
  \mt{selfify}(M, \mt{constraint} \; c_1 \sim c_2) &=& \mt{constraint} \; c_1 \sim c_2 \\
  \mt{selfify}(M, \mt{class} \; x :: \kappa) &=& \mt{class} \; x :: \kappa = M.x \\
  \mt{selfify}(M, \mt{class} \; x :: \kappa = c) &=& \mt{class} \; x :: \kappa = c \\
\end{eqnarray*}

\subsection{Module Projection}

\begin{eqnarray*}
  \mt{proj}(M, \mt{con} \; x :: \kappa \; \overline{s}, \mt{con} \; x) &=& \kappa \\
  \mt{proj}(M, \mt{con} \; x :: \kappa = c \; \overline{s}, \mt{con} \; x) &=& (\kappa, c) \\
  \mt{proj}(M, \mt{datatype} \; x \; \overline{y} = \overline{dc} \; \overline{s}, \mt{con} \; x) &=& \mt{Type}^{\mt{len}(\overline{y})} \to \mt{Type} \\
  \mt{proj}(M, \mt{datatype} \; x = \mt{datatype} \; M'.z \; \overline{s}, \mt{con} \; x) &=& (\mt{Type}^{\mt{len}(\overline{y})} \to \mt{Type}, M'.z) \textrm{ (where $\Gamma \vdash M' : \mt{sig} \; \overline{s'} \; \mt{end}$} \\
  && \textrm{and $\mt{proj}(M', \overline{s'}, \mt{datatype} \; z) = (\overline{y}, \overline{dc})$)} \\
  \mt{proj}(M, \mt{class} \; x :: \kappa \; \overline{s}, \mt{con} \; x) &=& \kappa \to \mt{Type} \\
  \mt{proj}(M, \mt{class} \; x :: \kappa = c \; \overline{s}, \mt{con} \; x) &=& (\kappa \to \mt{Type}, c) \\
  \\
  \mt{proj}(M, \mt{datatype} \; x \; \overline{y} = \overline{dc} \; \overline{s}, \mt{datatype} \; x) &=& (\overline{y}, \overline{dc}) \\
  \mt{proj}(M, \mt{datatype} \; x = \mt{datatype} \; M'.z \; \overline{s}, \mt{con} \; x) &=& \mt{proj}(M', \overline{s'}, \mt{datatype} \; z) \textrm{ (where $\Gamma \vdash M' : \mt{sig} \; \overline{s'} \; \mt{end}$)} \\
  \\
  \mt{proj}(M, \mt{val} \; x : \tau \; \overline{s}, \mt{val} \; x) &=& \tau \\
  \mt{proj}(M, \mt{datatype} \; x \; \overline{y} = \overline{dc} \; \overline{s}, \mt{val} \; X) &=& \overline{y ::: \mt{Type}} \to M.x \; \overline y \textrm{ (where $X \in \overline{dc}$)} \\
  \mt{proj}(M, \mt{datatype} \; x \; \overline{y} = \overline{dc} \; \overline{s}, \mt{val} \; X) &=& \overline{y ::: \mt{Type}} \to \tau \to M.x \; \overline y \textrm{ (where $X \; \mt{of} \; \tau \in \overline{dc}$)} \\
  \mt{proj}(M, \mt{datatype} \; x = \mt{datatype} \; M'.z, \mt{val} \; X) &=& \overline{y ::: \mt{Type}} \to M.x \; \overline y \textrm{ (where $\Gamma \vdash M' : \mt{sig} \; \overline{s'} \; \mt{end}$} \\
  && \textrm{and $\mt{proj}(M', \overline{s'}, \mt{datatype} \; z = (\overline{y}, \overline{dc})$ and $X \in \overline{dc}$)} \\
  \mt{proj}(M, \mt{datatype} \; x = \mt{datatype} \; M'.z, \mt{val} \; X) &=& \overline{y ::: \mt{Type}} \to \tau \to M.x \; \overline y \textrm{ (where $\Gamma \vdash M' : \mt{sig} \; \overline{s'} \; \mt{end}$} \\
  && \textrm{and $\mt{proj}(M', \overline{s'}, \mt{datatype} \; z = (\overline{y}, \overline{dc})$ and $X \; \mt{of} \; \tau \in \overline{dc}$)} \\
  \\
  \mt{proj}(M, \mt{structure} \; X : S \; \overline{s}, \mt{structure} \; X) &=& S \\
  \\
  \mt{proj}(M, \mt{signature} \; X = S \; \overline{s}, \mt{signature} \; X) &=& S \\
  \\
  \mt{proj}(M, \mt{con} \; x :: \kappa \; \overline{s}, V) &=& [x \mapsto M.x]\mt{proj}(M, \overline{s}, V) \\
  \mt{proj}(M, \mt{con} \; x :: \kappa = c \; \overline{s}, V) &=& [x \mapsto M.x]\mt{proj}(M, \overline{s}, V) \\
  \mt{proj}(M, \mt{datatype} \; x \; \overline{y} = \overline{dc} \; \overline{s}, V) &=& [x \mapsto M.x]\mt{proj}(M, \overline{s}, V) \\
  \mt{proj}(M, \mt{datatype} \; x = \mt{datatype} \; M'.z \; \overline{s}, V) &=& [x \mapsto M.x]\mt{proj}(M, \overline{s}, V) \\
  \mt{proj}(M, \mt{val} \; x : \tau \; \overline{s}, V) &=& \mt{proj}(M, \overline{s}, V) \\
  \mt{proj}(M, \mt{structure} \; X : S \; \overline{s}, V) &=& [X \mapsto M.X]\mt{proj}(M, \overline{s}, V) \\
  \mt{proj}(M, \mt{signature} \; X = S \; \overline{s}, V) &=& [X \mapsto M.X]\mt{proj}(M, \overline{s}, V) \\
  \mt{proj}(M, \mt{include} \; S \; \overline{s}, V) &=& \mt{proj}(M, \overline{s'} \; \overline{s}, V) \textrm{ (where $\Gamma \vdash S \equiv \mt{sig} \; \overline{s'} \; \mt{end}$)} \\
  \mt{proj}(M, \mt{constraint} \; c_1 \sim c_2 \; \overline{s}, V) &=& \mt{proj}(M, \overline{s}, V) \\
  \mt{proj}(M, \mt{class} \; x :: \kappa \; \overline{s}, V) &=& [x \mapsto M.x]\mt{proj}(M, \overline{s}, V) \\
  \mt{proj}(M, \mt{class} \; x :: \kappa = c \; \overline{s}, V) &=& [x \mapsto M.x]\mt{proj}(M, \overline{s}, V) \\
\end{eqnarray*}


\section{Type Inference}

The Ur/Web compiler uses \emph{heuristic type inference}, with no claims of completeness with respect to the declarative specification of the last section.  The rules in use seem to work well in practice.  This section summarizes those rules, to help Ur programmers predict what will work and what won't.

\subsection{Basic Unification}

Type-checkers for languages based on the Hindley-Milner type discipline, like ML and Haskell, take advantage of \emph{principal typing} properties, making complete type inference relatively straightforward.  Inference algorithms are traditionally implemented using type unification variables, at various points asserting equalities between types, in the process discovering the values of type variables.  The Ur/Web compiler uses the same basic strategy, but the complexity of the type system rules out easy completeness.

Type-checking can require evaluating recursive functional programs, thanks to the type-level $\mt{map}$ operator.  When a unification variable appears in such a type, the next step of computation can be undetermined.  The value of that variable might be determined later, but this would be ``too late'' for the unification problems generated at the first occurrence.  This is the essential source of incompleteness.

Nonetheless, the unification engine tends to do reasonably well.  Unlike in ML, polymorphism is never inferred in definitions; it must be indicated explicitly by writing out constructor-level parameters.  By writing these and other annotations, the programmer can generally get the type inference engine to do most of the type reconstruction work.

\subsection{Unifying Record Types}

The type inference engine tries to take advantage of the algebraic rules governing type-level records, as shown in Section \ref{definitional}.  When two constructors of record kind are unified, they are reduced to normal forms, with like terms crossed off from each normal form until, hopefully, nothing remains.  This cannot be complete, with the inclusion of unification variables.  The type-checker can help you understand what goes wrong when the process fails, as it outputs the unmatched remainders of the two normal forms.

\subsection{\label{typeclasses}Constructor Classes}

Ur includes a constructor class facility inspired by Haskell's.  The current version is very rudimentary, only supporting instances for particular constructors built up from abstract constructors and datatypes and type-level application.

Constructor classes are integrated with the module system.  A constructor class of kind $\kappa$ is just a constructor of kind $\kappa \to \mt{Type}$.  By marking such a constructor $c$ as a constructor class, the programmer instructs the type inference engine to, in each scope, record all values of types $c \; c'$ as \emph{instances}.  Any function argument whose type is of such a form is treated as implicit, to be determined by examining the current instance database.

The ``dictionary encoding'' often used in Haskell implementations is made explicit in Ur.  Constructor class instances are just properly-typed values, and they can also be considered as ``proofs'' of membership in the class.  In some cases, it is useful to pass these proofs around explicitly.  An underscore written where a proof is expected will also be inferred, if possible, from the current instance database.

Just as for constructors, constructors classes may be exported from modules, and they may be exported as concrete or abstract.  Concrete constructor classes have their ``real'' definitions exposed, so that client code may add new instances freely.  Abstract constructor classes are useful as ``predicates'' that can be used to enforce invariants, as we will see in some definitions of SQL syntax in the Ur/Web standard library.

\subsection{Reverse-Engineering Record Types}

It's useful to write Ur functions and functors that take record constructors as inputs, but these constructors can grow quite long, even though their values are often implied by other arguments.  The compiler uses a simple heuristic to infer the values of unification variables that are mapped over, yielding known results.  If the result is empty, we're done; if it's not empty, we replace a single unification variable with a new constructor formed from three new unification variables, as in $[\alpha = \beta] \rc \gamma$.  This process can often be repeated to determine a unification variable fully.

\subsection{Implicit Arguments in Functor Applications}

Constructor, constraint, and constructor class witness members of structures may be omitted, when those structures are used in contexts where their assigned signatures imply how to fill in those missing members.  This feature combines well with reverse-engineering to allow for uses of complicated meta-programming functors with little more code than would be necessary to invoke an untyped, ad-hoc code generator.


\section{The Ur Standard Library}

The built-in parts of the Ur/Web standard library are described by the signature in \texttt{lib/basis.urs} in the distribution.  A module $\mt{Basis}$ ascribing to that signature is available in the initial environment, and every program is implicitly prefixed by $\mt{open} \; \mt{Basis}$.

Additionally, other common functions that are definable within Ur are included in \texttt{lib/top.urs} and \texttt{lib/top.ur}.  This $\mt{Top}$ module is also opened implicitly.

The idea behind Ur is to serve as the ideal host for embedded domain-specific languages.  For now, however, the ``generic'' functionality is intermixed with Ur/Web-specific functionality, including in these two library modules.  We hope that these generic library components have types that speak for themselves.  The next section introduces the Ur/Web-specific elements.  Here, we only give the type declarations from the beginning of $\mt{Basis}$.
$$\begin{array}{l}
  \mt{type} \; \mt{int} \\
  \mt{type} \; \mt{float} \\
  \mt{type} \; \mt{string} \\
  \mt{type} \; \mt{time} \\
  \\
  \mt{type} \; \mt{unit} = \{\} \\
  \\
  \mt{datatype} \; \mt{bool} = \mt{False} \mid \mt{True} \\
  \\
  \mt{datatype} \; \mt{option} \; \mt{t} = \mt{None} \mid \mt{Some} \; \mt{of} \; \mt{t}
\end{array}$$

Another important generic Ur element comes at the beginning of \texttt{top.urs}.

$$\begin{array}{l}
  \mt{con} \; \mt{folder} :: \mt{K} \longrightarrow \{\mt{K}\} \to \mt{Type} \\
  \\
  \mt{val} \; \mt{fold} : \mt{K} \longrightarrow \mt{tf} :: (\{\mt{K}\} \to \mt{Type}) \\
  \hspace{.1in} \to (\mt{nm} :: \mt{Name} \to \mt{v} :: \mt{K} \to \mt{r} :: \{\mt{K}\} \to [[\mt{nm}] \sim \mt{r}] \Rightarrow \\
  \hspace{.2in} \mt{tf} \; \mt{r} \to \mt{tf} \; ([\mt{nm} = \mt{v}] \rc \mt{r})) \\
  \hspace{.1in} \to \mt{tf} \; [] \\
  \hspace{.1in} \to \mt{r} :: \{\mt{K}\} \to \mt{folder} \; \mt{r} \to \mt{tf} \; \mt{r}
\end{array}$$

For a type-level record $\mt{r}$, a $\mt{folder} \; \mt{r}$ encodes a permutation of $\mt{r}$'s elements.  The $\mt{fold}$ function can be called on a $\mt{folder}$ to iterate over the elements of $\mt{r}$ in that order.  $\mt{fold}$ is parameterized on a type-level function to be used to calculate the type of each intermediate result of folding.  After processing a subset $\mt{r'}$ of $\mt{r}$'s entries, the type of the accumulator should be $\mt{tf} \; \mt{r'}$.  The next two expression arguments to $\mt{fold}$ are the usual step function and initial accumulator, familiar from fold functions over lists.  The final two arguments are the record to fold over and a $\mt{folder}$ for it.

The Ur compiler treates $\mt{folder}$ like a constructor class, using built-in rules to infer $\mt{folder}$s for records with known structure.  The order in which field names are mentioned in source code is used as a hint about the permutation that the programmer would like.


\section{The Ur/Web Standard Library}

\subsection{Monads}

The Ur Basis defines the monad constructor class from Haskell.

$$\begin{array}{l}
  \mt{class} \; \mt{monad} :: \mt{Type} \to \mt{Type} \\
  \mt{val} \; \mt{return} : \mt{m} ::: (\mt{Type} \to \mt{Type}) \to \mt{t} ::: \mt{Type} \\
  \hspace{.1in} \to \mt{monad} \; \mt{m} \\
  \hspace{.1in} \to \mt{t} \to \mt{m} \; \mt{t} \\
  \mt{val} \; \mt{bind} : \mt{m} ::: (\mt{Type} \to \mt{Type}) \to \mt{t1} ::: \mt{Type} \to \mt{t2} ::: \mt{Type} \\
  \hspace{.1in} \to \mt{monad} \; \mt{m} \\
  \hspace{.1in} \to \mt{m} \; \mt{t1} \to (\mt{t1} \to \mt{m} \; \mt{t2}) \\
  \hspace{.1in} \to \mt{m} \; \mt{t2}
\end{array}$$

\subsection{Transactions}

Ur is a pure language; we use Haskell's trick to support controlled side effects.  The standard library defines a monad $\mt{transaction}$, meant to stand for actions that may be undone cleanly.  By design, no other kinds of actions are supported.
$$\begin{array}{l}
  \mt{con} \; \mt{transaction} :: \mt{Type} \to \mt{Type} \\
  \mt{val} \; \mt{transaction\_monad} : \mt{monad} \; \mt{transaction}
\end{array}$$

\subsection{HTTP}

There are transactions for reading an HTTP header by name and for getting and setting strongly-typed cookies.  Cookies may only be created by the $\mt{cookie}$ declaration form, ensuring that they be named consistently based on module structure.
$$\begin{array}{l}
\mt{val} \; \mt{requestHeader} : \mt{string} \to \mt{transaction} \; (\mt{option} \; \mt{string}) \\
\\
\mt{con} \; \mt{http\_cookie} :: \mt{Type} \to \mt{Type} \\
\mt{val} \; \mt{getCookie} : \mt{t} ::: \mt{Type} \to \mt{http\_cookie} \; \mt{t} \to \mt{transaction} \; (\mt{option} \; \mt{t}) \\
\mt{val} \; \mt{setCookie} : \mt{t} ::: \mt{Type} \to \mt{http\_cookie} \; \mt{t} \to \mt{t} \to \mt{transaction} \; \mt{unit}
\end{array}$$

\subsection{SQL}

The fundamental unit of interest in the embedding of SQL is tables, described by a type family and creatable only via the $\mt{table}$ declaration form.
$$\begin{array}{l}
  \mt{con} \; \mt{sql\_table} :: \{\mt{Type}\} \to \mt{Type}
\end{array}$$

\subsubsection{Queries}

A final query is constructed via the $\mt{sql\_query}$ function.  Constructor arguments respectively specify the table fields we select (as records mapping tables to the subsets of their fields that we choose) and the (always named) extra expressions that we select.
$$\begin{array}{l}
  \mt{con} \; \mt{sql\_query} :: \{\{\mt{Type}\}\} \to \{\mt{Type}\} \to \mt{Type} \\
  \mt{val} \; \mt{sql\_query} : \mt{tables} ::: \{\{\mt{Type}\}\} \\
  \hspace{.1in} \to \mt{selectedFields} ::: \{\{\mt{Type}\}\} \\
  \hspace{.1in} \to \mt{selectedExps} ::: \{\mt{Type}\} \\
  \hspace{.1in} \to \{\mt{Rows} : \mt{sql\_query1} \; \mt{tables} \; \mt{selectedFields} \; \mt{selectedExps}, \\
  \hspace{.2in} \mt{OrderBy} : \mt{sql\_order\_by} \; \mt{tables} \; \mt{selectedExps}, \\
  \hspace{.2in} \mt{Limit} : \mt{sql\_limit}, \\
  \hspace{.2in} \mt{Offset} : \mt{sql\_offset}\} \\
  \hspace{.1in} \to \mt{sql\_query} \; \mt{selectedFields} \; \mt{selectedExps}
\end{array}$$

Queries are used by folding over their results inside transactions.
$$\begin{array}{l}
  \mt{val} \; \mt{query} : \mt{tables} ::: \{\{\mt{Type}\}\} \to \mt{exps} ::: \{\mt{Type}\} \to \lambda [\mt{tables} \sim \mt{exps}] \Rightarrow \mt{state} ::: \mt{Type} \to \mt{sql\_query} \; \mt{tables} \; \mt{exps} \\
  \hspace{.1in} \to (\$(\mt{exps} \rc \mt{map} \; (\lambda \mt{fields} :: \{\mt{Type}\} \Rightarrow \$\mt{fields}) \; \mt{tables}) \\
  \hspace{.2in} \to \mt{state} \to \mt{transaction} \; \mt{state}) \\
  \hspace{.1in} \to \mt{state} \to \mt{transaction} \; \mt{state}
\end{array}$$

Most of the complexity of the query encoding is in the type $\mt{sql\_query1}$, which includes simple queries and derived queries based on relational operators.  Constructor arguments respectively specify the tables we select from, the subset of fields that we keep from each table for the result rows, and the extra expressions that we select.
$$\begin{array}{l}
  \mt{con} \; \mt{sql\_query1} :: \{\{\mt{Type}\}\} \to \{\{\mt{Type}\}\} \to \{\mt{Type}\} \to \mt{Type} \\
  \\
  \mt{type} \; \mt{sql\_relop} \\
  \mt{val} \; \mt{sql\_union} : \mt{sql\_relop} \\
  \mt{val} \; \mt{sql\_intersect} : \mt{sql\_relop} \\
  \mt{val} \; \mt{sql\_except} : \mt{sql\_relop} \\
  \mt{val} \; \mt{sql\_relop} : \mt{tables1} ::: \{\{\mt{Type}\}\} \\
  \hspace{.1in} \to \mt{tables2} ::: \{\{\mt{Type}\}\} \\
  \hspace{.1in} \to \mt{selectedFields} ::: \{\{\mt{Type}\}\} \\
  \hspace{.1in} \to \mt{selectedExps} ::: \{\mt{Type}\} \\
  \hspace{.1in} \to \mt{sql\_relop} \\
  \hspace{.1in} \to \mt{sql\_query1} \; \mt{tables1} \; \mt{selectedFields} \; \mt{selectedExps} \\
  \hspace{.1in} \to \mt{sql\_query1} \; \mt{tables2} \; \mt{selectedFields} \; \mt{selectedExps} \\
  \hspace{.1in} \to \mt{sql\_query1} \; \mt{selectedFields} \; \mt{selectedFields} \; \mt{selectedExps}
\end{array}$$

$$\begin{array}{l}
  \mt{val} \; \mt{sql\_query1} : \mt{tables} ::: \{\{\mt{Type}\}\} \\
  \hspace{.1in} \to \mt{grouped} ::: \{\{\mt{Type}\}\} \\
  \hspace{.1in} \to \mt{selectedFields} ::: \{\{\mt{Type}\}\} \\
  \hspace{.1in} \to \mt{selectedExps} ::: \{\mt{Type}\} \\
  \hspace{.1in} \to \{\mt{From} : \$(\mt{map} \; \mt{sql\_table} \; \mt{tables}), \\
  \hspace{.2in} \mt{Where} : \mt{sql\_exp} \; \mt{tables} \; [] \; [] \; \mt{bool}, \\
  \hspace{.2in} \mt{GroupBy} : \mt{sql\_subset} \; \mt{tables} \; \mt{grouped}, \\
  \hspace{.2in} \mt{Having} : \mt{sql\_exp} \; \mt{grouped} \; \mt{tables} \; [] \; \mt{bool}, \\
  \hspace{.2in} \mt{SelectFields} : \mt{sql\_subset} \; \mt{grouped} \; \mt{selectedFields}, \\
  \hspace{.2in} \mt {SelectExps} : \$(\mt{map} \; (\mt{sql\_exp} \; \mt{grouped} \; \mt{tables} \; []) \; \mt{selectedExps}) \} \\
  \hspace{.1in} \to \mt{sql\_query1} \; \mt{tables} \; \mt{selectedFields} \; \mt{selectedExps}
\end{array}$$

To encode projection of subsets of fields in $\mt{SELECT}$ clauses, and to encode $\mt{GROUP} \; \mt{BY}$ clauses, we rely on a type family $\mt{sql\_subset}$, capturing what it means for one record of table fields to be a subset of another.  The main constructor $\mt{sql\_subset}$ ``proves subset facts'' by requiring a split of a record into kept and dropped parts.  The extra constructor $\mt{sql\_subset\_all}$ is a convenience for keeping all fields of a record.
$$\begin{array}{l}
  \mt{con} \; \mt{sql\_subset} :: \{\{\mt{Type}\}\} \to \{\{\mt{Type}\}\} \to \mt{Type} \\
  \mt{val} \; \mt{sql\_subset} : \mt{keep\_drop} :: \{(\{\mt{Type}\} \times \{\mt{Type}\})\} \\
  \hspace{.1in} \to \mt{sql\_subset} \\
  \hspace{.2in} (\mt{map} \; (\lambda \mt{fields} :: (\{\mt{Type}\} \times \{\mt{Type}\}) \Rightarrow \mt{fields}.1 \rc \mt{fields}.2)\; \mt{keep\_drop}) \\
  \hspace{.2in} (\mt{map} \; (\lambda \mt{fields} :: (\{\mt{Type}\} \times \{\mt{Type}\}) \Rightarrow \mt{fields}.1) \; \mt{keep\_drop}) \\
\mt{val} \; \mt{sql\_subset\_all} : \mt{tables} :: \{\{\mt{Type}\}\} \to \mt{sql\_subset} \; \mt{tables} \; \mt{tables}
\end{array}$$

SQL expressions are used in several places, including $\mt{SELECT}$, $\mt{WHERE}$, $\mt{HAVING}$, and $\mt{ORDER} \; \mt{BY}$ clauses.  They reify a fragment of the standard SQL expression language, while making it possible to inject ``native'' Ur values in some places.  The arguments to the $\mt{sql\_exp}$ type family respectively give the unrestricted-availability table fields, the table fields that may only be used in arguments to aggregate functions, the available selected expressions, and the type of the expression.
$$\begin{array}{l}
  \mt{con} \; \mt{sql\_exp} :: \{\{\mt{Type}\}\} \to \{\{\mt{Type}\}\} \to \{\mt{Type}\} \to \mt{Type} \to \mt{Type}
\end{array}$$

Any field in scope may be converted to an expression.
$$\begin{array}{l}
  \mt{val} \; \mt{sql\_field} : \mt{otherTabs} ::: \{\{\mt{Type}\}\} \to \mt{otherFields} ::: \{\mt{Type}\} \\
  \hspace{.1in} \to \mt{fieldType} ::: \mt{Type} \to \mt{agg} ::: \{\{\mt{Type}\}\} \\
  \hspace{.1in} \to \mt{exps} ::: \{\mt{Type}\} \\
  \hspace{.1in} \to \mt{tab} :: \mt{Name} \to \mt{field} :: \mt{Name} \\
  \hspace{.1in} \to \mt{sql\_exp} \; ([\mt{tab} = [\mt{field} = \mt{fieldType}] \rc \mt{otherFields}] \rc \mt{otherTabs}) \; \mt{agg} \; \mt{exps} \; \mt{fieldType}
\end{array}$$

There is an analogous function for referencing named expressions.
$$\begin{array}{l}
  \mt{val} \; \mt{sql\_exp} : \mt{tabs} ::: \{\{\mt{Type}\}\} \to \mt{agg} ::: \{\{\mt{Type}\}\} \to \mt{t} ::: \mt{Type} \to \mt{rest} ::: \{\mt{Type}\} \to \mt{nm} :: \mt{Name} \\
  \hspace{.1in} \to \mt{sql\_exp} \; \mt{tabs} \; \mt{agg} \; ([\mt{nm} = \mt{t}] \rc \mt{rest}) \; \mt{t}
\end{array}$$

Ur values of appropriate types may be injected into SQL expressions.
$$\begin{array}{l}
  \mt{class} \; \mt{sql\_injectable} \\
  \mt{val} \; \mt{sql\_bool} : \mt{sql\_injectable} \; \mt{bool} \\
  \mt{val} \; \mt{sql\_int} : \mt{sql\_injectable} \; \mt{int} \\
  \mt{val} \; \mt{sql\_float} : \mt{sql\_injectable} \; \mt{float} \\
  \mt{val} \; \mt{sql\_string} : \mt{sql\_injectable} \; \mt{string} \\
  \mt{val} \; \mt{sql\_time} : \mt{sql\_injectable} \; \mt{time} \\
  \mt{val} \; \mt{sql\_option\_bool} : \mt{sql\_injectable} \; (\mt{option} \; \mt{bool}) \\
  \mt{val} \; \mt{sql\_option\_int} : \mt{sql\_injectable} \; (\mt{option} \; \mt{int}) \\
  \mt{val} \; \mt{sql\_option\_float} : \mt{sql\_injectable} \; (\mt{option} \; \mt{float}) \\
  \mt{val} \; \mt{sql\_option\_string} : \mt{sql\_injectable} \; (\mt{option} \; \mt{string}) \\
  \mt{val} \; \mt{sql\_option\_time} : \mt{sql\_injectable} \; (\mt{option} \; \mt{time}) \\
  \mt{val} \; \mt{sql\_inject} : \mt{tables} ::: \{\{\mt{Type}\}\} \to \mt{agg} ::: \{\{\mt{Type}\}\} \to \mt{exps} ::: \{\mt{Type}\} \to \mt{t} ::: \mt{Type} \to \mt{sql\_injectable} \; \mt{t} \\
  \hspace{.1in} \to \mt{t} \to \mt{sql\_exp} \; \mt{tables} \; \mt{agg} \; \mt{exps} \; \mt{t}
\end{array}$$

We have the SQL nullness test, which is necessary because of the strange SQL semantics of equality in the presence of null values.
$$\begin{array}{l}
  \mt{val} \; \mt{sql\_is\_null} : \mt{tables} ::: \{\{\mt{Type}\}\} \to \mt{agg} ::: \{\{\mt{Type}\}\} \to \mt{exps} ::: \{\mt{Type}\} \to \mt{t} ::: \mt{Type} \\
  \hspace{.1in} \to \mt{sql\_exp} \; \mt{tables} \; \mt{agg} \; \mt{exps} \; (\mt{option} \; \mt{t}) \to \mt{sql\_exp} \; \mt{tables} \; \mt{agg} \; \mt{exps} \; \mt{bool}
\end{array}$$

We have generic nullary, unary, and binary operators.
$$\begin{array}{l}
  \mt{con} \; \mt{sql\_nfunc} :: \mt{Type} \to \mt{Type} \\
  \mt{val} \; \mt{sql\_current\_timestamp} : \mt{sql\_nfunc} \; \mt{time} \\
  \mt{val} \; \mt{sql\_nfunc} : \mt{tables} ::: \{\{\mt{Type}\}\} \to \mt{agg} ::: \{\{\mt{Type}\}\} \to \mt{exps} ::: \{\mt{Type}\} \to \mt{t} ::: \mt{Type} \\
  \hspace{.1in} \to \mt{sql\_nfunc} \; \mt{t} \to \mt{sql\_exp} \; \mt{tables} \; \mt{agg} \; \mt{exps} \; \mt{t} \\\end{array}$$

$$\begin{array}{l}
  \mt{con} \; \mt{sql\_unary} :: \mt{Type} \to \mt{Type} \to \mt{Type} \\
  \mt{val} \; \mt{sql\_not} : \mt{sql\_unary} \; \mt{bool} \; \mt{bool} \\
  \mt{val} \; \mt{sql\_unary} : \mt{tables} ::: \{\{\mt{Type}\}\} \to \mt{agg} ::: \{\{\mt{Type}\}\} \to \mt{exps} ::: \{\mt{Type}\} \to \mt{arg} ::: \mt{Type} \to \mt{res} ::: \mt{Type} \\
  \hspace{.1in} \to \mt{sql\_unary} \; \mt{arg} \; \mt{res} \to \mt{sql\_exp} \; \mt{tables} \; \mt{agg} \; \mt{exps} \; \mt{arg} \to \mt{sql\_exp} \; \mt{tables} \; \mt{agg} \; \mt{exps} \; \mt{res} \\
\end{array}$$

$$\begin{array}{l}
  \mt{con} \; \mt{sql\_binary} :: \mt{Type} \to \mt{Type} \to \mt{Type} \to \mt{Type} \\
  \mt{val} \; \mt{sql\_and} : \mt{sql\_binary} \; \mt{bool} \; \mt{bool} \; \mt{bool} \\
  \mt{val} \; \mt{sql\_or} : \mt{sql\_binary} \; \mt{bool} \; \mt{bool} \; \mt{bool} \\
  \mt{val} \; \mt{sql\_binary} : \mt{tables} ::: \{\{\mt{Type}\}\} \to \mt{agg} ::: \{\{\mt{Type}\}\} \to \mt{exps} ::: \{\mt{Type}\} \to \mt{arg_1} ::: \mt{Type} \to \mt{arg_2} ::: \mt{Type} \to \mt{res} ::: \mt{Type} \\
  \hspace{.1in} \to \mt{sql\_binary} \; \mt{arg_1} \; \mt{arg_2} \; \mt{res} \to \mt{sql\_exp} \; \mt{tables} \; \mt{agg} \; \mt{exps} \; \mt{arg_1} \to \mt{sql\_exp} \; \mt{tables} \; \mt{agg} \; \mt{exps} \; \mt{arg_2} \to \mt{sql\_exp} \; \mt{tables} \; \mt{agg} \; \mt{exps} \; \mt{res}
\end{array}$$

$$\begin{array}{l}
  \mt{class} \; \mt{sql\_arith} \\
  \mt{val} \; \mt{sql\_int\_arith} : \mt{sql\_arith} \; \mt{int} \\
  \mt{val} \; \mt{sql\_float\_arith} : \mt{sql\_arith} \; \mt{float} \\
  \mt{val} \; \mt{sql\_neg} : \mt{t} ::: \mt{Type} \to \mt{sql\_arith} \; \mt{t} \to \mt{sql\_unary} \; \mt{t} \; \mt{t} \\
  \mt{val} \; \mt{sql\_plus} : \mt{t} ::: \mt{Type} \to \mt{sql\_arith} \; \mt{t} \to \mt{sql\_binary} \; \mt{t} \; \mt{t} \; \mt{t} \\
  \mt{val} \; \mt{sql\_minus} : \mt{t} ::: \mt{Type} \to \mt{sql\_arith} \; \mt{t} \to \mt{sql\_binary} \; \mt{t} \; \mt{t} \; \mt{t} \\
  \mt{val} \; \mt{sql\_times} : \mt{t} ::: \mt{Type} \to \mt{sql\_arith} \; \mt{t} \to \mt{sql\_binary} \; \mt{t} \; \mt{t} \; \mt{t} \\
  \mt{val} \; \mt{sql\_div} : \mt{t} ::: \mt{Type} \to \mt{sql\_arith} \; \mt{t} \to \mt{sql\_binary} \; \mt{t} \; \mt{t} \; \mt{t} \\
  \mt{val} \; \mt{sql\_mod} : \mt{sql\_binary} \; \mt{int} \; \mt{int} \; \mt{int}
\end{array}$$

Finally, we have aggregate functions.  The $\mt{COUNT(\ast)}$ syntax is handled specially, since it takes no real argument.  The other aggregate functions are placed into a general type family, using constructor classes to restrict usage to properly-typed arguments.  The key aspect of the $\mt{sql\_aggregate}$ function's type is the shift of aggregate-function-only fields into unrestricted fields.

$$\begin{array}{l}
  \mt{val} \; \mt{sql\_count} : \mt{tables} ::: \{\{\mt{Type}\}\} \to \mt{agg} ::: \{\{\mt{Type}\}\} \to \mt{exps} ::: \{\mt{Type}\} \to \mt{sql\_exp} \; \mt{tables} \; \mt{agg} \; \mt{exps} \; \mt{int}
\end{array}$$

$$\begin{array}{l}
  \mt{con} \; \mt{sql\_aggregate} :: \mt{Type} \to \mt{Type} \\
  \mt{val} \; \mt{sql\_aggregate} : \mt{tables} ::: \{\{\mt{Type}\}\} \to \mt{agg} ::: \{\{\mt{Type}\}\} \to \mt{exps} ::: \{\mt{Type}\} \to \mt{t} ::: \mt{Type} \\
  \hspace{.1in} \to \mt{sql\_aggregate} \; \mt{t} \to \mt{sql\_exp} \; \mt{agg} \; \mt{agg} \; \mt{exps} \; \mt{t} \to \mt{sql\_exp} \; \mt{tables} \; \mt{agg} \; \mt{exps} \; \mt{t}
\end{array}$$
 
$$\begin{array}{l}
  \mt{class} \; \mt{sql\_summable} \\
  \mt{val} \; \mt{sql\_summable\_int} : \mt{sql\_summable} \; \mt{int} \\
  \mt{val} \; \mt{sql\_summable\_float} : \mt{sql\_summable} \; \mt{float} \\
  \mt{val} \; \mt{sql\_avg} : \mt{t} ::: \mt{Type} \to \mt{sql\_summable} \; \mt{t} \to \mt{sql\_aggregate} \; \mt{t} \\
  \mt{val} \; \mt{sql\_sum} : \mt{t} ::: \mt{Type} \to \mt{sql\_summable} \mt{t} \to \mt{sql\_aggregate} \; \mt{t}
\end{array}$$

$$\begin{array}{l}
  \mt{class} \; \mt{sql\_maxable} \\
  \mt{val} \; \mt{sql\_maxable\_int} : \mt{sql\_maxable} \; \mt{int} \\
  \mt{val} \; \mt{sql\_maxable\_float} : \mt{sql\_maxable} \; \mt{float} \\
  \mt{val} \; \mt{sql\_maxable\_string} : \mt{sql\_maxable} \; \mt{string} \\
  \mt{val} \; \mt{sql\_maxable\_time} : \mt{sql\_maxable} \; \mt{time} \\
  \mt{val} \; \mt{sql\_max} : \mt{t} ::: \mt{Type} \to \mt{sql\_maxable} \; \mt{t} \to \mt{sql\_aggregate} \; \mt{t} \\
  \mt{val} \; \mt{sql\_min} : \mt{t} ::: \mt{Type} \to \mt{sql\_maxable} \; \mt{t} \to \mt{sql\_aggregate} \; \mt{t}
\end{array}$$

We wrap up the definition of query syntax with the types used in representing $\mt{ORDER} \; \mt{BY}$, $\mt{LIMIT}$, and $\mt{OFFSET}$ clauses.
$$\begin{array}{l}
  \mt{type} \; \mt{sql\_direction} \\
  \mt{val} \; \mt{sql\_asc} : \mt{sql\_direction} \\
  \mt{val} \; \mt{sql\_desc} : \mt{sql\_direction} \\
  \\
  \mt{con} \; \mt{sql\_order\_by} :: \{\{\mt{Type}\}\} \to \{\mt{Type}\} \to \mt{Type} \\
  \mt{val} \; \mt{sql\_order\_by\_Nil} : \mt{tables} ::: \{\{\mt{Type}\}\} \to \mt{exps} :: \{\mt{Type}\} \to \mt{sql\_order\_by} \; \mt{tables} \; \mt{exps} \\
  \mt{val} \; \mt{sql\_order\_by\_Cons} : \mt{tables} ::: \{\{\mt{Type}\}\} \to \mt{exps} ::: \{\mt{Type}\} \to \mt{t} ::: \mt{Type} \\
  \hspace{.1in} \to \mt{sql\_exp} \; \mt{tables} \; [] \; \mt{exps} \; \mt{t} \to \mt{sql\_direction} \to \mt{sql\_order\_by} \; \mt{tables} \; \mt{exps} \to \mt{sql\_order\_by} \; \mt{tables} \; \mt{exps} \\
  \\
  \mt{type} \; \mt{sql\_limit} \\
  \mt{val} \; \mt{sql\_no\_limit} : \mt{sql\_limit} \\
  \mt{val} \; \mt{sql\_limit} : \mt{int} \to \mt{sql\_limit} \\
  \\
  \mt{type} \; \mt{sql\_offset} \\
  \mt{val} \; \mt{sql\_no\_offset} : \mt{sql\_offset} \\
  \mt{val} \; \mt{sql\_offset} : \mt{int} \to \mt{sql\_offset}
\end{array}$$


\subsubsection{DML}

The Ur/Web library also includes an embedding of a fragment of SQL's DML, the Data Manipulation Language, for modifying database tables.  Any piece of DML may be executed in a transaction.

$$\begin{array}{l}
  \mt{type} \; \mt{dml} \\
  \mt{val} \; \mt{dml} : \mt{dml} \to \mt{transaction} \; \mt{unit}
\end{array}$$

Properly-typed records may be used to form $\mt{INSERT}$ commands.
$$\begin{array}{l}
  \mt{val} \; \mt{insert} : \mt{fields} ::: \{\mt{Type}\} \to \mt{sql\_table} \; \mt{fields} \\
  \hspace{.1in} \to \$(\mt{map} \; (\mt{sql\_exp} \; [] \; [] \; []) \; \mt{fields}) \to \mt{dml}
\end{array}$$

An $\mt{UPDATE}$ command is formed from a choice of which table fields to leave alone and which to change, along with an expression to use to compute the new value of each changed field and a $\mt{WHERE}$ clause.
$$\begin{array}{l}
  \mt{val} \; \mt{update} : \mt{unchanged} ::: \{\mt{Type}\} \to \mt{changed} :: \{\mt{Type}\} \to \lambda [\mt{changed} \sim \mt{unchanged}] \\
  \hspace{.1in} \Rightarrow \$(\mt{map} \; (\mt{sql\_exp} \; [\mt{T} = \mt{changed} \rc \mt{unchanged}] \; [] \; []) \; \mt{changed}) \\
  \hspace{.1in} \to \mt{sql\_table} \; (\mt{changed} \rc \mt{unchanged}) \to \mt{sql\_exp} \; [\mt{T} = \mt{changed} \rc \mt{unchanged}] \; [] \; [] \; \mt{bool} \to \mt{dml}
\end{array}$$

A $\mt{DELETE}$ command is formed from a table and a $\mt{WHERE}$ clause.
$$\begin{array}{l}
  \mt{val} \; \mt{delete} : \mt{fields} ::: \{\mt{Type}\} \to \mt{sql\_table} \; \mt{fields} \to \mt{sql\_exp} \; [\mt{T} = \mt{fields}] \; [] \; [] \; \mt{bool} \to \mt{dml}
\end{array}$$

\subsubsection{Sequences}

SQL sequences are counters with concurrency control, often used to assign unique IDs.  Ur/Web supports them via a simple interface.  The only way to create a sequence is with the $\mt{sequence}$ declaration form.

$$\begin{array}{l}
  \mt{type} \; \mt{sql\_sequence} \\
  \mt{val} \; \mt{nextval} : \mt{sql\_sequence} \to \mt{transaction} \; \mt{int}
\end{array}$$


\subsection{XML}

Ur/Web's library contains an encoding of XML syntax and semantic constraints.  We make no effort to follow the standards governing XML schemas.  Rather, XML fragments are viewed more as values of ML datatypes, and we only track which tags are allowed inside which other tags.

The basic XML type family has arguments respectively indicating the \emph{context} of a fragment, the fields that the fragment expects to be bound on entry (and their types), and the fields that the fragment will bind (and their types).  Contexts are a record-based ``poor man's subtyping'' encoding, with each possible set of valid tags corresponding to a different context record.  The arguments dealing with field binding are only relevant to HTML forms.
$$\begin{array}{l}
  \mt{con} \; \mt{xml} :: \{\mt{Unit}\} \to \{\mt{Type}\} \to \{\mt{Type}\} \to \mt{Type}
\end{array}$$

We also have a type family of XML tags, indexed respectively by the record of optional attributes accepted by the tag, the context in which the tag may be placed, the context required of children of the tag, which form fields the tag uses, and which fields the tag defines.
$$\begin{array}{l}
  \mt{con} \; \mt{tag} :: \{\mt{Type}\} \to \{\mt{Unit}\} \to \{\mt{Unit}\} \to \{\mt{Type}\} \to \{\mt{Type}\} \to \mt{Type}
\end{array}$$

Literal text may be injected into XML as ``CDATA.''
$$\begin{array}{l}
  \mt{val} \; \mt{cdata} : \mt{ctx} ::: \{\mt{Unit}\} \to \mt{use} ::: \{\mt{Type}\} \to \mt{string} \to \mt{xml} \; \mt{ctx} \; \mt{use} \; []
\end{array}$$

There is a function for producing an XML tree with a particular tag at its root.
$$\begin{array}{l}
  \mt{val} \; \mt{tag} : \mt{attrsGiven} ::: \{\mt{Type}\} \to \mt{attrsAbsent} ::: \{\mt{Type}\} \to \mt{ctxOuter} ::: \{\mt{Unit}\} \to \mt{ctxInner} ::: \{\mt{Unit}\} \\
  \hspace{.1in} \to \mt{useOuter} ::: \{\mt{Type}\} \to \mt{useInner} ::: \{\mt{Type}\} \to \mt{bindOuter} ::: \{\mt{Type}\} \to \mt{bindInner} ::: \{\mt{Type}\} \\
  \hspace{.1in} \to \lambda [\mt{attrsGiven} \sim \mt{attrsAbsent}] \; [\mt{useOuter} \sim \mt{useInner}] \; [\mt{bindOuter} \sim \mt{bindInner}] \Rightarrow \$\mt{attrsGiven} \\
  \hspace{.1in} \to \mt{tag} \; (\mt{attrsGiven} \rc \mt{attrsAbsent}) \; \mt{ctxOuter} \; \mt{ctxInner} \; \mt{useOuter} \; \mt{bindOuter} \\
  \hspace{.1in} \to \mt{xml} \; \mt{ctxInner} \; \mt{useInner} \; \mt{bindInner} \to \mt{xml} \; \mt{ctxOuter} \; (\mt{useOuter} \rc \mt{useInner}) \; (\mt{bindOuter} \rc \mt{bindInner})
\end{array}$$

Two XML fragments may be concatenated.
$$\begin{array}{l}
  \mt{val} \; \mt{join} : \mt{ctx} ::: \{\mt{Unit}\} \to \mt{use_1} ::: \{\mt{Type}\} \to \mt{bind_1} ::: \{\mt{Type}\} \to \mt{bind_2} ::: \{\mt{Type}\} \\
  \hspace{.1in} \to \lambda [\mt{use_1} \sim \mt{bind_1}] \; [\mt{bind_1} \sim \mt{bind_2}] \\
  \hspace{.1in} \Rightarrow \mt{xml} \; \mt{ctx} \; \mt{use_1} \; \mt{bind_1} \to \mt{xml} \; \mt{ctx} \; (\mt{use_1} \rc \mt{bind_1}) \; \mt{bind_2} \to \mt{xml} \; \mt{ctx} \; \mt{use_1} \; (\mt{bind_1} \rc \mt{bind_2})
\end{array}$$

Finally, any XML fragment may be updated to ``claim'' to use more form fields than it does.
$$\begin{array}{l}
  \mt{val} \; \mt{useMore} : \mt{ctx} ::: \{\mt{Unit}\} \to \mt{use_1} ::: \{\mt{Type}\} \to \mt{use_2} ::: \{\mt{Type}\} \to \mt{bind} ::: \{\mt{Type}\} \to \lambda [\mt{use_1} \sim \mt{use_2}] \\
  \hspace{.1in} \Rightarrow \mt{xml} \; \mt{ctx} \; \mt{use_1} \; \mt{bind} \to \mt{xml} \; \mt{ctx} \; (\mt{use_1} \rc \mt{use_2}) \; \mt{bind}
\end{array}$$

We will not list here the different HTML tags and related functions from the standard library.  They should be easy enough to understand from the code in \texttt{basis.urs}.  The set of tags in the library is not yet claimed to be complete for HTML standards.

One last useful function is for aborting any page generation, returning some XML as an error message.  This function takes the place of some uses of a general exception mechanism.
$$\begin{array}{l}
  \mt{val} \; \mt{error} : \mt{t} ::: \mt{Type} \to \mt{xml} \; [\mt{Body}] \; [] \; [] \to \mt{t}
\end{array}$$


\subsection{Functional-Reactive Client-Side Programming}

Ur/Web supports running code on web browsers, via automatic compilation to JavaScript.  Most approaches to this kind of coding involve imperative manipulation of the DOM tree representing an HTML document's structure.  Ur/Web follows the \emph{functional-reactive} approach instead.  Programs may allocate mutable \emph{sources} of arbitrary types, and an HTML page is effectively a pure function over the latest values of the sources.  The page is not mutated directly, but rather it changes automatically as the sources are mutated.

$$\begin{array}{l}
  \mt{con} \; \mt{source} :: \mt{Type} \to \mt{Type} \\
  \mt{val} \; \mt{source} : \mt{t} ::: \mt{Type} \to \mt{t} \to \mt{transaction} \; (\mt{source} \; \mt{t}) \\
  \mt{val} \; \mt{set} : \mt{t} ::: \mt{Type} \to \mt{source} \; \mt{t} \to \mt{t} \to \mt{transaction} \; \mt{unit} \\
  \mt{val} \; \mt{get} : \mt{t} ::: \mt{Type} \to \mt{source} \; \mt{t} \to \mt{transaction} \; \mt{t}
\end{array}$$

Pure functions over sources are represented in a monad of \emph{signals}.

$$\begin{array}{l}
  \mt{con} \; \mt{signal} :: \mt{Type} \to \mt{Type} \\
  \mt{val} \; \mt{signal\_monad} : \mt{monad} \; \mt{signal} \\
  \mt{val} \; \mt{signal} : \mt{t} ::: \mt{Type} \to \mt{source} \; \mt{t} \to \mt{signal} \; \mt{t}
\end{array}$$

A reactive portion of an HTML page is injected with a $\mt{dyn}$ tag, which has a signal-valued attribute $\mt{Signal}$.

$$\begin{array}{l}
  \mt{val} \; \mt{dyn} : \mt{ctx} ::: \{\mt{Unit}\} \to \mt{use} ::: \{\mt{Type}\} \to \mt{bind} ::: \{\mt{Type}\} \to \mt{unit} \\
  \hspace{.1in} \to \mt{tag} \; [\mt{Signal} = \mt{signal} \; (\mt{xml} \; \mt{ctx} \; \mt{use} \; \mt{bind})] \; \mt{ctx} \; [] \; \mt{use} \; \mt{bind}
\end{array}$$

Transactions can be run on the client by including them in attributes like the $\mt{OnClick}$ attribute of $\mt{button}$, and GUI widgets like $\mt{ctextbox}$ have $\mt{Source}$ attributes that can be used to connect them to sources, so that their values can be read by code running because of, e.g., an $\mt{OnClick}$ event.

\section{Ur/Web Syntax Extensions}

Ur/Web features some syntactic shorthands for building values using the functions from the last section.  This section sketches the grammar of those extensions.  We write spans of syntax inside brackets to indicate that they are optional.

\subsection{SQL}

\subsubsection{Queries}

Queries $Q$ are added to the rules for expressions $e$.

$$\begin{array}{rrcll}
  \textrm{Queries} & Q &::=& (q \; [\mt{ORDER} \; \mt{BY} \; (E \; [o],)^+] \; [\mt{LIMIT} \; N] \; [\mt{OFFSET} \; N]) \\
  \textrm{Pre-queries} & q &::=& \mt{SELECT} \; P \; \mt{FROM} \; T,^+ \; [\mt{WHERE} \; E] \; [\mt{GROUP} \; \mt{BY} \; p,^+] \; [\mt{HAVING} \; E] \\
  &&& \mid q \; R \; q \\
  \textrm{Relational operators} & R &::=& \mt{UNION} \mid \mt{INTERSECT} \mid \mt{EXCEPT}
\end{array}$$

$$\begin{array}{rrcll}
  \textrm{Projections} & P &::=& \ast & \textrm{all columns} \\
  &&& p,^+ & \textrm{particular columns} \\
  \textrm{Pre-projections} & p &::=& t.f & \textrm{one column from a table} \\
  &&& t.\{\{c\}\} & \textrm{a record of columns from a table (of kind $\{\mt{Type}\}$)} \\
  \textrm{Table names} & t &::=& x & \textrm{constant table name (automatically capitalized)} \\
  &&& X & \textrm{constant table name} \\
  &&& \{\{c\}\} & \textrm{computed table name (of kind $\mt{Name}$)} \\
  \textrm{Column names} & f &::=& X & \textrm{constant column name} \\
  &&& \{c\} & \textrm{computed column name (of kind $\mt{Name}$)} \\
  \textrm{Tables} & T &::=& x & \textrm{table variable, named locally by its own capitalization} \\
  &&& x \; \mt{AS} \; t & \textrm{table variable, with local name} \\
  &&& \{\{e\}\} \; \mt{AS} \; t & \textrm{computed table expression, with local name} \\
  \textrm{SQL expressions} & E &::=& p & \textrm{column references} \\
  &&& X & \textrm{named expression references} \\
  &&& \{\{e\}\} & \textrm{injected native Ur expressions} \\
  &&& \{e\} & \textrm{computed expressions, probably using $\mt{sql\_exp}$ directly} \\
  &&& \mt{TRUE} \mid \mt{FALSE} & \textrm{boolean constants} \\
  &&& \ell & \textrm{primitive type literals} \\
  &&& \mt{NULL} & \textrm{null value (injection of $\mt{None}$)} \\
  &&& E \; \mt{IS} \; \mt{NULL} & \textrm{nullness test} \\
  &&& n & \textrm{nullary operators} \\
  &&& u \; E & \textrm{unary operators} \\
  &&& E \; b \; E & \textrm{binary operators} \\
  &&& \mt{COUNT}(\ast) & \textrm{count number of rows} \\
  &&& a(E) & \textrm{other aggregate function} \\
  &&& (E) & \textrm{explicit precedence} \\
  \textrm{Nullary operators} & n &::=& \mt{CURRENT\_TIMESTAMP} \\
  \textrm{Unary operators} & u &::=& \mt{NOT} \\
  \textrm{Binary operators} & b &::=& \mt{AND} \mid \mt{OR} \mid \neq \mid < \mid \leq \mid > \mid \geq \\
  \textrm{Aggregate functions} & a &::=& \mt{AVG} \mid \mt{SUM} \mid \mt{MIN} \mid \mt{MAX} \\
  \textrm{Directions} & o &::=& \mt{ASC} \mid \mt{DESC} \\
  \textrm{SQL integer} & N &::=& n \mid \{e\} \\
\end{array}$$

Additionally, an SQL expression may be inserted into normal Ur code with the syntax $(\mt{SQL} \; E)$ or $(\mt{WHERE} \; E)$.

\subsubsection{DML}

DML commands $D$ are added to the rules for expressions $e$.

$$\begin{array}{rrcll}
  \textrm{Commands} & D &::=& (\mt{INSERT} \; \mt{INTO} \; T^E \; (f,^+) \; \mt{VALUES} \; (E,^+)) \\
  &&& (\mt{UPDATE} \; T^E \; \mt{SET} \; (f = E,)^+ \; \mt{WHERE} \; E) \\
  &&& (\mt{DELETE} \; \mt{FROM} \; T^E \; \mt{WHERE} \; E) \\
  \textrm{Table expressions} & T^E &::=& x \mid \{\{e\}\}
\end{array}$$

Inside $\mt{UPDATE}$ and $\mt{DELETE}$ commands, lone variables $X$ are interpreted as references to columns of the implicit table $\mt{T}$, rather than to named expressions.

\subsection{XML}

XML fragments $L$ are added to the rules for expressions $e$.

$$\begin{array}{rrcll}
  \textrm{XML fragments} & L &::=& \texttt{<xml/>} \mid \texttt{<xml>}l^*\texttt{</xml>} \\
  \textrm{XML pieces} & l &::=& \textrm{text} & \textrm{cdata} \\
  &&& \texttt{<}g\texttt{/>} & \textrm{tag with no children} \\
  &&& \texttt{<}g\texttt{>}l^*\texttt{</}x\texttt{>} & \textrm{tag with children} \\
  &&& \{e\} & \textrm{computed XML fragment} \\
  &&& \{[e]\} & \textrm{injection of an Ur expression, via the $\mt{Top}.\mt{txt}$ function} \\
  \textrm{Tag} & g &::=& h \; (x = v)^* \\
  \textrm{Tag head} & h &::=& x & \textrm{tag name} \\
  &&& h\{c\} & \textrm{constructor parameter} \\
  \textrm{Attribute value} & v &::=& \ell & \textrm{literal value} \\
  &&& \{e\} & \textrm{computed value} \\
\end{array}$$


\section{The Structure of Web Applications}

A web application is built from a series of modules, with one module, the last one appearing in the \texttt{.urp} file, designated as the main module.  The signature of the main module determines the URL entry points to the application.  Such an entry point should have type $\mt{unit} \to \mt{transaction} \; \mt{page}$, where $\mt{page}$ is a type synonym for top-level HTML pages, defined in $\mt{Basis}$.  If such a function is at the top level of main module $M$, it will be accessible at URI \texttt{/M/f}, and so on for more deeply-nested functions, as described in Section \ref{tag} below.

When the standalone web server receives a request for a known page, it calls the function for that page, ``running'' the resulting transaction to produce the page to return to the client.  Pages link to other pages with the \texttt{link} attribute of the \texttt{a} HTML tag.  A link has type $\mt{transaction} \; \mt{page}$, and the semantics of a link are that this transaction should be run to compute the result page, when the link is followed.  Link targets are assigned URL names in the same way as top-level entry points.

HTML forms are handled in a similar way.  The $\mt{action}$ attribute of a $\mt{submit}$ form tag takes a value of type $\$\mt{use} \to \mt{transaction} \; \mt{page}$, where $\mt{use}$ is a kind-$\{\mt{Type}\}$ record of the form fields used by this action handler.  Action handlers are assigned URL patterns in the same way as above.

For both links and actions, direct arguments and local variables mentioned implicitly via closures are automatically included in serialized form in URLs, in the order in which they appear in the source code.

Ur/Web programs generally mix server- and client-side code in a fairly transparent way.  The one important restriction is that mixed client-server code must encapsulate all server-side pieces within named functions.  This is because execution of such pieces will be implemented by explicit calls to the remote web server, and it is useful to get the programmer's help in designing the interface to be used.  For example, this makes it easier to allow a client running an old version of an application to continue interacting with a server that has been upgraded to a new version, if the programmer took care to keep the interfaces of all of the old remote calls the same.  The functions implementing these services are assigned names in the same way as normal web entry points, by using module structure.


\section{Compiler Phases}

The Ur/Web compiler is unconventional in that it relies on a kind of \emph{heuristic compilation}.  Not all valid programs will compile successfully.  Informally, programs fail to compile when they are ``too higher order.''  Compiler phases do their best to eliminate different kinds of higher order-ness, but some programs just won't compile.  This is a trade-off for producing very efficient executables.  Compiled Ur/Web programs use native C representations and require no garbage collection.

In this section, we step through the main phases of compilation, noting what consequences each phase has for effective programming.

\subsection{Parse}

The compiler reads a \texttt{.urp} file, figures out which \texttt{.urs} and \texttt{.ur} files it references, and combines them all into what is conceptually a single sequence of declarations in the core language of Section \ref{core}.

\subsection{Elaborate}

This is where type inference takes place, translating programs into an explicit form with no more wildcards.  This phase is the most likely source of compiler error messages.

\subsection{Unnest}

Named local function definitions are moved to the top level, to avoid the need to generate closures.

\subsection{Corify}

Module system features are compiled away, through inlining of functor definitions at application sites.  Afterward, most abstraction boundaries are broken, facilitating optimization.

\subsection{Especialize}

Functions are specialized to particular argument patterns.  This is an important trick for avoiding the need to maintain any closures at runtime.

\subsection{Untangle}

Remove unnecessary mutual recursion, splitting recursive groups into strongly-connected components.

\subsection{Shake}

Remove all definitions not needed to run the page handlers that are visible in the signature of the last module listed in the \texttt{.urp} file.

\subsection{\label{tag}Tag}

Assign a URL name to each link and form action.  It is important that these links and actions are written as applications of named functions, because such names are used to generate URL patterns.  A URL pattern has a name built from the full module path of the named function, followed by the function name, with all pieces separated by slashes.  The path of a functor application is based on the name given to the result, rather than the path of the functor itself.

\subsection{Reduce}

Apply definitional equality rules to simplify the program as much as possible.  This effectively includes inlining of every non-recursive definition.

\subsection{Unpoly}

This phase specializes polymorphic functions to the specific arguments passed to them in the program.  If the program contains real polymorphic recursion, Unpoly will be insufficient to avoid later error messages about too much polymorphism.

\subsection{Specialize}

Replace uses of parameterized datatypes with versions specialized to specific parameters.  As for Unpoly, this phase will not be effective enough in the presence of polymorphic recursion or other fancy uses of impredicative polymorphism.

\subsection{Shake}

Here the compiler repeats the earlier Shake phase.

\subsection{Monoize}

Programs are translated to a new intermediate language without polymorphism or non-$\mt{Type}$ constructors.  Error messages may pop up here if earlier phases failed to remove such features.

This is the stage at which concrete names are generated for cookies, tables, and sequences.  They are named following the same convention as for links and actions, based on module path information saved from earlier stages.  Table and sequence names separate path elements with underscores instead of slashes, and they are prefixed by \texttt{uw\_}.
\subsection{MonoOpt}

Simple algebraic laws are applied to simplify the program, focusing especially on efficient imperative generation of HTML pages.

\subsection{MonoUntangle}

Unnecessary mutual recursion is broken up again.

\subsection{MonoReduce}

Equivalents of the definitional equality rules are applied to simplify programs, with inlining again playing a major role.

\subsection{MonoShake, MonoOpt}

Unneeded declarations are removed, and basic optimizations are repeated.

\subsection{Fuse}

The compiler tries to simplify calls to recursive functions whose results are immediately written as page output.  The write action is pushed inside the function definitions to avoid allocation of intermediate results.

\subsection{MonoUntangle, MonoShake}

Fuse often creates more opportunities to remove spurious mutual recursion.

\subsection{Pathcheck}

The compiler checks that no link or action name has been used more than once.

\subsection{Cjrize}

The program is translated to what is more or less a subset of C.  If any use of functions as data remains at this point, the compiler will complain.

\subsection{C Compilation and Linking}

The output of the last phase is pretty-printed as C source code and passed to GCC.


\end{document}