61 Commits (7bfdc49a7c627e30da67bc5f41f431a678e0cfeb)

Author	SHA1	Message	Date
Jonathan Arnett	fd348b11c3	Improve generated AST. Fixed a few "empty" bugs.	2021-12-17 02:41:40 +07:00
Jonathan Arnett	71c1660942	Differentiate concrete types from type constructors	2021-12-17 01:53:33 +07:00
Jonathan Arnett	62672649b0	Small formatting change	2021-12-17 01:36:43 +07:00
Jonathan Arnett	a77d3f5785	Add support for parsing function declarations	2021-12-14 23:35:37 +07:00
Jonathan Arnett	83bad86c24	Add support for public external functions and public external types	2021-12-14 01:46:23 +07:00
Jonathan Arnett	068ae5178f	Add support for external function statements	2021-12-14 01:35:59 +07:00
Jonathan Arnett	2f1624e1dd	Add ability to parse external types	2021-12-14 00:00:17 +07:00
Jonathan Arnett	3cb2569f12	OK, I swear I actually finished constants this time	2021-12-13 23:40:39 +07:00
Jonathan Arnett	25c5af2aa7	Better constant type parsing, still not my favorite ... Types for constants are more restricted than types for other parts of the language. The way that the Gleam parser handles this is by having the `parse_type` function pass along a `for_const` boolean, which is used to limit valid subnodes. I tried replicating this functionality in tree-sitter by creating a `parse_type($, for_const)` function, and calling that instead of `$.type`. tree-sitter did not like this, saying that the call stack became too deep. Thus, I arrived at my current solution, which is simply to have largely duplicate type rules for constants vs not-constants. Another possible approach would be to _generate_ the type rules via a `gen_types($, for_const)` function, which could be embedded into the rules list like so: ``` /* Special constant types */ ...gen_types($, true), // other stuff /* Types */ ...types($, false), ``` I may try that later.	2021-12-13 17:18:55 +07:00
Jonathan Arnett	8aecfc0617	Rudimentary constant support	2021-12-13 01:24:34 +07:00
Jonathan Arnett	7a820c581f	Initial commit	2021-12-12 04:53:43 +07:00