triallax changed the topic of #numbat to: The Official Numbat channel https://numbat.dev | This channel is publicly logged at https://libera.irclog.whitequark.org/numbat | Please read https://workaround.org/getting-help-on-irc/ if you're new to IRC!
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
<sharkdp> Numbat just gained support for structs! (https://numbat.dev/doc/structs.html)
<achin> \o/
<sharkdp> I'm pretty excited about this change. One application that I am currently thinking of is some kind of database lookup for properties of chemical elements, compounds or materials.
<sharkdp> something like `element("Au").atomic_weight`
<achin> that sounds very nice
<sharkdp> where `element` would be a function from `String -> Element`, and `Element` would have multiple fields with properties of that element.
<achin> or instead of having the g0 and g_moon variables, a database of constants like `planet("moon").gravity`
<sharkdp> yes
<sharkdp> But planet("moon") would return a runtime error, of course :-)
<achin> why's that?
<sharkdp> Just kidding (because the Moon is not a planet)
<achin> oh, hah
<sharkdp> I'm also thinking there might be some useful interaction between DateTime and structs
<achin> "planet" is easier for me to spell that "astronomical_body" :)
<achin> being able to do `now().year` could be interesting
<sharkdp> I might be pretty natural to access "fields" of a DateTime object
<triallax> sharkdp: awesome!
<triallax> structs are very nice
<sharkdp> achin: exactly
<triallax> okay those ideas are very interesting
<triallax> the element one is particularly intriguing
<triallax> i don't know if it's ever been done before in something like numbat
<sharkdp> Once we add lists, it might also be useful for CSV parsing (where the structure of the CSV would have to be known at compile time)
<sharkdp> Something like `parse_csv<Planet>("list-of-planets.csv")` where `Planet` would be a struct with the field names and physical dimensions
<triallax> yeah sounds nice
<sharkdp> But we would also have to specify the units somewhere, probably
<triallax> also would be nice to be able to read files in general
<achin> that would be a good way to get bulk data into numbat from a common format (instead of writing tools that output data as .nbt files)
<triallax> but actually we don't really have string manipulation
<triallax> so won't be able to do much with it
<sharkdp> It's not very user-friendly, but we have basic string manipulation. I rather see the problem that we don't have lists... so what are we going to read from a file? a single value?
<triallax> i was thinking it would be a string and then you'd do stuff with it
<triallax> but like you said we have only the basics
<triallax> and i'm not sure if we want to go down the path of adding more sophisticated stuff for that?
<achin> btw, the other day i wanted to know the length of a string. i normally use python for this, but i tried to use numbat. but i couldn't get it to work in numbat because my string has brace characters that caused numbat to try to apply string interpolation
<triallax> we could add raw strings
<triallax> either r"..." or `...`
<sharkdp> Right. I think it shouldn't be our most important goal to turn Numbat into a language which allows us to write custom format parsers. But I definitely think we should have functions available for parsing common formats like CSV, Numpy, maybe JSON.
<triallax> or maybe """..."""
<triallax> sharkdp: agreed
<triallax> json i'm a bit ambivalent about maybe
<triallax> but could work
<triallax> given that it's unstructured though we'd need something like a hash map type
<sharkdp> I was rather thinking of a less dynamic interface. After all, our strength is that Numbat is a statically typed language.
<triallax> so you're thinking of requiring a schema?
<sharkdp> Hm, no
<triallax> hmm, interested to hear what you have in mind
<sharkdp> Not a fixed layout
<sharkdp> Haven't thought this through :-). But the user could specify the expected datatype. And then we could have something similar to serde
<triallax> is what serde has not basically a schema?
<sharkdp> struct MyJsonFormat { lengths: List<Length>, timestamp: DateTime }
<triallax> that was pretty much what i was thinking
<sharkdp> Ok
<triallax> am i misunderstanding what the term means?
<achin> maybe you define a numbat struct and then try to get serde to deserilize something to that struct, and if it fails, that's just a runtime error
<achin> s/struct/struct or list/
<triallax> can you get serde to do that at runtime?
<sharkdp> No, I thought you meant we would define some kind of global "Numbat JSON file schema". Where we could only read JSON files of that one particular type.
<triallax> ah, no
<triallax> we were thinking basically the same idea
<sharkdp> achin: I don't think we can use serde
<sharkdp> But a very basic `parse_json<MyJsonFormat>("file.json")` might be doable
<achin> why's that?
<sharkdp> as triallax said, in order to use serde, we would have to specify some kind of schema at (Rust) compile time
<achin> that's just for serde's automatically derived Deserialize trait. serde can deserilize json data into a generic 'Value' type (which you can then deconstruct further at runtime as needed)
<sharkdp> achin: Right, this is what we need. I thought that would be part of some generic json-parser crate, not serde_json.
<triallax> yeah we could use that
<triallax> not that i was expecting finding a json parser to be troublesome at all :)
<achin> 👍 understood, agreed
<achin> but i was thinking of borrowing the concept
<sharkdp> Okay, once we have a List<T> datatype, we can do some powerful things :-)
<achin> where the numbat user can say "i want to deserlize some json data into this numbat struct"
<sharkdp> achin: yes. apply the serde concept to Numbat. Define a datatype (struct or list of structs or …) and then …
<sharkdp> exactly
<triallax> this all sounds very neat
<achin> and numbat would handle that stuff, instead of requring the numbat user to manually to all the annoying type unwrapping you need to do when parsing json
<triallax> hmm but also
<triallax> do we want to handle the cases where a field is not present
<triallax> where rust typically uses Option
<triallax> or should we keep it simple
<sharkdp> This is what I meant by "a basic version of …" above :-)
<triallax> right yeah
<achin> always keep it simple at first :)
<triallax> yeah i was thinking for later of course
<triallax> but this sounds exciting
<sharkdp> achin: Coming back to strings. Yes, they definitely need some work. Escape sequences also don't work (you can't have a " inside a string, you can't have a newline, etc).
<sharkdp> That shouldn't be too hard, I think. Only touches the tokenizer and the parser.
<triallax> can you let me handle it?
<triallax> good refresher back into the project
<sharkdp> Of course :-)
<triallax> rust-style escapes?
<achin> want me to create an issue to track the topic?
<triallax> sure
<triallax> and also do we want raw strings
<sharkdp> yes and yes
<triallax> should be easy to add
<sharkdp> I would think so, yes. I don't see a need for them right now, but if we can add them easily, let's do it.
<triallax> i'll do it in a separate pr for simplicity
<triallax> but sounds good
<sharkdp> Can't be long until someone needs regexes inside Numbat :-)
<triallax> hmm
<triallax> i would be somewhat opposed to regexes
<sharkdp> just kidding. it's just a case where I sometimes use raw strings
<triallax> haha
<triallax> the ship might have already sailed but i would've possibly considered requiring an f format specifier for string interpolation
<triallax> could be a bit annoying though
<triallax> if somebody forgot to add it in e.g. a function's code
<triallax> wouldn't get any errors
<triallax> yeah that's not nice
<achin> since we're here ponding large expansions of numbat's scope.... i've sometimes wondered if it would make sense for numbat to be able to load FFI functions as small wasm blobs, allowing arbitrarily complex functions to be brought into numbat. i have no realistic use cases for this, though
<triallax> c ffi???
<achin> wasm
<triallax> i was just thinking out loud
<triallax> a c ffi sounds very cursed but also very useful occasionally
<achin> that requires dlopening a shared library, which is annoying to do in a portable way, and means that your entire process can be crashed with a buggy function
<triallax> that's why i said it's cursed
<triallax> i've never done a c ffi before so it would be an interesting experiment for learning's sake
<achin> if you wanted to get your feet wet, you could play with python's ctypes module
<triallax> or i could go hardcore and try calling some c functions from asm
<achin> do whatever sounds fun to you :)
<sharkdp> I mean, we can call C functions and WASM functions via the Numbat-Rust FFI. But I guess you're thinking of doing that dynamically. Like loading an external module via `use`. But instead of Numbat code, you load WASM.
<achin> yeah
<triallax> wasm could be neat
<triallax> but also more trouble than it's worth?
<achin> like i said, i don't really have any real use cases in mind
<triallax> could be useful for plugin-like functionality
<sharkdp> I can definitely see how that could be useful, but it wouldn't be my top priority right now.
<triallax> what's your top priority?
<sharkdp> I think there are two important things that users would actually need: (1) arbitrary precision integers, higher-precision floats (2) better unit simplifications
<triallax> sounds sensible
<sharkdp> The thing I'm personally most excited about would be extensions to the type system: Adding lists, adding sum types ("proper" ADT-style enums), better polymorphism support, type inference, closures, …
<triallax> numbat would be nearly a full-fledged functional programming language at that point :D
<triallax> will we also get an accidentally turing-complete type system to complete the pack
<sharkdp> I'm currently reading "Types and Programming Languages". So the list of ideas is endless :-)
<sharkdp> C++ bashing? :D
<triallax> c++ did come to mind, though i wasn't necessarily bashing it specifically
<triallax> also just remembered something funny
<triallax> trying to find it
<triallax> c's printf is turing complete
<triallax> c++ definitely isn't alone in that club
<triallax> i remember people doing pretty interesting things with purescript's type class system
<sharkdp> I miss PureScript.
<triallax> yeah i don't use it anymore
<triallax> i would say the rust rewrite has been a massive success though
<triallax> my initial skepticism was entirely unwarranted
<sharkdp> For a moment, I thought the PureScript compiler had been rewritten in Rust :D
<triallax> oh haha no
<triallax> that would be neat
<triallax> i still don't have ghc packaged for my distro
<sharkdp> I need to leave. It's already `now() -> tz("Europe/Berlin")`. Everyone: I would also be interested to know what your biggest priorities for Numbat would be
* triallax gets the idea to have a numbat irc bot
<sharkdp> :-)
<triallax> honestly i don't really have any priorities, my use case for numbat is very basic
<triallax> just a glorified units converter
<triallax> but good night :)
<triallax> i really like the numbat irc bot idea though, i think i'm going to do it
sharkdp has quit [Remote host closed the connection]
<achin> i might beat you to it ;)
<triallax> oh no
<triallax> friday evening project perhaps
<triallax> never wrote an irc bot before but this should be simple