The declaration file isn't used to typecheck the code the declaration is for. It is only for consumers of the code.

Would be nice to add a seamless ability to call executable UDFs from clickhouse-local, last time I checked clickhouse-local required executables to be in a special directory (as in proper clickhouse). Instead it'd be nice to be able to reference any executable in an ad-hoc way.

Also check out BQNPAD[1], the online BQN REPL built with codemirror (syntax highlighting, history).

[1]: https://bqnpad.mechanize.systems

The nice thing is that the whole notebook is a single CodeMirror editor with cells stored as ranges in CodeMirror state. This way intercell actions like selection/copy/paste are possible and still you can control execution per cell.

Shortcuts at https://bqnpad.mechanize.systems/notebook

* Shift+Enter to eval cell

* Cmd-Enter to create new cell

* Cmd-Option-Enter to split cell at cursor

* Cmd-Backspace to join cell with the previous one

[1]: https://mlochbaum.github.io/BQN/index.html

After the recent AoC which I've attempted to solve with BQN[1] (another array language) I've got interested in array languages and now exploring K too.

K seems like a nice blend between an array language and a lisp: list is a primary data structure in K, no multidimensional data. K is good at symbolic workloads as well — visit http://nsl.com for some examples.

Also, make sure to check out the C code style ngn/k is written with :-) another K implementation Kona (uses similar C code style) has a wiki page with explanation[2].

[1]: https://mlochbaum.github.io/BQN/index.html [2]: https://github.com/kevinlawler/kona/wiki/Coding-Guidelines

Have you considered any other implementation strategies (C native extension, any other pl/* or maybe running an out of PostgreSQL process which does GraphQL to SQL compilation)?

I'd say the main problem is that local switches and lock files are still not the default mode of operation.

Also opam lacks a global cache of built packages which esy provides (esy's cache is modelled after Nix package manager). So every new opam local switch effectively compiles everything from scratch. Though, as I understand this aspect is going to be addressed by dune at some point (though esy caches not just OCaml built artefacts but also C/C++).

(Full disclosure: I'm biased as I'm one of the original developers of esy)

The library presents an API of combinators for query construction but it's totally possible to build a concrete syntax around it (in fact I did it for my port in OCaml). But syntax isn't really this important (it is of course) but the compositional semantics FunSQL.jl provides:

1. Query combinators can be composed together in any order (if they are "compatible") unlike SQL where structure SELECT .. FROM .. WHERE .. is rigid:

    from users
    where is_active
    select username

2. The way FunSQL.jl treats `group by` as just another kind of namespace, aggregates are then specified as just expressions under this namespace:

    from users as u
    join (from comments group by user_id) as c on c.user_id = u.id
    select
      u.username,
      c.count() as comment_count,
      c.max(created_date) as comment_last_created_date

This is a really useful feature, from my point of view, as it's allows you to construct re-usable query fragments first and then combine them to build complete quries.

3. In other aspects FunSQL.jl is really close to SQL which I think is a big plus as well — familiriaty.

Comments URL: https://news.ycombinator.com/item?id=30072608

Points: 25

# Comments: 1

I have re-implemented parts of FunSQL in Python and OCaml (the one I have ended up using) and have added a concrete syntax similar to what you have in PRQL.

    from employees
    define
      salary + payroll_tax as gross_salary,
      gross_salary + benefits_cost as gross_cost
    where gross_cost > 0 and country = 'usa'
    group by title, country
    select
      title,
      country,
      avg(salary) as average_salary,
      sum(salary) as sum_salary,
      avg(gross_salary) as average_gross_salary,
      sum(gross_salary) as sum_gross_salary,
      avg(gross_cost) as average_gross_cost,
      sum(gross_cost) as sum_gross_cost,
      count() as count
    order by sum_gross_cost
    where count > 200
    limit 20

    from users as u
    join (from comments group by user_id) as c on c.user_id = u.id
    select
      u.username,
      c.count() as comment_count,
      c.max(created_date) as comment_last_created_date

I think this approach is very powerful as it allows you to build reusable query fragments in isolation but then combine them into a single query which fully specifies what's being selected.