3 ms·

For anyone interested in how it looks like: http://impredicative.com/ur/todomvc/todomvc_db.ur.html http://impredicative.com/ur/todomvc/todomvc_db.ur.html It se

For anyone interested in how it looks like: http://impredicative.com/ur/todomvc/todomvc_db.ur.html http://impredicative.com/ur/todomvc/todomvc_db.ur.html It seems DELETE FROM requires WHERE... Good idea :)

catnaroek 9y ago
Far more important IMO are the following features: (0) The type checker ensures that database and application types are synchronized. It's literally impossible to query inexistent tables, inexistent fields, or assume they have a type that they in fact don't have. (1) Tables can be private to a module, just like everything else in an ML dialect. This allows you to establish “table invariants” that other modules cannot possibly break. If this still sounds too abstract, here's a concrete benefit: You can dernormalize private tables, without risking other modules putting them in an inconsistent state. If I ever go back to programming ERP systems, I would love to do it in Ur/Web.
- Shoothe 9y ago
  Do you mean the type checker that runs during compiling connects to the database? Seems interesting but on most of my projects there were several environments so it wouldn't solve all problems. A similar, but simpler solution for other languages would be to generate types from the database schema before compiling. Do you have a sample code of these table invariants at hand? I'd gladly take a look...
  - catnaroek 9y ago
    > Do you mean the type checker that runs during compiling connects to the database? Okay, it doesn't go that far. But the compiler produces the table creation scripts. So, if your build process includes running said scripts, then database and application types are guaranteed to be synchronized. > Do you have a sample code of these table invariants at hand? I'd gladly take a look... Imagine a general ledger that's guaranteed to never go out of balance, no matter what third party modules do that interact with the accounting subsystem, because the only module that can directly manipulate accounting tables is the accounting subsystem. Guaranteed by the type checker. I haven't implemented such a thing in Ur/Web, because implementing accounting systems from scratch is a frigging lot of work, most of it utterly boring, and nobody has paid me to do it. But it's feasible, and the ML module system is the reason why.

catnaroek 9y ago

Far more important IMO are the following features: (0) The type checker ensures that database and application types are synchronized. It's literally impossible to query inexistent tables, inexistent fields, or assume they have a type that they in fact don't have. (1) Tables can be private to a module, just like everything else in an ML dialect. This allows you to establish “table invariants” that other modules cannot possibly break. If this still sounds too abstract, here's a concrete benefit: You can dernormalize private tables, without risking other modules putting them in an inconsistent state. If I ever go back to programming ERP systems, I would love to do it in Ur/Web.

Shoothe 9y ago
Do you mean the type checker that runs during compiling connects to the database? Seems interesting but on most of my projects there were several environments so it wouldn't solve all problems. A similar, but simpler solution for other languages would be to generate types from the database schema before compiling. Do you have a sample code of these table invariants at hand? I'd gladly take a look...
- catnaroek 9y ago
  > Do you mean the type checker that runs during compiling connects to the database? Okay, it doesn't go that far. But the compiler produces the table creation scripts. So, if your build process includes running said scripts, then database and application types are guaranteed to be synchronized. > Do you have a sample code of these table invariants at hand? I'd gladly take a look... Imagine a general ledger that's guaranteed to never go out of balance, no matter what third party modules do that interact with the accounting subsystem, because the only module that can directly manipulate accounting tables is the accounting subsystem. Guaranteed by the type checker. I haven't implemented such a thing in Ur/Web, because implementing accounting systems from scratch is a frigging lot of work, most of it utterly boring, and nobody has paid me to do it. But it's feasible, and the ML module system is the reason why.