Details on QL
Apr. 19th, 2016 06:32 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jducoeurFor the who are paying a little attention to Querki (but not following ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-community.gif)
querki_project): the first major phase of the QL language is finally finished. A little while ago, I introduced bound values, and last week I was finally driven to add local function definitions. That brings us to the point where I've implemented all of the read-time functions that are in the plans. There will likely be some enhancements as we go, to support transforming and storing data as it gets saved to the database, but the main spine of the language is in place.
It's been an interesting experience, deriving the simplest language I could come up with that suffices for this purpose. It's certainly more complex than it once was, but still -- the reasonably full language definition fits in a handful of screens. It's not *quite* as simple as Scheme, but it's well up there.
The end result is a bit surprising, with a couple of aspects that emerged organically as I developed. One is the fact that it's a very pure functional language: that wasn't an original design goal, but after a while, it became clear that there was no good reason *not* to go for pure-functional, and all the usual arguments in favor apply here. The other is the incredibly strange way Querki handles function parameters, behaving more like macros than conventional functions. I keep feeling like this *surely* must be wrong, since no other language I know works this way, but it's clearly optimal for the way Querki thinks about data.
(An open question is whether QL should be considered a DSL. It kind of is, in somewhat the same way that SQL is: the domain is "data transformation". I have trouble considering that a "domain", but there you go.)
Anyway, I've written up a first-draft guide to the language, which can be found here. I'm unlikely to change any major aspects of the language at this point -- this syntax was evolved through a lot of careful thought about how one works in Querki -- but questions and comments would be quite welcome...
querki_project): the first major phase of the QL language is finally finished. A little while ago, I introduced bound values, and last week I was finally driven to add local function definitions. That brings us to the point where I've implemented all of the read-time functions that are in the plans. There will likely be some enhancements as we go, to support transforming and storing data as it gets saved to the database, but the main spine of the language is in place.It's been an interesting experience, deriving the simplest language I could come up with that suffices for this purpose. It's certainly more complex than it once was, but still -- the reasonably full language definition fits in a handful of screens. It's not *quite* as simple as Scheme, but it's well up there.
The end result is a bit surprising, with a couple of aspects that emerged organically as I developed. One is the fact that it's a very pure functional language: that wasn't an original design goal, but after a while, it became clear that there was no good reason *not* to go for pure-functional, and all the usual arguments in favor apply here. The other is the incredibly strange way Querki handles function parameters, behaving more like macros than conventional functions. I keep feeling like this *surely* must be wrong, since no other language I know works this way, but it's clearly optimal for the way Querki thinks about data.
(An open question is whether QL should be considered a DSL. It kind of is, in somewhat the same way that SQL is: the domain is "data transformation". I have trouble considering that a "domain", but there you go.)
Anyway, I've written up a first-draft guide to the language, which can be found here. I'm unlikely to change any major aspects of the language at this point -- this syntax was evolved through a lot of careful thought about how one works in Querki -- but questions and comments would be quite welcome...