2023-06-30 04:32:28 <lich        > KipIngram: just send him prelogomena to any future metaphysics, at least a lecture on Kant, I hate when people think in pre-Kantian terms, like those issues are 'proven' to be impossible to be proven
2023-06-30 04:32:41 <lich        > therefore it is a complete waste of tiem to think about simulation theory
2023-06-30 04:32:49 <lich        > ##forth - Forth programming
2023-06-30 04:42:22 <veltas      > The waters are separated by a firmament
2023-06-30 04:44:07 <veltas      > Don't worry lich we do a lot of off-topic discussion. It's not stated as a rule but I like to think off-topic conversations would shush if someone came to actually ask a Forth question though
2023-06-30 04:45:44 <veltas      > : LEFT  RIGHT RIGHT RIGHT ;
2023-06-30 04:46:34 <veltas      > My robots are the most efficient :)
2023-06-30 04:49:15 <veltas      > Is there any other language with this kind of brevity? I can't think of one
2023-06-30 04:49:40 <veltas      > How would you write this in Haskell if it was done with side effects?
2023-06-30 10:12:49 <KipIngram   > That's exactly the difficulty I have with functional languages - my thinking is so nailed into embedded type applications where it's all about "doing stuff" to real hardware sitting out there.  The "side effects" are exactly the point, and achieiving them functionally seems awfully "round about."
2023-06-30 10:17:29 <drakonis    > to be honest, FP is somewhat overloaded these days
2023-06-30 10:29:19 <KipIngram   > In my meager understanding of it, when you write a statement you aren't describing something "to be done now" - you are "stating a fact" that is universally true, at all times.
2023-06-30 10:30:08 <KipIngram   > There's really not any concept of "flow of time" in functional programming, or something like that?
2023-06-30 10:30:17 <drakonis    > you're thinking about haskell here
2023-06-30 10:30:39 <drakonis    > which, to be honest, is actually a common mistake to make when thinking about fp
2023-06-30 10:31:35 <drakonis    > haskell does have a problem with the flow of time
2023-06-30 10:33:19 <drakonis    > the laziness makes it hard to reason about time and space when executing code
2023-06-30 10:35:33 <drakonis    > you can reason about the theoretical complexity of algorithms but the implementation otoh
2023-06-30 10:47:36 <KipIngram   > I know Prolog is a bit the same way - each statement you make is just a declaration of a relationship.
2023-06-30 11:05:04 <thrig       > there is a certain logic to it
2023-06-30 11:25:23 <veltas      > KipIngram: But Haskell does support side-effects, that's why I was asking for an example of the syntax, because I don't know by heart how you could write that on one line
2023-06-30 11:25:39 <veltas      > I've seen it before and it looks good to me
2023-06-30 11:26:26 <veltas      > My main issue with Haskell is it seems to scare people away and it's not that efficient, but on the plus side it's often succinct and has a nice strong type system
2023-06-30 11:27:03 <Zarutian_iPad> you mean strict, right?
2023-06-30 11:27:54 <veltas      > "These look like big strong types, don't they?"
2023-06-30 11:28:36 <Zarutian_iPad> the issue I have with Haskel is the over reliance of types for dispatch and the annoyance of its syntax
2023-06-30 11:54:01 <remexre     > veltas:  left = right >> right >> right
2023-06-30 11:54:43 <remexre     > or left = do { right; right; right }  (or that could be written with significant whitespace instead)
2023-06-30 14:28:15 <veltas      > Thanks remexre
2023-06-30 14:30:27 <veltas      > When I said 'strong' I did it somewhat consciously to mean 'good'. I don't think strict=good. A strict type system that's too limiting or too much of an overhead to development would be arguably worse than a weak type system that gets in your way less while catching 90% of the type errors that are helpful
2023-06-30 14:31:09 <veltas      > I don't have much experience with Haskell, I've barely used it, it just seemed good from what I saw. I can't remember how it affected dispatch
2023-06-30 14:32:03 <remexre     > I think Zarutian_iPad was referring to type classes
2023-06-30 14:32:31 <remexre     > There's a kinda funny example with the length function; length (1, 2) == 1
2023-06-30 14:35:05 <veltas      > I'm trying to choose a syntax for a sized array literal for NewB, right now I've settled on {a, b, c; [size]} when you want to init first three, and init the rest as 0 to produce a length 'size' array
2023-06-30 14:35:29 <veltas      > Does this look alright? Does anyone have a better suggestion?
2023-06-30 14:36:16 <unjust      > what about [size]{a, b, c}; ?
2023-06-30 14:36:29 <veltas      > That's another thing I've considered
2023-06-30 14:37:09 <veltas      > I've thought about supporting anonymous functions, but I could require e.g. [](){...} for that
2023-06-30 14:37:44 <unjust      > are you going to allow nested functions?
2023-06-30 14:37:45 <veltas      > Or maybe something with the 'arrow' operator, since I don't even have an arrow token yet, so that's totally free for anonymous functions
2023-06-30 14:38:10 <veltas      > I'm considering it because I want to be able to provide small one-liner code that people like to use to show off modern languages
2023-06-30 14:39:56 <veltas      > But [size]{a, b, c} is definitely a contender
2023-06-30 14:54:32 <veltas      > Oooooh, maybe I can use () to start an anonymous function. Because () is only valid as a suffix (function call) so I can detect it differently as a prefix.
2023-06-30 14:54:35 <veltas      > (){...} and ()(args){...}
2023-06-30 14:54:40 <veltas      > For anonymous functions
2023-06-30 14:55:18 <veltas      > I'm definitely not going to support different kinds of capture, if I support capture at all, so I don't need anything in those brackets like in C++
2023-06-30 23:48:51 <KipIngram   > I realize we're not necessarily talking about Forth here, but to me "nested functions" just subverts the whole idea from Forth of making your definitions concise and short so that they "fit in your short term mental store."
2023-06-30 23:49:08 <KipIngram   > A nested function automatically makes the outer function bigger.