Glide VS interjevko.js

I've added the code to the repo: https://github.com/dibsonthis/Glide/blob/main/imports/csv.gl

So for the past few months, I've been working on my data transformation language Glide. It started off as a simple toy PL that aimed to do some basic data transformation through piping. But as time went on, more and more features were added and the implementation became more complex.

I'm about 70% through writing Glide's new type system. Here are some examples:

Hey all, I'd like to hear your opinions on Glide's list comprehension syntax:

I was hesitant to spend time building a proper type system originally, but I'm so glad I decided to do it. Having a typing stage in the pipeline has made my language (Glide) feel so much closer to a real language than the toy language I've always seen it as.

Just finished the core implementation of a compile time type system for my language Glide.

Link to documentation: https://github.com/dibsonthis/Glide/wiki

I'm working on building out the csv module in my language Glide and I'm at a bit of a crossroads. I initially envisioned the csv module to build a list of objects out of the data and the user manipulates those objects directly and then can serialise them back to csv. However, I've also come up with a different solution that doesn't involve objects, but only flat lists.

My language Glide is currently dynamically typed, however I've been trying to build some sort of type system for it. I chose to go with a dynamic type system because I felt it would be a lot easier to get going, and can be written directly in the language. But I've also noticed that I could be using this time and effort on implementing a "real" static type system in the compiler itself. But I'm unsure which direction I want to take.

So I've noticed the more code I write in my language (Glide), the bigger my "standard library" gets. And by standard library, I mean a bunch of different files that contain really handy functions, i.e list functions like map, filter, reduce and string functions like to_chars, split etc.

Now you can devise a more complex format which would specify what trees map to nulls or empty tables or what-have-you, or even use a complementary Jevko schema to disambiguate what an empty tree means, e.g. https://github.com/jevko/interjevko.js -- but that is a topic for another time.