Loading ...
Sorry, an error occurred while loading the content.

Re: [extremeperl] HaskellDB, static typing, combinators, and ObPerl

Expand Messages
  • Rob Nagler
    ... Here s our language for defining SQL queries in Perl for our domain: { version = 1, can_iterate = 1, # List of fields which uniquely identify each row in
    Message 1 of 3 , Mar 29, 2005
    • 0 Attachment
      Shae Matijs Erisson writes:
      > Database theory is (pretty much) the same as set theory.
      > One pattern in Haskell is to make a 'domain specific language.'
      > In the case of HaskellDB, this is used to do set theory operations directly in
      > the Haskell language. So I wrote that "HaskellDB is a database UNwrapper for
      > Haskell" because the database stuff happens directly in Haskell, and is then
      > mapped to SQL, or whatever relational language. (Yes, I wrote that tutorial.)

      Here's our language for defining SQL queries in Perl for our domain:

      {
      version => 1,
      can_iterate => 1,

      # List of fields which uniquely identify each row in this list
      primary_key => [
      ['Product.product_id'],
      ],

      # Allow sorting by name and product_id
      order_by => [
      'Product.name',
      'Product.product_id',
      # For example, to add a column, uncomment this line
      # 'Product.description',
      ],

      # Narrows query to just this category_id; selectable by ListQuery
      parent_id => ['Product.category_id'],
      };

      > I think the same thing could be done in Perl by making a bunch of infix
      > functions that expect other infix functions that only work with set theory
      > operations. You'd end up with code that generates only legal SQL or errors.

      We came about this definitional model through refactoring to match our
      problem domain (paged and non-paged lists).

      We don't end up with legal SQL, because the definition of what is
      legal depends on the run-time binding to the database vendor we are
      using. That's on reason why we defer errors to the SQL interpreter
      and avoid parsing any SQL in our library. (Our model allows you to
      inject SQL directly at different points in the processing.)

      > A type system is simplified automated proof checking software. One example of a
      > cool useful type trick is Simon Peyton-Jones' financial contracts combinators:
      > http://research.microsoft.com/Users/simonpj/Papers/financial-contracts/contracts-icfp.htm
      > This sort of application is valuable to the customer, to the point that a
      > company was started based on this idea alone: http://www.lexifi.com/

      This seems like a cool paper. Thanks for pointing it out.

      Rob
    • Shae Matijs Erisson
      ... HaskellDB allows higher-order database queries, and I don t think this does. I used to work with multi-page SQL queries in some trust
      Message 2 of 3 , Mar 31, 2005
      • 0 Attachment
        Rob Nagler <nagler@...> writes:

        > Here's our language for defining SQL queries in Perl for our domain:
        >
        > {
        > version => 1,
        > can_iterate => 1,

        <snip code>

        HaskellDB allows higher-order database queries, and I don't think this does.
        I used to work with multi-page SQL queries in some trust management code.
        We always wished for some way to pass one bit of SQL as the parameter to
        another bit of SQL. HaskellDB allows that ( see test/higher-order.hs )
        and checks that the resulting relational query is somewhat sane.
        One advantage of combinators is that they can be composed with each other.

        > We don't end up with legal SQL, because the definition of what is
        > legal depends on the run-time binding to the database vendor we are
        > using. That's on reason why we defer errors to the SQL interpreter
        > and avoid parsing any SQL in our library. (Our model allows you to
        > inject SQL directly at different points in the processing.)

        SQL is still one step away from relational operations.
        You could directly output the relational operations you're producing and turn
        that into SQL for each backend, and you'd be able to do some sanity checks in
        the process.
        --
        Programming is the Magic Executable Fridge Poetry, | www.ScannedInAvian.com
        It is machines made of thought, fueled by ideas. | -- Shae Matijs Erisson
      Your message has been successfully submitted and would be delivered to recipients shortly.