16:23 <alexshpilkin> proteusguy (or proteus-guy... are you the same person?): not necessarily. I am pessimistic towards language designs that try to combine heavy abstractions with low-level access to the machine, because you usually get all the predictability (and therefore optimizability) of the latter coupled with all the performance of the former

16:25 <alexshpilkin> from a cursory reading of the doc pages it doesn't seem that ActorForth strives for the low-level access characteristic of classic Forth, so, well... the actor model is cool, stack-based (concatenative, however you want to call them) languages are cool, so merging them may well get you something useful

16:27 <alexshpilkin> though from the same very cursory reading it doesn't appear that the type system is particularly good... swap : Any Any -> Any Any is a rather weak typing (I'd hope for swap : forall a b. a b -> b a or something like that)

16:28 <proteus-guy> alexshpilkin, yeah our target domain is different than what is classically forth - but the architectural drivers are the same - relentlessly eliminate all unnecessary complexity. Our intention is to have a system where a single developer can understand the full tech stack from the top all the way to the gate level. Not possible on "modern" tech stacks.

16:29 <proteus-guy> Ultimately it'll be Any1 Any2 -> Any2 Any1. Just hasn't come up given where we are in the initial implementation.

16:29 <proteus-guy> Actually it'll look more like swap : _1 _2 -> _2 _1

16:31 <alexshpilkin> well, parametric polymorphism by any other name ...

16:31 <alexshpilkin> but good to know you are planning it

16:32 <proteus-guy> alexshpilkin, part of what we're doing is trying to see how powerful a type system can be implemented in a point-free stack based language.

16:34 <alexshpilkin> oh, really? I'll be watching that place then :)

16:35 <proteus-guy> yeah this is more of a "discover based" rather than a planned based system and we expect that it'll take a few implementations before we get the right balance.

16:36 <alexshpilkin> have you seen Kleffner's talk about typing stack-based languages (http://prl.ccs.neu.edu/blog/2017/03/10/type-inference-in-stack-based-programming-languages/)? I've linked to it before on ForthHub, but it... well, wasn't met with enthusiasm

16:37 <proteus-guy> yes I have that paper and have read it a few times.

16:42 <alexshpilkin> wohoo

17:25 <siraben> alexshpilkin: you might be interested in my implementation of Algorithm J (of the HM type system) for a concatenative language: https://github.com/ActorForth/ActorForth/blob/haskell/forth.hs

17:25 <siraben> It uses a representation of the stack isomorphic to nested tuples, so barely ant difference from Algorithm J.

17:26 <siraben> It properly deals with polymorphic functions like swap : a:b:s → b:a:s

17:27 <siraben> where a b s are type variables

17:31 <siraben> alexshpilkin: why wasn't it met with enthusiasm from ForthHub?

17:37 <siraben> I should note that there isn't anything particularly hard about type inference in stack-based languages. With a proper AST representation it's no different than writing a typechecker for a functional language.

17:45 <alexshpilkin> <siraben "alexshpilkin: why wasn't it met "> *shrug* it was mostly met with silence, so no idea. maybe everybody already knows that, maybe nobody is interested, maybe I'm just unpleasant to talk with

17:47 <siraben> Skimming through that conversation, heh that's interesting. Dynamic words like EXECUTE are problematic from a static analysis perspective. This sort of thing is similar to the situation in Lisp.

17:48 <alexshpilkin> <siraben "alexshpilkin: you might be inter"> (I have to admit I've never actually implemented inference, even though I think I kinda understand how it works. No excuse really)

17:49 <siraben> Forth in its current form is no better than assembly, so naturally adding a type system severely restricts the language.

17:50 <siraben> alexshpilkin: I believe using Matrix replies duplicates the content for IRC users, please use mentions instead.

17:50 <siraben> (I'm also on a Matrix bridge)

17:51 <siraben> I'll have to sign off for tonight, will check the messages tomorrow.

17:53 <siraben> alexshpilkin: Do you come from an FP background as well?

17:56 <alexshpilkin> siraben : well, my point was there that first-order languages are just easier to type. EXECUTE by itself appears to be just an application operator like Haskell's ($), so not particularly evil, no? though the fact that everything happens on a single stack stack and has variable arity does complicate things

17:58 <alexshpilkin> siraben : well to some extent yes. more like I owe my interest in types to FP (Haskell in particular; proof-assistant-y things tend to go over my head, sadly)