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> I just added the element(…) function that we discussed yesterday: https://github.com/sharkdp/numbat/pull/431, https://numbat.dev/?q=element%28%22Au%22%29%E2%8F%8E
<triallax> ooh, neat
<achin> TIL about mendeleev
<triallax> i thought you meant mendeleev the actual chemist for a second and was momentarily confused
<achin> i mean the crate :)
<triallax> yeah ik
<triallax> okay very bad implementation but i got basic escapes working
<triallax> not the fancy unicode stuff, just \n, \\, etc.
<achin> next thing we need is tab completion for struct members
<triallax> i'm just mildly confused about what should be handled in the lexer and what should be handled in the parser
<triallax> e.g. should escapes be tokenized separately?
<triallax> i'd say yes
<achin> i think i would have said "no" but i haven't given it much thought at the moment
<triallax> i think that's how a lot of parsers do it but not quite sure why
<triallax> if we don't do it like that we would have to do a bit of tokenization in the parser itself for e.g. \u{...}
<triallax> sounds weird
<triallax> i haven't described it precisely but i think you get what i mean
<triallax> and also we'll need to handle escaping strings in output as well
<triallax> maybe add an ast element for escapes as well to make that easier?
<sharkdp> "next thing we need is tab completion for struct members" -> yes, I tried a few times already :-)
<sharkdp> concerning escape handling: I would hope that we can handle almost everything in the tokenizer? Why would we need new AST elements?
<sharkdp> "we'll need to handle escaping strings in output as well" => ?
<triallax> we wouldn't _need_ them per se
<triallax> a minute
<sharkdp> by the way: for escaping '{' and '}', can we also follow Rust (and many other languages), and do that using '{{' and '}}'?
<sharkdp> ah, I see. I would handle that inside the pretty-printer for strings (which is a bit strange at the moment... it doesn't have surrounding quotes)
<triallax> there's another way i just thought about
<triallax> we could also store the original string in the ast
<triallax> in addition to the unescaped one
<triallax> or we can handle it in the pretty printer like you said
<triallax> i just thought it would be nice to save some work and duplication there
<sharkdp> Assuming we have some escape/unescape function that does Rust-style escaping... then I wouldn't bother saving both versions. I would just call them as appropriate.
<triallax> the problem is we don't
<triallax> we'd either have to find some external library or do this ourselves
<triallax> right now i just wrote some rudimentary code that handles it manually
<triallax> but i agree that not storing it would be best
<sharkdp> https://crates.io/crates/unescape ... one direction. (JS-style, not Rust)
<sharkdp> which might be similar
<triallax> it's probably very similar yeah
<triallax> biggest difference i can think of is not using braces for unicode escapes
<triallax> that could work
<sharkdp> But it doesn't look too complicated, so feel free to roll your own if you want to :-)
<sharkdp> Maybe DON'T include it in the main tokenizer logic? And really just provide escape/unescape functions in a separate module, that can be called from the tokenizer/pretty printer?
<sharkdp> On the other hand, for really good error messages, we probably need to include it in the tokenizer
<triallax> yeah i want good errors
<triallax> it's probably not very hard i guess
<sharkdp> Also, feel free to just support the basics in the beginning (\n, \", {{, }}, …)
<triallax> alright :)
<triallax> and do you want me to quote pretty-printed strings as well?
<sharkdp> I guess we should quote and escape the pretty printed strings. But not the ones that we print, of course.
<triallax> yeah of course
<sharkdp> Not sure if both use the same functionality right now. That might need some adaptation
<triallax> i'll look into it
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
sharkdp has quit [Remote host closed the connection]
sharkdp has joined #numbat
potash has quit [Quit: Ping timeout (120 seconds)]
potash has joined #numbat
<sharkdp> So I have a very basic version of lists in Numbat working.
<sharkdp> But there are a lot of challenges in the type checker
<sharkdp> 1) We don't have polymorphic values yet. So we can't give a type for the empty list []
<sharkdp> 2) Almost all useful functions on lists will be generic over the element type. Very basic things work (len, head, tail, cons) when I implement them via the FFI. But if I now want to use those functions to implement map, filter, etc., I'm running into type inference problems (https://github.com/sharkdp/numbat/issues/166).
<sharkdp> 3) Polymorphism in Numbat only works for dimension types (Scalar, Length, Length^2, Length / Time, etc). But so far, we can't be generic over *all* types, which means we can not give a type to a function that works on all lists, only on lists of dimension types. So no List<Bool> or List<String>.
<sharkdp> 3) cont: We can create lists of Bools, Strings, …; but we can't pass them to a function like `head<A>(xs: List<A>) -> A`.
<achin> how much of a headache to you forsee trying to get numbat to be polymorphic over all types, not just dimension types?
<sharkdp> I think we want most functions (sqrt, mean, …) to just be generic over dimension types. And we definitely want the possibility to just be generic over dimension types. I'd rather not have something like C++ pre-concepts where a call to sqrt(true) would only fail because you can't apply ^(1/2) to something of type bool. I want it to be apparent from the function signature.
<sharkdp> So we would probably need a syntax do distinguish fully generic type parameters from dimension-type type parameters.
<sharkdp> something like: `fn head<$A>(xs: List<$A>) -> $A` where $-prefixed parameters would range over ALL types, not just all dimension types.
<sharkdp> What would probably be better is to have some kind of bounded quantification, i.e. something like trait bounds in Rust/Haskell or C++ concepts
<sharkdp> So that would mean we would have `fn head<A>(xs: List<A>) -> A` if we want all types, but `fn sqrt<A: Dimension>(x: A) -> A^(1/2)`, if we want to restrict a type parameter to just dimension types
<sharkdp> So, yeah. It will be quite a challenge to implement.
<sharkdp> Coming back to the basics. Despite all the problems mentioned above, we can still do some useful things with the current state of lists: https://github.com/sharkdp/numbat/blob/d5f24efd7946a56d6e6dd4dda7bdd7253ce3bb0d/numbat/modules/core/lists.nbt#L10-L55
<sharkdp> And points (1) and (2) above should hopefully be solvable without a complete rewrite of the type system
<achin> is something like fn sqrt<T: Dim>(t: T) -> T be too much for numbat? (it would be annoyingly verbose, i think)
<achin> oh shoot, i did a bad job reading you above messages
<sharkdp> I think I'd be fine with that. We could even think about "T: Dim" being the default quantification when you just say "T". And have something like "T: All" be the way to specify all types.
<sharkdp> I think I like both of these options better than some kind of prefix like $T
<achin> that sounds sensible
<achin> there's something very satisifying about the reverse function you shared
<sharkdp> it's also the most inefficient way to reverse a list :-)
<achin> yeah, but is the very first way to reverse a list that most people will learn in an intro comp-sci class :)
sharkdp has quit [Remote host closed the connection]