Gregory's Server|
31 comments
  @neauoire Doing a bit of pen and paper computing, and I this is probably going to be a very hard problem to solve. In the most general case, you are asking "does this loop terminate" which can't be solved (halting problem). It could be possible to define some limited subset of loops that are known to terminate. However, this would require defining "finite data types" in Uxn and enforcing strings/arrays always end and numbers don't under/overflow.  @CapitalEx OOOoooh, I think you're right. I hadn't made the connection with the halting problem, but that's true, I guess a specific type is indeed the solution here. @neauoire :: (oops broke that one reply by accident) Interested in what ideas you explore within Tal's limits. FP languages have the advantage of a strong type system and pattern matching. If your type is finite and each step reduces the given inputs to their base cases, you can say confidently that "this loop terminates". Idris does this, but it also means some finite functions can't be statically resolved and are marked as partial. @CapitalEx I'm an absolute beginner when it comes to building type systems, so this is all fresh to me. I've been going through the handlful of papers and blog posts on types/concat languages. This morning @toxi gave me a bunch of very interesting links on the topic: https://merveilles.town/@toxi@mastodon.thi.ng/110362257067437570 I'll keep reporting my findings, I've started a stub on the topic here: http://wiki.xxiivv.com/site/type_systems.html @toxi @CapitalEx I promise I'll try to not get sucked in too deeply that I can never re-emerge. :moomin_hello: No! Wait, I'm just dumb, the type checker was right and I couldn't understand what it was trying to tell me. Haha, wow, it's a weird feeling when you build a thing to reflect about a problem and it starts to see things that you don't :maru:  @neauoire this is the kind of joy I find in languages like TypeScript and Rust when I explain to people that the biggest win is in it checking my work and *proving* I didn't make logic mistakes (insofar as the type system can do) some day eventually, I want you to investigate (as a purely learning experiment) tagged unions and exhaustiveness checking. by far one of my most-used features in those two mentioned languages, such checks genuinely made me a better developer. @klardotsh I wrote a tiny bit of Rust and I encountered the branch permutation checker, which is very cool. I'll look into the tagged union checker, that's something I've never heard of before.  I'm starting to get the hang of this now. So, one bad-habit that I had when building my wiki(which I've managed to overcome in the projects I've made afterward) was to hard-crash on error, no matter the stack state, and this just won't fly with the type checker, I've got to keep the stack in balance during error handling. @neauoire what environment are you running your blog in? The UI seems Oberon-like, but the language looks like Forth. @neauoire yaaaayyyy this is a lo-fi flavour of the Result<T> concept :) it's analogous to an Option<T> for methods (words) that might return null. I (very subjectively) find having to handle things in a balanced way like this leads to more understandable code. https://blog.logrocket.com/understanding-rust-option-results-enums/ @klardotsh did you ever come across anything about type-checking in regards to concatenative languages by any chance? The body of work on the topic, that I can find, is extremely thin. @neauoire your assessment is correct. I never found much useful. I was planning my way around doing things very DIY and kinda blue collar since there's almost no academic research or past art to refer to, especially for my plans with Gale (inference, etc) @klardotsh everything that I could find, I've collected here: http://wiki.xxiivv.com/site/type_systems.html I'll improve as I go along.  @neauoire @klardotsh looks like you are in the Maybe monad... and maybe bind is the concatenation you are looking for... @chainik @klardotsh monad? in point-free assembly? I'm having trouble understanding what that might look like. Do you have a link on monads in Joy or Factor? @neauoire @chainik @klardotsh I can imagine a Maybe monad in joy looking something like wordThatReturnsMaybe [doSomethingToResult] map or wordThatReturnsMaybe @neauoire @klardotsh i don't have a concrete suggestion because my head isn't in the details. abstractly, i recognise Maybe and if the rest of the computation was happening in the monad it would type check :)  @neauoire i'm not sure how your type-checker works but the way i'd handle this would be to confirm that the stack at the !&loop corresponds to the initial stack entering &loop. if that is true then you know it's preserving the shape and can just focus on the ?&exit condition @d6 that's how I do it at the moment, it's not throwing an error for the /l scope, it would if the entry and exit was unbalanced, but it's the scmp scope that throws an error since this routine doesn't have an obvious exit. Here's a simpler version of that sort of routine which doesn't trigger an error. @neauoire i guess the checker doesn't know that ?&exit is a possible exit? i would have assumed that it follows both paths and then attempts to unify them later. @bellinitte the thing is that I don't want to trigger an error there, but the issue here is that the scmp routine promises to make an extra byte, and I don't know how to verify that this byte will be created until it reaches !&l. I know it makes sense when you read the code, but I can't figure how who you find it programmatically. |
*throws hands in the air*
Guess I'll add yet another god damn type