Morel: A Functional Language for Data | Hacker News Reader

Morel: A Functional Language for Data

blog.hydromatic.net

78 pointsngaut11 comments

The language reminds me of xquery:

Morel:

    from e in hr.emps,
        d in depts
    where e.deptno = d.deptno
    yield {e.id, e.deptno, ename = e.name, dname = d.name};

Xquery:

    for $act in doc("hamlet.xml")//ACT
        let $speakers := distinct-values($act//SPEAKER)
    return
      <div><h1>{ string($act/TITLE) }</h1></div>

and other LINQ like languages:

    var results =  from c in SomeCollection
               where c.SomeProperty < 10
               select new {c.SomeProperty, c.OtherProperty};

or JSONiq:

    for $p in collection("persons")
    where $p.age gt 20
    let $home := $p.phoneNumber[][$$.type eq "home"].number
    group by $area := substring-before($home, " ")
    return {"area code" : $area, "count" : count($p)}

Nice that this is using SML as a core and doesn't totally re-invent the wheel. I appreciate the language name, too.

This is just the core language, right? So I could query native datasets, but there's no connection to either an existing database nor a specific persistent storage engine, right?

    SQL is not Turing complete (if you ignore the WITH RECURSIVE construct), [...]

    Morel, on the other hand, crosses that line. This is necessary, because all functional languages are Turing complete, [...]

According to Wikipedia, there is a paradign of total functional programming (https://en.wikipedia.org/wiki/Total_functional_programming), as described by D.A. Turner (https://www.cs.kent.ac.uk/people/staff/dat/esfp/fple.pdf) which restricts programs to be non-Turing complete. Wikipedia gives two examples of languages following it: Epigram and Charity.

TL;DR it's possible if you limit the recursive functions to only act on _reduced_ form of input (e.g. strict subset of a set) and if every function is total (produce output for every input).

Cool project BTW.

FWIW, SQL is actually the runner-up for Relational DBs. Codd had something he called Alpha:

> The Alpha language was the original database language proposed by Edgar F. Codd, the inventor of the relational database approach. It was defined in Codd's 1971 paper "A Data Base Sublanguage Founded on the Relational Calculus".

https://en.wikipedia.org/wiki/Alpha_(programming_language)

Also see Datalog and Prolog. https://en.wikipedia.org/wiki/Datalog https://en.wikipedia.org/wiki/Prolog

Everything is RMDB

I advocate: Building a relational data model on top of hash-map to achieve a combination of NoSQL and RMDB advantages. This is actually a reverse implementation of PostgreSQL.

[Clojure is a functional programming language based on relational database theory](https://github.com/linpengcheng/PurefunctionPipelineDataflow...)

[Everything is RMDB](https://github.com/linpengcheng/PurefunctionPipelineDataflow...)

[Implement relational data model and programming based on hash-map (NoSQL)](https://github.com/linpengcheng/PurefunctionPipelineDataflow...)

From foo where bar yield baz; is always how I think about SQL and wish I could write it

I'm still surprised that there's no common ratfor/coffeescript/SCSS for SQL.

I've thought about that before, too. One of the issues with a light syntax helper atop SQL is that SQL is often used as snippets in other languages or with SQL tools, etc. It seems hard to shim a layer in there.

However, I think what would make a ton of sense is a coffeescript-esque PL/pgSQL, complete with runtime. Basically an easier to use psql shell (or equivalent for another DB). Postgres is incredibly powerful, and I feel like could be a much more useful interactive tool for loading up CSVs, doing some querying, modifying, etc, with a little friendlier or more programmer-familiar environment.

It would get complicated in code if you're constructing your statement from bits and pieces, as the preprocessor would have no way of forming a complete syntax tree out of it, of course.

I'm picturing something closer to "emmet"[1], where you write some shorthand and this gets expanded to proper SQL in line. So our imaginary sql-script would never see the light of git, most of the time you'd use it through an IDE plugin or vim's "!" filter (although you could have it available as a function at runtime and actually save the simplified code). Actual database access at this stage would be good, I wouldn't mind e.g. globbing column names or excluding some ("sel *-[{created,updated}_at]")...

But you're right, for something like psql this would make good sense, too. And after you've played arond with it, you can paste the proper SQL wherever you needed it, too.

[1]: https://docs.emmet.io/

There are s-expression syntaxes in various lisps. True hard problem is designing an alternate syntax that still gives you access to all the features of your database.

This is really amazing! Want to make sure I have a comment on the original post when this is huge!

Reply on news.ycombinator.com