2023-10-05 00:39:53 <xelxebar    > FUZxxl: Not quite sure what you mean. Forks aren't directly related to the composition operators.
2023-10-05 00:41:22 <xelxebar    > (f g h) is a function when f, g, and h are functions. It gives the obvious meaning to things like (f+g).
2023-10-05 00:42:02 <FUZxxl      > xelxebar: I know that the semantics of forks and trains differ between J and APL
2023-10-05 00:42:07 <FUZxxl      > but I always mess them up
2023-10-05 00:42:09 <xelxebar    > Specifically (f g h) ←→ {(⍺f⍵)g(⍺h⍵)}
2023-10-05 00:43:29 <xelxebar    > Yeah, hook semantics differ between J and APL, but that's about it, AFAIK. The syntax is actually the exact same.
2023-10-05 00:43:29 <FUZxxl      > yea that's the same as in J
2023-10-05 00:43:33 <FUZxxl      > there was one that is different
2023-10-05 00:43:39 <FUZxxl      > oh so it was the hook
2023-10-05 00:45:40 <xelxebar    > Yeah (f g) is called a hook, and in APL it's defined to be the same as f∘g.
2023-10-05 00:45:46 <FUZxxl      > oh cool
2023-10-05 00:45:52 <FUZxxl      > so it works like a capped fork
2023-10-05 00:46:00 <FUZxxl      > i.e. what J spells [: f g
2023-10-05 00:46:15 <FUZxxl      > or f@g if you are into conjunctions
2023-10-05 00:47:27 <xelxebar    > Exactly. J's hooks are more interesting in isolation, since they copy the right argument to the left when used monadically.
2023-10-05 00:48:48 <xelxebar    > But, for some reason I find that APL hooks tend to usually be exactly what I want in longer trains.
2023-10-05 00:49:35 <FUZxxl      > also correct
2023-10-05 00:49:43 <xelxebar    > Like, it's usually a question of whether I just want to post-process something or not. Having an implicit compose is not something I've wanted all that often.
2023-10-05 00:49:48 <FUZxxl      > when I write pointsless J code, I find myself typing [: way too often
2023-10-05 00:50:23 <xelxebar    > Same. That always made me feel like I just wasn't finding the natural expression or something.
2023-10-05 00:52:20 <xelxebar    > Man, so much array-language discussion going on here lately :P
2023-10-05 00:52:45 <xelxebar    > Feel like I inadvertently co-opted the channel ⍨
2023-10-05 00:54:02 <FUZxxl      > don't worry
2023-10-05 05:07:38 <veltas      > I'm done with 'main' branch, seen too many development issues caused by it now
2023-10-05 05:07:54 <veltas      > I think the subject's cooled off a bit anyway, will just go back to 'master'
2023-10-05 07:22:18 <veltas      > I think at this point, rather than "if you make a new repo call the main branch 'main'", the advice for me is now "if you make a new version control system"
2023-10-05 07:22:45 <veltas      > master just appears in too many of my scripts and I just can't justify the extra work to handle different names for the 'default branch'
2023-10-05 09:48:43 <KipIngram   > xelxebar: I think the array language discussion had a lot to do with my current interest in it.  But I'm seeking to bring the techniques into a stack-based language, so that makes it at least a little topical.
2023-10-05 09:49:03 <KipIngram   > And we have taken the bulk of our conversation to PM, so I don't think you've caused a problem.
2023-10-05 09:51:18 <KipIngram   > And we had uiua get pointed out - that's kind of a connection too.  I think uiua has done a pretty coherent job of migrating the ideas.  I just wish there was a clean way to avoid having to introduce new symbols.
2023-10-05 09:52:23 <KipIngram   > From what I can tell, uiua solved the "is it a vector or multiple stack items" issue the way you mentioned to me yesterday - it allows one to use _ instead of space, and _ separated items are part of one stack item.
2023-10-05 09:54:27 <KipIngram   > I don't exactly love it visually, but it's probably the best way to proceed given the situation, as is the introduction of the additional symbols to solve the monad/dyad issue.
2023-10-05 09:55:07 <KipIngram   > The biggest problem with that, though, is that those new symbols aren't going to be on your keyboard generally.
2023-10-05 09:59:34 <KipIngram   > It did occur to me that one could resolve the monadid/dyadic question by introducing ONE new symbol - a symbol for a "null operand."  So functions would always be dyadic - if you wanted the monadic version you'd specify the null operand as the second operand.
2023-10-05 09:59:53 <KipIngram   > One new symbol is better than many.  And it's a decision that could be made at compile time.
2023-10-05 10:00:41 <FUZxxl      > sounds like a solution in need of a problem
2023-10-05 10:00:54 <FUZxxl      > the grammar of APL-like languages is unambiguous
2023-10-05 10:01:20 <KipIngram   > Yes, but the discussion at hand is bringing APL's array handling techniques into an RPN environment.
2023-10-05 10:01:31 <KipIngram   > postfix vs. infix.
2023-10-05 10:01:35 <KipIngram   > That changes things.
2023-10-05 10:01:48 <KipIngram   > In Forth, you have a stack full of items sitting there all the time.
2023-10-05 10:02:03 <KipIngram   > When you fire a function, does it use the top stack item or the top two?
2023-10-05 10:02:29 <KipIngram   > In APL itself you're right - it's clear whether or not there is a left operand.
2023-10-05 10:03:13 <KipIngram   > uiua just bit the bullet and didn't try to overload symbols with both types of functionality.
2023-10-05 10:03:35 <KipIngram   > But as I said, at the moment I think one new symbol wins over many new symbols.
2023-10-05 10:04:50 <FUZxxl      > in an RPN environment, just give up on the dualty and have each name reference only one function, not two
2023-10-05 10:05:05 <FUZxxl      > so exactly as you say
2023-10-05 10:05:06 <KipIngram   > Right - that's what I just said uiua did.
2023-10-05 10:05:17 <FUZxxl      > I was typing the comment before you had finished, sorry
2023-10-05 10:05:23 <KipIngram   > But that would make it harder for an APL programmer to switch over.
2023-10-05 10:05:46 <KipIngram   > And you won't find those new symbols on a standard APL keyboard layout, so it complicates keyboard support a lot.
2023-10-05 10:05:52 <KipIngram   > No worries - that happens a lot around here.
2023-10-05 10:07:03 <FUZxxl      > APL programmers won't switch over anyway
2023-10-05 10:07:11 <FUZxxl      > you're looking at Forth programmers as your audience
2023-10-05 10:07:38 <KipIngram   > Likely.  But we'd have to create all of our own tutorial material and so on, which would be more work.
2023-10-05 10:07:54 <FUZxxl      > you'll have to do that anyway
2023-10-05 10:07:59 <KipIngram   > I think it's a matter of taste, actually - I think both approaches are viable.
2023-10-05 10:08:01 <FUZxxl      > also you'll need dynamic memory management
2023-10-05 10:08:03 <FUZxxl      > which is hard
2023-10-05 10:08:06 <KipIngram   > uiua's already done one approach.
2023-10-05 10:08:38 <KipIngram   > Yes, but any solution that offers good support for scientific computing, array or not, is going to impose memory management requirements.
2023-10-05 10:09:00 <KipIngram   > That's been pretty clear to me from the very beginning of wanting an "Octave/Matlab like Forth."
2023-10-05 10:09:11 <KipIngram   > And it requires some kind of type awareness too.
2023-10-05 10:09:25 <KipIngram   > So it's certainly not "pure Forth' anymore.
2023-10-05 10:11:16 <KipIngram   > A bunch of the things I'm wanting to add pushes dynamic memory onto us.  Short duration threads, "sessions" that come and go like in bash, etc.
2023-10-05 10:14:46 <KipIngram   > Anyway, null symbol vs. many new symbols - it feels to me like just a decision that has to be made.  I don't see it as "right vs. wrong."  But that's just an opinion.
2023-10-05 10:15:20 <KipIngram   > Pros and cons.
2023-10-05 10:20:55 <KipIngram   > It does look like there are a few "keystroke places" where new symbols could be put.  I see seven or eight places on my little crib sheet where it looks like shift-alt-key either does nothing or replicates alt-key; those slots could be hijacked.
2023-10-05 10:21:26 <KipIngram   > Anyone look at uiua enough to discern HOW MANY new symbols it uses?
2023-10-05 10:47:59 <xelxebar    > KipIngram: Interesting idea. My only thought is that lots of APL code just just flows some data through a bunch of functions, so visually forcing all applications to be dyadic would actually add a lot of syntactic overhead in practice.
2023-10-05 10:48:03 <drakonis    > https://dt.plumbing/
2023-10-05 10:49:28 <xelxebar    > Hrm... Maybe I'm overstating my case. Looking at my parser code, it might not be terrible.
2023-10-05 10:50:14 <drakonis    > highly inspired by forth
2023-10-05 10:50:29 <xelxebar    > drakonis: Hehe. This looks nifty.
2023-10-05 10:51:11 <drakonis    > the dev runs a concatenative langs discord
2023-10-05 10:53:54 <drakonis    > its basically where the activity in ##concatenative has been bleeding into lately
2023-10-05 11:00:10 <KipIngram   > I see what you're saying.  You're saying that _<function> would wind up getting invoked a lot.
2023-10-05 11:01:01 <KipIngram   > So you'd wind up with stuff like _⍴_⍳_∇_∆
2023-10-05 11:01:13 <KipIngram   > (random symbols there - I wasn't trying to make it mean anything).
2023-10-05 11:01:51 <KipIngram   > That is an issue - it completely disrupts the "shape" of the idiom.
2023-10-05 11:03:05 <KipIngram   > At any rate, I think "how often you need to use it" definitely matters.
2023-10-05 11:03:12 <KipIngram   > Re: it's acceptability.
2023-10-05 11:05:49 <KipIngram   > I'm pretty into the idea of "meaning through shape."
2023-10-05 11:06:34 <KipIngram   > It's how I read - phonics was a "thing" when I was learning to read, but I never found  it to be anything but stupid.  NOT how one should approach reading.
2023-10-05 11:07:29 <KipIngram   > Words are shapes.  Short phrases are shapes.  You recognize the shape and it injects the meaning into your head.  If you have to pick each word to pieces to figure out what it means, you'll never be as good a reader as you could be.
2023-10-05 11:48:53 <KipIngram   > FUZxxl: Actually, I think uiua's trick for keyboard entry of glyphs is adequate for me to consider the "lack of keyboard support" issue mostly resolved.
2023-10-05 11:49:16 <KipIngram   > For each glyph, it lets you type <letter><letter><tab> and that glyph will appear.
2023-10-05 11:49:31 <KipIngram   > That's not something I'd call "awesome," but it gets the job done.
2023-10-05 11:50:04 <KipIngram   > And given that it's a little tedious reaching my right alt key anyway, and particularly hard to get shift-right-alt, I would likely wind up using that method most of the time.
2023-10-05 11:50:17 <KipIngram   > I'd be faster typing <letter><letter><tab>
2023-10-05 11:50:23 <FUZxxl      > interesting
2023-10-05 11:50:54 <KipIngram   > I wouldn't like it at all if the only way to get some symbols was an on-screen clickable keyboard.
2023-10-05 11:51:06 <KipIngram   > That forces a graphical interface when one's not necessarily required.
2023-10-05 11:51:27 <KipIngram   > And forces mouse activity.
2023-10-05 11:53:10 <KipIngram   > It would need to be well-designed; hopefully just the first two letters of the typical "name" we give glyphs would be the right ones.  I'd make rh<tab> give ⍴, io<tab> give ⍳ and so on.
2023-10-05 11:53:24 <KipIngram   > I'd have to work through it to see if that was going to stay smooth all the way through, though.
2023-10-05 11:53:47 <FUZxxl      > the way it's traditionally done is that the special characters are on an extra keyboard layer
2023-10-05 11:53:53 <FUZxxl      > triggered e.g. by the right Alt key
2023-10-05 11:54:00 <KipIngram   > Yes, my keyboard is set up for that.
2023-10-05 11:54:14 <FUZxxl      > (in the original IBM APL, they just used the upper case for this)
2023-10-05 11:54:25 <KipIngram   > But any 'new glyphs' we invent to solve the monad / dyad problem won't likely be found on easily obtainable keyboard riggings.
2023-10-05 11:54:36 <FUZxxl      > (while lower case was upper case; it was just a different ball on the selectric typewriter after all)
2023-10-05 11:54:41 <KipIngram   > Yes, it's neat how history is "speaking to us" here.
2023-10-05 11:54:48 <FUZxxl      > again, I don't think you need a new glyph
2023-10-05 11:55:06 <FUZxxl      > You are trying to introduce a problem and then solve it
2023-10-05 11:55:06 <KipIngram   > I thought you said you'd use new symbols to resolve monadic/dyadic confusion.
2023-10-05 11:55:20 <FUZxxl      > I said make the names of each funcion unique
2023-10-05 11:55:36 <FUZxxl      > instead of overloading the same name for monadic and dyadic functions
2023-10-05 11:55:40 <KipIngram   > This isn't about "fixing something that's broken in APL."
2023-10-05 11:55:50 <KipIngram   > It's about migrating APL capabilities into an RPN setting.
2023-10-05 11:55:54 <FUZxxl      > the monadic/dyadic thing is an artefact of APL having an infix grammar
2023-10-05 11:56:01 <FUZxxl      > in a postfix grammar, why should it exist?
2023-10-05 11:56:07 <FUZxxl      > you could have any number of operands
2023-10-05 11:56:38 <KipIngram   > Ok, now I'm really confused.  In APL some symbols have ambiguous function - monadic vs. dyadic.  I want both capabilities in my RPN array language.
2023-10-05 11:56:59 <KipIngram   > Will I continue to try to use a single symbol in those cases, or introduce a brand new symbol for one or the other of the functions?
2023-10-05 11:57:31 <KipIngram   > You can certainly say "you don't need this to be RPN - APL has already given this all to you," and that is true.
2023-10-05 11:57:51 <KipIngram   > But this is a Forth channel and we're all Forth nuts around here.  The RPN nature of the target is kind of a given.
2023-10-05 11:58:36 <KipIngram   > Here's an explicit example:
2023-10-05 11:59:07 <KipIngram   > ⍴3 4 returns the shape of 3 4.  3 4 ⍴ ⍳12 returns a 3x4 matrix.
2023-10-05 11:59:15 <KipIngram   > In an RPN world, what will this do?
2023-10-05 11:59:27 <KipIngram   > 12⍳ 3_4⍴
2023-10-05 11:59:34 <FUZxxl      > yes, brand new symbol for each of those
2023-10-05 11:59:38 <FUZxxl      > that's what I propose
2023-10-05 11:59:47 <KipIngram   > Ok - gotcha.  That's what I thought you had said earlier.
2023-10-05 11:59:57 <FUZxxl      > i.e. separate out the two meanings of iota
2023-10-05 12:00:00 <KipIngram   > Now, how do I get those new symbols onto my keyboard?
2023-10-05 12:00:08 <FUZxxl      > use words, not single symbols
2023-10-05 12:00:19 <KipIngram   > I understand it's technically possible of course.
2023-10-05 12:00:21 <FUZxxl      > you need whitespace separators anyway with forth
2023-10-05 12:00:33 <FUZxxl      > so yet another reason not to follow APL conventions
2023-10-05 12:00:35 <KipIngram   > I'm planning to relax the space delimitation requirements.
2023-10-05 12:00:45 <FUZxxl      > good luck
2023-10-05 12:00:49 <KipIngram   > :-)
2023-10-05 12:01:04 <KipIngram   > Well, take that 12⍳
2023-10-05 12:01:25 <KipIngram   > As soon as the compiler sees ⍳ it says Oh, that's not a digit, so it wraps up the number.
2023-10-05 12:02:03 <FUZxxl      > but what if you have foo⍳
2023-10-05 12:02:09 <FUZxxl      > can ⍳ not be a part of a word?
2023-10-05 12:02:20 <KipIngram   > It could be done either way.
2023-10-05 12:02:27 <FUZxxl      > also note that this breaks the extensible integer literals some forths have
2023-10-05 12:02:43 <FUZxxl      > where you can essentially hook the "unknown word" handler and do your own integer parsing.
2023-10-05 12:02:54 <KipIngram   > Maybe you require foo ⍳ or maybe ⍳ is a reserved character.
2023-10-05 12:03:04 <KipIngram   > Just like + or - would be in a lot of languages.
2023-10-05 12:03:32 <KipIngram   > I want a lot more "literal" support one way or another.
2023-10-05 12:03:40 <KipIngram   > Literal strings, literal arrays, literal matrices, etc.
2023-10-05 12:03:49 <KipIngram   > I haven't made full decisions about exactly how to approach that.
2023-10-05 12:04:00 <KipIngram   > Or even exactly how to write some of those literals.
2023-10-05 12:04:05 <FUZxxl      > sure
2023-10-05 12:04:10 <FUZxxl      > I wish you best of luck with that
2023-10-05 12:04:29 <KipIngram   > Well, thank you - me too I suppose.  :-)
2023-10-05 12:04:40 <KipIngram   > It's still a thought process right now.
2023-10-05 12:04:55 <KipIngram   > When my Forth first powers on it will just be Forth, more or less completely standard.
2023-10-05 12:05:05 <KipIngram   > This other stuff I'll LOAD
2023-10-05 12:05:21 <KipIngram   > I think of it as an application environment, not as "the native system."
2023-10-05 12:06:16 <KipIngram   > I have to answer a lot of questions about how smart I want to try to make it>
2023-10-05 12:06:24 <KipIngram   > Consider 12⍳ again.
2023-10-05 12:06:36 <KipIngram   > Does that compile to a literal 12 and an executed ⍳?
2023-10-05 12:06:53 <KipIngram   > Or do I recognize that I can just compile a literal vector with those numbers in it?
2023-10-05 12:07:36 <KipIngram   > 12⍳ is effectively a constant.
2023-10-05 12:14:07 <KipIngram   > Re: your foo⍳ question, APL allows ⍳foo so it clearly treates ⍳ as a reserved symbol.
2023-10-05 12:14:12 <KipIngram   > I suspect I'll do the same.
2023-10-05 12:14:23 <KipIngram   > This is no longer Forth we're talking about here.
2023-10-05 12:16:50 <veltas      > We're not in Kansas anymore
2023-10-05 12:16:55 <KipIngram   > I do like the idea of there being hooks in the system I can use for some of these extensions - when it first starts up it'll be Forth and integers will really be the only literals it knows how to handle.  Just like normal.  I'll hook something new into that.
2023-10-05 12:17:21 <KipIngram   > And probably will have a place to hook that lets me grow beyond rigid space delimitation.
2023-10-05 12:34:42 <KipIngram   > Also, the distinction between, say, -3 and ¯3 is useful.
2023-10-05 23:33:38 <KipIngram   > Wow - the character "Shaw" that showed up a couple or three seasons into Person of Interest is just phenomenal.  She's just added to the show plot wise, comic relief wise, and pretty much anything else you can think of.
2023-10-05 23:39:59 <thrig       > comic sans relief might also be good
2023-10-05 23:56:41 <KipIngram   > :-)