2024-11-02 00:11:12 <tabemann    > I've written what would be a "safe" Forthy language if it were not possible to escape it by using FORTH::FOO , FOREIGN , and UNSAFE and if it were not for stack overflow and underflow
2024-11-02 00:12:11 <tabemann    > overflow/underflow is the hard part
2024-11-02 00:14:01 <zelgomer    > easy: just make the stack wrap
2024-11-02 00:14:43 <zelgomer    > sorry i was reading about the mill architecture recently
2024-11-02 00:38:05 <veltas      > For overflow/underflow I think you need an ABI where small stack ops are allowed, each step you check level, have some canary/dead zone around ends, and larger ops are all checked
2024-11-02 00:38:59 <veltas      > Massive performance penalty but it is what it is
2024-11-02 00:42:14 <veltas      > I guess if you can map a lone page and only allow drastic stack changes with checks then virtual memory will catch going off the edges
2024-11-02 00:43:03 <zelgomer    > i think that's how pthreads does it. maps guard pages at the boundaries.
2024-11-02 00:58:38 <zelgomer    > i just realized something i'm a little embarrassed to admit. how do traditional forths that parse words into PAD do this at the interpreter:  S" hello" type  ( doesn't parsing type clobber the hello string?)
2024-11-02 01:19:29 <veltas      > Is S" allowed when interpreting?  I would guess old Forths only support when compiling
2024-11-02 01:20:58 <veltas      > S" is state-smart in the standard with file word set only, I had assumed so INCLUDED was easier to use, but not state-smart for a core-only forth
2024-11-02 01:22:55 <zelgomer    > oooohh
2024-11-02 01:23:05 <zelgomer    > that makes way more sense, thanks
2024-11-02 01:23:14 <zelgomer    > i've been getting away with that by cheating
2024-11-02 01:24:08 <zelgomer    > a lot of my forth journey has been having to go back and unlearn things that i thought were clever while i was still learning, but now i look at them and don't think so much
2024-11-02 01:24:19 <veltas      > In a traditional Forth I might have done:   5 >IN +! hello  TIB 9 + 5 TYPE
2024-11-02 01:24:31 <zelgomer    > the way i was doing parsing allowed me to get away with a S" that worked in interpret mode
2024-11-02 01:24:56 <veltas      > I would define PARSE because that can be defined nicely in terms of TIB/#TIB and is quite useful
2024-11-02 01:25:21 <veltas      > PARSE gives you the actual string in the input buffer
2024-11-02 01:25:41 <veltas      > A lot of the trouble here is caused by needing a separate buffer to do a counted string
2024-11-02 01:26:11 <zelgomer    > but that's still dodgy, isn't it? what if it has to refill in order to parse type?
2024-11-02 01:26:45 <veltas      > You can control that though by not writing TYPE on the next line / block
2024-11-02 01:27:08 <zelgomer    > i see
2024-11-02 01:33:01 <veltas      > In the standard I think PAD is separate from WORD
2024-11-02 01:33:25 <veltas      > Yeah it's stated that WORD can overlap with #> but not PAD
2024-11-02 01:33:46 <zelgomer    > there's no way you can know that because forth-standard.org is down again
2024-11-02 01:34:09 <veltas      > I'm looking at the ANS PDF
2024-11-02 01:34:46 <zelgomer    > sorry i don't recognize it if it's not on a web site
2024-11-02 01:36:05 <veltas      > I'm actually surprised that Forth 200x draft still allows WORD and #> to overlap
2024-11-02 01:36:26 <veltas      > I've got the 2019 draft locally too, I'm sad like that
2024-11-02 01:36:41 <veltas      > The website is the 2012 released version I think(?)
2024-11-02 01:37:01 <zelgomer    > why? can you imagine any situation where you'd ever parse while converting a number to a string?
2024-11-02 01:39:32 <veltas      > Dunno, combining some string with a number suffix?  I'm sure there's not a huge cause but seems like the sort of thing that would get 'fiddled' by the committee
2024-11-02 01:42:00 <veltas      > Can you imagine any situation where you would come up with something like ENVIRONMENT?
2024-11-02 01:42:19 <zelgomer    > well since <# #> builds the string from right to left, it's probably fine within certain limits
2024-11-02 01:42:27 <zelgomer    > what does ENVIRONMENT do?
2024-11-02 01:44:59 <veltas      > You give it a string address and size, and it checks if it is a special string defined in the standard like /PAD which would potentially return true, and then the size of PAD under that true value
2024-11-02 01:45:51 <veltas      > I cannot for the life of me understand how it ended up in the standard, or who thought this was a good design for a Forth standard
2024-11-02 01:46:03 <veltas      > It's actually worse than e.g. C standard feature macros
2024-11-02 01:46:50 <zelgomer    > what
2024-11-02 01:47:11 <zelgomer    > so instead of just standardizing a constant /PAD, they want you to do something like " /PAD" ENVIRONMENT [IF] ... ?
2024-11-02 01:47:34 <zelgomer    > S" /PAD"
2024-11-02 01:48:50 <veltas      > In their rationale it says something about how you can't even do that with a core-words-only standard forth
2024-11-02 01:49:09 <veltas      > I don't think they understand what 'rationale' means, it's somewhat related to the word 'rational'
2024-11-02 01:55:04 <zelgomer    > LOL
2024-11-02 01:55:24 <veltas      > So if I want to write code not knowing if the blocks word set is present, then I can write:  : HAS-BLOCK? S" BLOCK" ENVIRONMENT? ;
2024-11-02 01:55:40 <veltas      > And I can put that code in my block, and wonder about chickens and eggs
2024-11-02 01:56:39 <veltas      > Bear in mind if you support files in ANS Forth you must define the block word set
2024-11-02 01:56:51 <veltas      > And a human at the interpreter can just use block words and watch it error out
2024-11-02 01:57:01 <veltas      > if they're not defined
2024-11-02 01:59:31 <veltas      > Not to mention I could have just as easily done:  BL WORD BLOCK FIND NIP  with less code and no new defs
2024-11-02 02:01:01 <veltas      > And that works in F83 and probably a lot of old forths, and isn't considered obsolescent in Forth 200x
2024-11-02 02:02:04 <veltas      > And the whole point of Forth is it's a small implementation, but nothing about ENVIRONMENT? is natural to implement with a minimal standard forth
2024-11-02 02:31:19 <zelgomer    > just ignore the standard
2024-11-02 02:31:19 <zelgomer    > even in c i'm starting to lose faith in the standards
2024-11-02 02:51:52 <lf94        > Has anyone tried pforth? Does pforth follow similar ffi as gforth? Will gforth still be here in 10 years?
2024-11-02 02:52:02 <lf94        > Basically I'm looking for a forth with network functions.
2024-11-02 03:28:18 <tabemann    > in zeptoforth when interpreting S" I put it in a special temporary buffer outside the dictionary
2024-11-02 03:28:33 <tabemann    > i.e. not PAD so it won't get overwritten by anything other than another S"
2024-11-02 03:29:00 <tabemann    > and I make the temporary buffer the size of the input buffer, such that multiple S" 's in a single input won't overwrite one another
2024-11-02 03:29:44 <tabemann    > lf94: never assume that any two Forths are compatible under the hood
2024-11-02 03:29:46 <tabemann    > but
2024-11-02 03:29:58 <tabemann    > pforth is eminently extensible for calling C code
2024-11-02 03:33:30 <tabemann    > so if you want to add C code to a Forth project and you don't care about maximum performance, I'd highly recommend pforth