wow, what an fascinating talk. this seems really fun to play with and it's giving me the same satisfying feeling of perspective shift that I first got from learning about FP, so Teodor definitely lived up to his introduction
That's a hard-to-search-for talk! I have an answer to the "three stack elements" conjecture: It's not true. Turing completeness requires a stack language to be able to access elements at any depth, so all stack languages that I know of have an idomatic way of doing so, and I'm not talking about bad practices like "pick" from Forth. There's some version of a "dip" operator in every concatenative language that allows to execute a piece of code as if the top element wasn't on the stack, and then return it. In high level languages like Factor or Quackery this is a literal "dip" operator that takes a quotation as an argument and has type ( X.. a ( X.. -- Y.. ) -- Y.. a ), and in low level ones like there's a way to store the top value on a different stack and retrieve later, like ">R" and "
I wonder why PICK is considered bad practice in FORTH. The only reason I can think of is that something somehow interferes with the stack and your argument becomes invalid. I.e., you have ( y x a b c d ), want a with 3 PICK but before the command is executed something weird happens and steals, let's say c. Then you'll PICK x instead of a. But if we assume that such strange things can happen to the stack, they can render every other stack operation invalid, too. If you had performed 2ROT instead of 3 PICK, your values and stack state also would not have been correct. So, what makes PICK more bad than any other stack operation?
@@N.A._McBee PICK is a bad practice on the conceptual level. The deeper a value is in the stack the less of your concern it should be. If you find yourself caring about access to data deep in the stack you should stop and think whether you are actually in one of the degenerate cases where you need access to so much data at once or if you can actually factor your code into smaller pieces that each cares only about a few items, or even just reorder the arguments to your existing words. Usually the latter is true, so avoiding PICK and ROLL is a good intuition towards better Forth code. (Of course by "deep" I don't mean 3 cells, more like 5 and over)
It does have some potential.
wow, what an fascinating talk. this seems really fun to play with and it's giving me the same satisfying feeling of perspective shift that I first got from learning about FP, so Teodor definitely lived up to his introduction
That's a hard-to-search-for talk! I have an answer to the "three stack elements" conjecture: It's not true. Turing completeness requires a stack language to be able to access elements at any depth, so all stack languages that I know of have an idomatic way of doing so, and I'm not talking about bad practices like "pick" from Forth. There's some version of a "dip" operator in every concatenative language that allows to execute a piece of code as if the top element wasn't on the stack, and then return it. In high level languages like Factor or Quackery this is a literal "dip" operator that takes a quotation as an argument and has type ( X.. a ( X.. -- Y.. ) -- Y.. a ), and in low level ones like there's a way to store the top value on a different stack and retrieve later, like ">R" and "
I wonder why PICK is considered bad practice in FORTH. The only reason I can think of is that something somehow interferes with the stack and your argument becomes invalid. I.e., you have ( y x a b c d ), want a with 3 PICK but before the command is executed something weird happens and steals, let's say c. Then you'll PICK x instead of a. But if we assume that such strange things can happen to the stack, they can render every other stack operation invalid, too. If you had performed 2ROT instead of 3 PICK, your values and stack state also would not have been correct. So, what makes PICK more bad than any other stack operation?
@@N.A._McBee PICK is a bad practice on the conceptual level. The deeper a value is in the stack the less of your concern it should be. If you find yourself caring about access to data deep in the stack you should stop and think whether you are actually in one of the degenerate cases where you need access to so much data at once or if you can actually factor your code into smaller pieces that each cares only about a few items, or even just reorder the arguments to your existing words. Usually the latter is true, so avoiding PICK and ROLL is a good intuition towards better Forth code.
(Of course by "deep" I don't mean 3 cells, more like 5 and over)
@@aleksandersabak
That's a good, if not an excellent explanation, thank you!
18:28 AND operator is commutative, so [dup app] and # should do the trick.