2025-02-01 01:14:01 <vms14       > how do you guys signal the user is compiling in the repl?
2025-02-01 01:14:17 <vms14       > I have ok when not compiling and no errors and ... when compiling
2025-02-01 01:14:38 <vms14       > although I can also make the repl to print the stack instead of ok
2025-02-01 01:15:01 <vms14       > I guess I will change the prompt when compiling instead
2025-02-01 01:17:56 <crc         > vms14: I don't have any prompts (so no 'ok') or indicator for compile vs interpret in my systems
2025-02-01 01:21:10 <vms14       > I have it like this now
2025-02-01 01:21:10 <vms14       > https://i.imgur.com/qa1Jmkj.png
2025-02-01 01:21:52 <vms14       > ps changes ok for the stack printing
2025-02-01 01:22:07 <vms14       > but I like that they won't display anything if you are compiling
2025-02-01 01:22:26 <xentrac     > ps?
2025-02-01 01:22:45 <vms14       > print stack
2025-02-01 01:22:51 <xentrac     > aha, not PostScript
2025-02-01 01:23:06 <xentrac     > I was going to say, I don't remember PostScript having that behavior ;)
2025-02-01 01:23:09 <vms14       > it was print.stack but found annoying to use such a large name
2025-02-01 01:23:21 <xentrac     > I think .s is the traditional name
2025-02-01 01:23:28 <xentrac     > not that there's anything wrong with ps
2025-02-01 01:23:37 <vms14       > I have .s but ps is a flag for the repl
2025-02-01 01:23:37 <xentrac     > I was just lacking the context
2025-02-01 01:23:56 <vms14       > the repl prints 'ok' but if you use ps it prints the stack instead of ok
2025-02-01 01:24:23 <xentrac     > oh, I see
2025-02-01 07:40:10 <veltas      > vms14: I like that ... for compiling
2025-02-01 07:41:35 <veltas      > Also printing stack instead of 'ok' as an option is a good idea!
2025-02-01 07:42:37 <veltas      > I usually just print 'ok', but I might steal both of those ideas
2025-02-01 09:52:40 <pgimeno     > agreed, I like the ...
2025-02-01 12:45:17 <vms14       > veltas I like the stack instead because I get tired of using .s
2025-02-01 12:45:43 <vms14       > but since I sort of pretend to be a forth I cheat with those things
2025-02-01 12:46:37 <vms14       > the goal is to cover a subset of forth that makes sense for my case
2025-02-01 12:51:09 <vms14       > veltas note that the ... are the prompt ' >' changing for '...'
2025-02-01 12:51:35 <vms14       > the prompt word looks at the state flag
2025-02-01 12:51:52 <vms14       > and the repl will not print the stack or ok if it's compiling
2025-02-01 17:59:36 <vms14       > I have :noname defer and recurse
2025-02-01 17:59:48 <vms14       > no idea yet how to implement does>
2025-02-01 18:00:14 <vms14       > but I have a memory array which I will use for create, variable, etc
2025-02-01 18:01:36 <vms14       > recurse should be able to recurse indefinitely without blowing the return stack (since it does not exist) and also works with noname definition
2025-02-01 18:02:54 <vms14       > now I have here and allot, which is just a pointer and allot increments it, @ and ! will use that memory array, so you can increment a memory location to provide offsets or accessors
2025-02-01 18:14:54 <vms14       > https://softwareengineering.stackexchange.com/questions/339283/forth-how-do-create-and-does-work-exactly
2025-02-01 18:14:57 <vms14       > this is helpful
2025-02-01 20:05:33 <vms14       > seems I can do in forth: create one create two 24 one ! 3 two !
2025-02-01 20:05:38 <vms14       > is this expected behavior?
2025-02-01 20:05:48 <vms14       > there is no allocation of space
2025-02-01 20:06:39 <GeDaMo      > You can do it, whether it's a good idea or not is a different thing :P
2025-02-01 20:06:47 <GeDaMo      > You might be overwriting something
2025-02-01 20:07:47 <vms14       > GeDaMo I want to have the same behavior, but this gives me a bit of problem
2025-02-01 20:07:57 <vms14       > if it's expected behavior I should do it
2025-02-01 20:08:16 <vms14       > if not then meh
2025-02-01 20:08:37 <vms14       > I'm using an array to simulate behavior and here is just a pointer for that array
2025-02-01 20:09:03 <vms14       > but since there is no pfa or whatever it will not align properly
2025-02-01 20:09:20 <GeDaMo      > A created word just returns the address of the "data field" which traditionally is the address after the word header
2025-02-01 20:09:22 <vms14       > create should not increment here, but it does in gforth
2025-02-01 20:09:56 <vms14       > well it should maybe
2025-02-01 20:09:58 <vms14       >  If the data-space pointer is not aligned, reserve enough data space to align it. The new data-space pointer defines name's data field. CREATE does not allocate data space in name's data field.
2025-02-01 20:11:19 <vms14       > in my case create just creates a word definition that will capture and push the current value of here when executed
2025-02-01 20:12:06 <vms14       > but it says it does not allocate data space
2025-02-01 20:12:19 <vms14       > so shouldn't create one create two fail?
2025-02-01 20:12:29 <vms14       > well access the same memory
2025-02-01 20:14:01 <vms14       > I can make create increment here, but does not seem like it should
2025-02-01 20:16:12 <vms14       > pforth crashes when I set two
2025-02-01 20:16:24 <vms14       > but it also increments here
2025-02-01 20:19:08 <GeDaMo      > Increment what? The dictionary pointer?
2025-02-01 20:33:06 <vms14       > GeDaMo here
2025-02-01 20:33:27 <GeDaMo      > : here dp @ ;
2025-02-01 20:33:37 <vms14       > here create one here .s <2> 504414475616 504414475656  ok
2025-02-01 20:33:48 <vms14       > that's gforth
2025-02-01 20:33:54 <vms14       > pforth also does this
2025-02-01 20:34:02 <GeDaMo      > That's because the header was created
2025-02-01 20:34:07 <vms14       > but gforth seems to allocate enough to save an integer
2025-02-01 20:34:23 <GeDaMo      > gforth is 64-bit
2025-02-01 20:34:35 <GeDaMo      > It'll be incrementing to align the address
2025-02-01 20:34:48 <vms14       > but you can set values without allocating
2025-02-01 20:35:03 <vms14       > create one create two 24 one ! 3 two !
2025-02-01 20:35:06 <GeDaMo      > Yes, Forth generally doesn't prevent you writing to any memory address
2025-02-01 20:35:09 <vms14       > this works in gforth
2025-02-01 20:35:17 <vms14       > but segfaults in pforth
2025-02-01 20:35:36 <vms14       > segfaults when setting two
2025-02-01 20:35:53 <vms14       > so then I would like to assume that is undefined behavior
2025-02-01 20:36:02 <vms14       > and that I do not have to follow it
2025-02-01 20:36:25 <GeDaMo      > Possibly writing to 'one' overwrites part of the header for 'two' so calling 'two' returns an invalid address
2025-02-01 20:36:39 <vms14       > makes sense
2025-02-01 20:36:48 <vms14       > ty GeDaMo for helping me to understand
2025-02-01 20:36:52 <GeDaMo      > :)
2025-02-01 20:37:12 <vms14       > I will just forget about that and expect the user to allocate space
2025-02-01 20:42:13 <GeDaMo      > It's technically possible for 'header space', 'code space' and 'data space' to be in separate memory regions
2025-02-01 20:45:30 <GeDaMo      > You might also separate machine code from threaded code
2025-02-01 20:46:10 <GeDaMo      > There could be advantages on architectures with CPU caches to have different types of data on separate cache lines
2025-02-01 20:47:56 <vms14       > there is no header space, code space is a perl subroutine and data space will be the memory array xd
2025-02-01 20:48:52 <vms14       > I tried to consider sticking to forth and make the dictionary be a linked list in the memory array with headers and alike
2025-02-01 20:49:04 <GeDaMo      > There is header space, it's just not directly accessible from your Forth code :P
2025-02-01 20:49:04 <vms14       > but it made not much sense at the end
2025-02-01 20:50:53 <vms14       > I might rethink that in the future
2025-02-01 20:50:56 <vms14       > if I keep adding features that push me into that direction I will reconsider if I should start again with this method
2025-02-01 20:51:51 <vms14       > at the end I just want to be able to follow most of a forth book with my interpreter
2025-02-01 20:52:34 <vms14       > but being so different internally will require workarounds, which for now I do by abusing closures
2025-02-01 20:52:44 <GeDaMo      > I'm pretty sure that most Forth programs won't be doing anything fancy with headers, they're mainly used for compiling
2025-02-01 20:53:18 <vms14       > defer for example is a closure xD
2025-02-01 20:54:09 <vms14       > it captures a variable named $code in a closure and the closure will execute that code if no arguments are given, if it takes an argument it will update the $code variable to that value
2025-02-01 20:55:02 <vms14       > the interpreter will call that closure without arguments, the 'is' word will take an "xt" and call that closure with that as the argument
2025-02-01 20:55:14 <vms14       > xt is directly the perl subroutine
2025-02-01 20:55:32 <vms14       > : oh 1 2 3 ;  defer ah ' oh is ah
2025-02-01 20:59:35 <vms14       > https://i.imgur.com/dWgKug9.png
2025-02-01 22:04:58 <pgimeno     > "<vms14> recurse should be able to recurse indefinitely without blowing the return stack (since it does not exist)" - wait, what? it has to blow *something*, there might not be a Forth return stack but there should be one
2025-02-01 22:06:13 <pgimeno     > one return stack of sorts, even if it's the Perl return stack
2025-02-01 22:07:59 <pgimeno     > as for CREATE, I can tell you that the Jupiter implements VARIABLE this way: 1 VARIABLE stuff is equivalent to CREATE STUFF 1 ,
2025-02-01 22:30:55 <pgimeno     > "<vms14> create one create two 24 one ! 3 two !" - I only know the details of the internals of the Jupiter, so I can only tell you about it. In the jupiter, the first ! will overwrite the first two letters of the name "TWO", and the second ! will be harmless.