Logs: freenode/#haskell
| 2021-04-06 08:57:10 | × | cole-h quits (~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) (Client Quit) |
| 2021-04-06 08:58:32 | <xsperry> | minoru_shiraeesh agda and idris copmilers were written in haskell |
| 2021-04-06 08:58:58 | × | nut` quits (~user@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 240 seconds) |
| 2021-04-06 08:59:19 | <Franciman> | and that was a serious error |
| 2021-04-06 08:59:29 | → | frozenErebus joins (~frozenEre@37.231.244.249) |
| 2021-04-06 08:59:33 | <xsperry> | meh |
| 2021-04-06 08:59:43 | × | gtk quits (~user@roc37-h01-176-170-197-243.dsl.sta.abo.bbox.fr) (Ping timeout: 260 seconds) |
| 2021-04-06 08:59:45 | → | CaptainIRS joins (9d339880@157.51.152.128) |
| 2021-04-06 08:59:50 | <enikar> | since version 1.5 the go compiler is written in go. |
| 2021-04-06 09:00:41 | <minoru_shiraeesh> | from the rust page in wikipedia: The same year, work shifted from the initial compiler (written in OCaml) to the LLVM-based self-hosting compiler written in Rust. |
| 2021-04-06 09:01:24 | → | sedeki joins (~textual@unaffiliated/sedeki) |
| 2021-04-06 09:01:25 | <merijn> | minoru_shiraeesh: Elm and PureScript are written in Haskell, Ocaml is presumably written in Ocaml |
| 2021-04-06 09:01:25 | → | __monty__ joins (~toonn@unaffiliated/toonn) |
| 2021-04-06 09:01:29 | <Uniaika> | minoru_shiraeesh: NodeJS is indeed made in C++ if I'm not mistaken |
| 2021-04-06 09:02:05 | <merijn> | minoru_shiraeesh: The main reason compiler components tend to be written in C is that C is the only language with a standardised ABI |
| 2021-04-06 09:02:23 | → | molehillish joins (~molehilli@2600:8800:8d06:1800:b54a:36bf:7632:87f4) |
| 2021-04-06 09:02:25 | <merijn> | And once you write some component temporarily in C and it works, why bother rewriting it |
| 2021-04-06 09:03:04 | <minoru_shiraeesh> | what do they need llvm for? maybe it simplifies the work |
| 2021-04-06 09:03:30 | <minoru_shiraeesh> | can you create a compiler with java script and llvm? |
| 2021-04-06 09:03:38 | <minoru_shiraeesh> | or python and llvm |
| 2021-04-06 09:03:38 | <merijn> | Same reason with people complaining "Why is GHCs RTS written in C?!" to which the obvious is "Because the first version was and by now we have a 3 decades old, high-performance, battle-tested RTS...why would you spend a year rewriting it from scratch if the only reason is "to make it not C"?" |
| 2021-04-06 09:03:53 | → | mettekou joins (~mettekou@d8D875214.access.telenet.be) |
| 2021-04-06 09:03:55 | → | viluon joins (uid453725@gateway/web/irccloud.com/x-vxyigueamtfqricd) |
| 2021-04-06 09:04:01 | <mettekou> | Any advice on storing recursive algebraic data types in a relational database? |
| 2021-04-06 09:04:10 | <merijn> | minoru_shiraeesh: LLVM == the low-level virtual machine, it's a framework for generating and optimising assembly in a platform independent way |
| 2021-04-06 09:04:19 | <merijn> | mettekou: "do it manually" |
| 2021-04-06 09:04:49 | × | Unhammer quits (~Unhammer@gateway/tor-sasl/unhammer) (Remote host closed the connection) |
| 2021-04-06 09:05:03 | <mettekou> | merijn: I am doing it manually, but you have a lot of options: adjacency lists, nested sets... |
| 2021-04-06 09:05:22 | → | Unhammer joins (~Unhammer@gateway/tor-sasl/unhammer) |
| 2021-04-06 09:05:32 | <mettekou> | I was wondering whether there's a canonical way. |
| 2021-04-06 09:05:43 | <merijn> | mettekou: tbh, I would forget about ADTs when defining a database schema |
| 2021-04-06 09:06:27 | <merijn> | mettekou: In the sense of: Define a schema for the data you have (and maybe the operation you'll need) and then figure out how to map between that and ADTs |
| 2021-04-06 09:06:39 | <mettekou> | merijn: I don't know, the sum and product types map quite well, if you use the same approach you would use for classes in a class hierarchy in an object-oriented programming language. |
| 2021-04-06 09:06:47 | <merijn> | replicating ADTs in your database sounds way to tightly coupled |
| 2021-04-06 09:07:02 | <mettekou> | merijn: I'm actually trying to store ASTs and program executions for some really minimal DSL. |
| 2021-04-06 09:07:12 | × | vicfred quits (vicfred@gateway/vpn/mullvad/vicfred) (Quit: Leaving) |
| 2021-04-06 09:08:08 | → | kuribas joins (~user@ptr-25vy0i98ky9sotgacau.18120a2.ip6.access.telenet.be) |
| 2021-04-06 09:08:09 | <merijn> | That sounds...odd? But I'd probably have something like 1 table for the AST itself and 1 table for each type of node, the AST table just referencing those |
| 2021-04-06 09:08:33 | <aldum> | tables are a product type of sorts ;) |
| 2021-04-06 09:08:45 | <merijn> | So, like, a table of binary operators has an id, operator and 2 references back into the AST table |
| 2021-04-06 09:08:52 | <sedeki> | mettekou i'm here as well (not only in the postgres channel). |
| 2021-04-06 09:09:09 | <mettekou> | merijn: That's the adjacency list approach, which is what I would do as well. |
| 2021-04-06 09:09:23 | <mettekou> | With a recursive CTE, it's easy to query. |
| 2021-04-06 09:09:28 | <merijn> | Morbidly curious why you wanna store an AST into a database, though :> |
| 2021-04-06 09:09:35 | → | michalz joins (~user@185.246.204.46) |
| 2021-04-06 09:10:06 | → | stree joins (~stree@68.36.8.116) |
| 2021-04-06 09:10:37 | <mettekou> | merijn: I'm modelling industrial processes using a DSL which is based on Gilbreth-style flow process charts. |
| 2021-04-06 09:11:36 | <mettekou> | merijn: Industrial engineers do not like text-based languages, so I'm building a flow process chart editor which also makes these charts executable programs in the DSL. |
| 2021-04-06 09:12:04 | × | royal_screwup21 quits (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed) |
| 2021-04-06 09:12:22 | → | royal_screwup21 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2021-04-06 09:13:14 | <Maxdamantus> | If you were creating a text-based language, would you still be trying to store the AST in the database? |
| 2021-04-06 09:13:41 | <Maxdamantus> | ("in the database" presumably means something other than "as a single blob of data"( |
| 2021-04-06 09:13:44 | <Maxdamantus> | )) |
| 2021-04-06 09:14:14 | <mettekou> | Maxdamantus: Yes, because I want to link executions of the process steps to the process steps. |
| 2021-04-06 09:14:40 | <mettekou> | The alternative is indeed JSON/XML/BLOB or files, which is just moving the linking problem to the application code. |
| 2021-04-06 09:15:48 | <mettekou> | Not smart, in my opinion, since an important advantage of using a relational database is delegating referential integrity to it. |
| 2021-04-06 09:15:54 | <merijn> | mettekou: Oooh |
| 2021-04-06 09:16:10 | <Maxdamantus> | I find it hard to imagine that it would be simpler to maintain these things in a relational database, otherwise people would be generally using relational database when writing compilers. |
| 2021-04-06 09:16:28 | <merijn> | mettekou: "Other people who liked process flowcharts and Haskell also liked: Clean" ;) |
| 2021-04-06 09:16:30 | <mettekou> | Maxdamntus: I don't think so, they don't require persistence. |
| 2021-04-06 09:16:56 | <merijn> | mettekou: You should lookup itasks |
| 2021-04-06 09:17:00 | <Maxdamantus> | mettekou: the source files persist. |
| 2021-04-06 09:17:25 | <merijn> | mettekou: https://clean.cs.ru.nl/ITasks |
| 2021-04-06 09:17:36 | <mettekou> | merijn: I'm doing it in F#, but it's a general functional programming problem, so I asked about it here, since there's more activity here. :P |
| 2021-04-06 09:17:56 | <Maxdamantus> | mettekou: you're presumably treating contents of the database as source code, rather than the contents of a text/JSON/binary string/file. |
| 2021-04-06 09:18:10 | → | Aquazi joins (uid312403@gateway/web/irccloud.com/x-bmhbjzvaxfjgfshr) |
| 2021-04-06 09:18:11 | → | cafce25 joins (~cafce25@ipbcc3009d.dynamic.kabel-deutschland.de) |
| 2021-04-06 09:18:25 | <merijn> | mettekou: Well, they literally have a pre-built DSL generating GUIs etc for exactly the kinda stuff you're talking about ;) |
| 2021-04-06 09:18:47 | <merijn> | mettekou: So if your adventurous it could save you weeks/months of work :p |
| 2021-04-06 09:19:04 | <Maxdamantus> | Having worked on something similar, I imagine you would run into issues at some point regarding versioning of the code, including merging. |
| 2021-04-06 09:19:58 | <Maxdamantus> | When people work on the code, they'll probably think in terms of a particular snapshot and make changes to that, then at some point those changes will be merged into the master copy. |
| 2021-04-06 09:20:37 | <mettekou> | Maxdamantus: They define the process once and only revise details, kind of important for production lines. |
| 2021-04-06 09:21:00 | <mettekou> | A single edit after the production line runs already makes them nervous. |
| 2021-04-06 09:21:09 | <Maxdamantus> | and at various stages, you have different "versions" of this code. That will be a bit tricky I think to represent in a RDBMS. Probably a lot simpler to just keep each version of the code in a big string (or JSON/XML structure, whatever) |
| 2021-04-06 09:22:24 | <Maxdamantus> | Right, I would also be nervous using a system built like that. |
| 2021-04-06 09:24:08 | × | royal_screwup21 quits (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Quit: Connection closed) |
| 2021-04-06 09:24:27 | → | royal_screwup21 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2021-04-06 09:24:33 | → | coni joins (d4338494@212-51-132-148.fiber7.init7.net) |
| 2021-04-06 09:24:35 | <Maxdamantus> | another reason that the single-version blob approach is useful is that you know that a single version of the entire code is represented by just a string, which in the worst case could be understood by someone technical enough, but you just have to optimise the way you view that string by producing appropriate tooling, so tools that just render that string as a graph, etc. |
| 2021-04-06 09:25:28 | × | noCheese quits (~nocheese@unaffiliated/nocheese) (Quit: I'm out!) |
| 2021-04-06 09:25:29 | <Maxdamantus> | RDBMSes are potentially useful when it doesn't make sense to look at the entire dataset as a unit. |
| 2021-04-06 09:25:51 | → | noCheese joins (~nocheese@gw2.aibor.de) |
| 2021-04-06 09:25:51 | × | noCheese quits (~nocheese@gw2.aibor.de) (Changing host) |
| 2021-04-06 09:25:51 | → | noCheese joins (~nocheese@unaffiliated/nocheese) |
| 2021-04-06 09:27:16 | <mettekou> | Maxdamantus: "Right, I would also be nervous using a system built like that." - What's that supposed to mean? |
| 2021-04-06 09:27:56 | → | fendor joins (~fendor@91.141.0.13.wireless.dyn.drei.com) |
| 2021-04-06 09:28:00 | → | Ranhir joins (~Ranhir@157.97.53.139) |
| 2021-04-06 09:28:58 | × | royal_screwup21 quits (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Ping timeout: 240 seconds) |
| 2021-04-06 09:29:30 | × | bahamas quits (~lucian@unaffiliated/bahamas) (Ping timeout: 268 seconds) |
| 2021-04-06 09:33:33 | <Maxdamantus> | mettekou: I find it hard to trust systems that don't have some clear representation of the overall code. |
| 2021-04-06 09:34:11 | <Maxdamantus> | mettekou: for a typical text-based programming language, that can simply be the text that makes up each source file. |
| 2021-04-06 09:34:50 | <Maxdamantus> | mettekou: but even for a graphical programming system, there should be something analogous. Something that can at least be serialised into such a source file. |
| 2021-04-06 09:35:11 | × | molehillish quits (~molehilli@2600:8800:8d06:1800:b54a:36bf:7632:87f4) (Ping timeout: 260 seconds) |
| 2021-04-06 09:35:41 | <Maxdamantus> | So someone can capture the state of the system into a file, and any other representation can be seen as derived from the contents of that file. |
| 2021-04-06 09:36:11 | → | dhouthoo joins (~dhouthoo@ptr-eitgbj2w0uu6delkbrh.18120a2.ip6.access.telenet.be) |
| 2021-04-06 09:36:24 | <mettekou> | Maxdamantus: I don't see why a relational database is not trustworthy in that respect, and flat files are. |
| 2021-04-06 09:37:56 | <mettekou> | mettekou: I'd hate to do reporting queries over flat files, by the way. Even with PostgreSQL's excellent JSON support, for example, I would still hate to do reporting queries over JSON. |
| 2021-04-06 09:38:52 | <mettekou> | I just realized that that's why I want a relational database and compiler writers don't: I need to store executions and do reporting based on them. |
| 2021-04-06 09:40:18 | <Maxdamantus> | Well, your original question was about representing ASTs in relational databases. Unless the approach is to just store the entire tree in a string (which is what I would advocate), you're going to be creating some representation that is harder to use than regular AST structures you would create in memory. |
| 2021-04-06 09:40:54 | <Maxdamantus> | since the way you normally represent ASTs is as some sort of recursive structure, which doesn't inherently work in an RDBMS. |
All times are in UTC.