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