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

HaskellDB, static typing, combinators, and ObPerl

Expand Messages
  • Shae Matijs Erisson
    ... My opinion is that the Haskell way is better. And the Perl way is better. I think the best choice for any given goal depends on the timeframe, the
    Message 1 of 3 , Mar 29 1:40 PM
    • 0 Attachment
      --- In extremeperl@yahoogroups.com, Rob Nagler <nagler@b...> wrote:

      > I always thought that was the customer's job. ;-) Seriously, is there
      > any evidence that forcing programs to decompose problems the Haskell
      > way is any better than the Perl way?

      My opinion is that the Haskell way is better. And the Perl way is better.
      I think the best choice for any given goal depends on the timeframe, the
      customer, and more. Some times the best choice is to use them all!
      ( for example - http://c2.com/cgi/wiki?AlternateHardAndSoftLayers )

      > http://www.haskell.org/hawiki/HaskellDbTutorial
      > Do you have experience with this? Is it better to program this way
      > than with good old SQL?

      Database theory is (pretty much) the same as set theory.
      ( see http://en.wikipedia.org/wiki/Database_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.)

      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.
      (Those sorts of functions are called combinators, for more detail see
      http://en.wikipedia.org/wiki/Combinator )

      > I haven't found the lack of type safety in Perl to be hindrance in
      > performance or quality so I'd like to see some evidence that programming in a
      > type safe language is any better for the customer. Are there any studies out
      > there that compare programming Perl vs Haskell to do the same job?

      In my opinion, static type safety is just one tool in the toolbox.
      In Haskell you're not forced to see the type system all the time like you are
      in Java. I jokingly refer to Haskell as 'compile-time dynamic typing'.
      You can use Dynamics in Haskell to escape the type system entirely, or you can
      use the HaXml approach where everything is a typesafe algebraic datatype.

      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/
      --
      Programming is the Magic Executable Fridge Poetry, | www.ScannedInAvian.com
      It is machines made of thought, fueled by ideas. | -- Shae Matijs Erisson
    • 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 2 of 3 , Mar 29 5:25 PM
      • 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 3 of 3 , Mar 31 3:44 AM
        • 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.