AgentM

Indeed, I think we are in complete agreement. Haskell makes refactoring relatively safe and I don't expect the user-exposed APIs to change whatsoever until we are ready to introduce a...

I can see how that would be annoying indeed. Thus far, I've been avoiding implementing typeclass support at the Atom level, but it might be required. It doesn't make sense...

The data type construction is broken even if we eliminate the type variable: ``` TutorialD (master/main): data Rose = Node Text (List Rose) TutorialD (master/main): :showexpr relation{rose Rose}{tuple{rose Node "a"...

Ugh, type constructors are parsed completely incorrectly right now- "Rose Text (List Text)" is parsed as "Rose (Text (List Text))" which is obviously wrong.

I fixed the parsing bug but there's still a naive bug involving type name variables. A quick workaround is to avoid the "a" type variable. ``` TutorialD (master/main): data Rose...

Oops. Thanks for catching that. That type was actually accepted but it was not possible to create values for it. This is fixed with new validation in d97145408be8c7c5286ab79f7ac5b3f350abb994.

Another rather obvious optimization would be to detect if an inclusion dependency operates independently on tuples (no aggregate functions or cross-relvar references) and, if so, run the constraint checker against...

C.J. Date in "Database In Depth" around page 126 discusses his multiple assignment operator (the comma) and how is differs from deferred execution, allowing various whole statement optimizations to still...

Indeed, the current constraint optimizer uses such information to determine which constraint checks can be skipped (if the update expression mentions relvar x and the constraint does not, then the...

Ultimately, deferred constraints and the comma operator serve the same purpose. The advantage of the comma operator is that it doesn't actually defer constraint-checking. Date explains: ``` s:= ..., p:=...;...