17:08:16
##forth
<user51>
The isalpha is there because I wrote it in C first. There's some fancier solutions in the thread, but it seems to me that anything fancier than a simple recursive approach is a bit of an injustice.
18:31:38
##forth
<vms14>
user51 weren't you making your own forth?
18:37:30
##forth
<user51>
vms14: I was always rewriting it from scratch because the code never quite felt right. Basically, lots of little experiements and (rewritten) refinements to the code and my own understanding. Eventually I ended up writing more or less the same code every rewrite and felt like I was getting dimnishing returns.
18:40:17
##forth
<vms14>
yeah that's normal
18:40:39
##forth
<vms14>
you have to learn what you are doing and that requires you to experiment
18:41:17
##forth
<vms14>
you don't know how many times I have rewritten my abomination just to abandon it eventually xd
18:41:34
##forth
<vms14>
but in some way it was worth because I learned and saw stuff
18:42:25
##forth
<user51>
vms14: I also felt like the write-compile-repeat loop was a bit uninteractive, plus the compilation step felt somewhat redundant - if I'm writing another one my next shot would be a mix of FS 3IF and jonesforth. I've mentioned a 'live assembler' before but never written one.
19:13:57
##forth
<vms14>
being able to create code words in assembly on the repl must feel badass
19:14:24
##forth
<vms14>
well I guess it feels like a mad scientist laughing while the world burns
21:08:16
##forth
<MrMobius>
it probably feels scary
21:08:24
##forth
<MrMobius>
since your REPL is about to crash
21:22:35
##forth
<anthk_>
I'd like jonesforth if it used -1 as true
22:57:35
##forth
<veltas>
I prefer 1 as true
22:58:54
##forth
<veltas>
Because it is easier to generate 1 as the 'true' result in assembly on most archs, and potentially 'faster'
23:01:26
##forth
<veltas>
The only bitwise op that is different to a logical op with 1 is "NOT" which I've been writing as 0= the whole time anyway because it's shorter to write and more tolerant of input vs INVERT
23:06:19
##forth
<veltas>
The FORTH79 standard used 1 as 'true', and FORTH83 and later use -1
23:07:08
##forth
<anthk_>
ah, but there aren't many Jupiter Ace's in use :p
23:07:39
##forth
<vms14>
I would love to have one I guess
23:07:51
##forth
<anthk_>
there's canace and xace
23:07:54
##forth
<anthk_>
as emulators
23:07:57
##forth
<vms14>
meh
23:09:12
##forth
<veltas>
Who is responsible for FORTH-83 being so bad?
23:09:50
##forth
<vms14>
I was actually reading a forth book that mentions people getting upset with 83 for making confusing and unnecessary changes
23:09:54
##forth
<anthk_>
bad, why?
23:09:56
##forth
<veltas>
It's weird how many things are better in FORTH-79, or at least things that just shouldn't 'break' between standard revisions
23:10:52
##forth
<veltas>
Well they redefined 'true' to -1 instead of 1, and changed divison to floored instead of symmetric division, etc.
23:11:28
##forth
<veltas>
FORTH-79 is closer to how actual mainstream CPU architectures work today, to further cement my opinion
23:14:11
##forth
<vms14>
btw the book I'm reading is forth: a text and reference
23:14:27
##forth
<vms14>
although I'm just starting it, but I like it so far
23:17:28
##forth
<veltas>
The stack items tend to be numbered from 1, so PICK using 1-indexing makes sense there. I.e. 1 PICK is the 1st stack item, 2 PICK is 2nd, etc.
23:18:42
##forth
<vms14>
but memory and do loop and I assume other things start with 0
23:18:52
##forth
<vms14>
so in this case it makes it a bit more consistent I guess
23:19:02
##forth
<vms14>
that might be the reason?
23:19:22
##forth
<veltas>
Lack of consistency is a defining trait of Forth
23:19:31
##forth
<vms14>
about the -1 I have no idea why
23:19:46
##forth
<veltas>
e.g. >IN doesn't put something in the 'IN stack' or move anything
23:20:08
##forth
<vms14>
I did not feel forth to be inconsistent, but I'm just a noob so I cannot really say much
23:20:27
##forth
<vms14>
php is inconsistent, more like a joke than a language
23:20:38
##forth
<veltas>
I personally think 1 PICK getting 1st stack item makes sense
23:20:51
##forth
<veltas>
I think you could do it either way, but when you pick one you need to keep it
23:21:05
##forth
<veltas>
And that's the issue with FORTH-83, it started on a bad foot by changing so many of the words
23:21:20
##forth
<anthk_>
starting forth needs a new PDF edition with ANS-Forth
23:21:41
##forth
<veltas>
Starting FORTH 2nd edition is for ANS Forth I think?
23:21:55
##forth
<vms14>
the book I mentioned shows the difference in both 83 and 79 when it explains a word
23:21:57
##forth
<veltas>
That's the copy I have, and it's probably easier to find second hand copies of that
23:22:32
##forth
<anthk_>
the online shared PDF is not, it's from 1981
23:22:51
##forth
<veltas>
That's 1st edition
23:22:53
##forth
<anthk_>
they have a web, and I mirrored it with wget but is not as portable
23:23:32
##forth
<veltas>
How did you do a bitwise NOT operation in FORTH-79, did you have to do -1 XOR ?
23:24:39
##forth
<vms14>
who has actually used forth 79? :0
23:24:52
##forth
<vms14>
the only forth I have available is gforth and maybe pforth
23:25:12
##forth
<veltas>
Someone in here was working with Jupiter ACE code which is close to FORTH-79
23:25:13
##forth
<anthk_>
vms14: pforth here trye
23:25:27
##forth
<anthk_>
too*
23:25:51
##forth
<anthk_>
veltas: you can be really close by reading the manuals, they add missing words
23:25:56
##forth
<vms14>
btw how can I bind the xlib.h library with gforth? I need to give it -l and -I directives
23:26:03
##forth
<anthk_>
place it into a tape file and I wil be fine
23:26:07
##forth
<anthk_>
vms14: system
23:26:08
##forth
<anthk_>
?
23:26:20
##forth
<anthk_>
-I /usr/X11R6/include at openbsd
23:26:51
##forth
<anthk_>
and -L /usr/X11R6/lib
23:27:01
##forth
<vms14>
yeah but how I give those flags to gforth
23:27:02
##forth
<anthk_>
in my machine
23:27:03
##forth
<anthk_>
pkg-config --cflags --libs x11
23:27:03
##forth
<anthk_>
-I/usr/X11R6/include -L/usr/X11R6/lib -lX11 -lxcb -lXau -lXdmcp
23:27:11
##forth
<vms14>
I only see s" curses" add-lib which is -l
23:27:58
##forth
<vms14>
I guess creating some object file and then a wrapper on it?
23:28:03
##forth
<vms14>
that sucks
23:29:27
##forth
<anthk_>
veltas: -1 invert ?
23:29:30
##forth
<vms14>
maybe I have more luck with pforth
23:30:54
##forth
<veltas>
There's no INVERT in FORTH-79
23:30:54
##forth
<anthk_>
-1 negate
23:31:30
##forth
<veltas>
In FORTH-79 NOT and 0= are defined to be identical, which I think probably annoyed some people
23:31:38
##forth
<veltas>
And there's no bitwise NOT
23:31:55
##forth
<veltas>
That may well be why they insisted on -1 for 'true' in FORTH-83
23:32:04
##forth
<anthk_>
ah ok
23:32:19
##forth
<anthk_>
now I recall 0=
23:32:42
##forth
<veltas>
In defense of FORTH-79, NOT is a readable human word instead of 0= for those 'logical not' scenarios
23:33:12
##forth
<veltas>
But they should have defined a standard one's complement word
23:33:30
##forth
<vms14>
I like the on and off words
23:33:41
##forth
<anthk_>
so they defined it to match both as flags
23:33:53
##forth
<vms14>
if using real hardware I would love to do something like: led on
23:34:04
##forth
<anthk_>
because of 0= and invert
23:35:09
##forth
<anthk_>
I'm using pforth with the web edition of starting forth, but I'm trying stuff on eforth too (the one under muxleq)
23:35:14
##forth
<veltas>
ON and OFF are very common defs, yet not in any of the standards
23:35:57
##forth
<vms14>
gforth has them, I thought they were a defined word by the book author
23:36:12
##forth
<veltas>
This is one of the pitfalls of Forth, that the meaning of 'ON' and 'OFF' change significantly depending on the argument
23:37:01
##forth
<vms14>
they are just 1 swap ! and 0 swap !
23:37:22
##forth
<vms14>
or it is c! ?
23:37:30
##forth
<veltas>
-1 in most Forths
23:37:47
##forth
<veltas>
Very few embedded controllers are as simple to control GPIO as setting some addresses to 1 or 0, or -1 and 0.
23:38:18
##forth
<veltas>
So ON/OFF is contrived, it's more useful for pure software programs than embedded programs like a washing machine controller
23:38:57
##forth
<veltas>
Still useful for controlling 'flags' in high-level apps though
23:39:36
##forth
<veltas>
E.g. I use VISUAL ON to enable the visual editor in my Forth startup block
23:39:42
##forth
<vms14>
I want to do something like LED ON before dying and see a led shine
23:40:36
##forth
<veltas>
In real life an LED is probably controlled by a single GPIO pin, and needs at minimum setting a particular bit of a register to control the output
23:40:52
##forth
<veltas>
So if LED is an address/shift pair that could work, if ON was defined specially for it
23:41:47
##forth
<veltas>
In my opinion with Forth you need to fearlessly reject conventions and just define words that make sense for the problem at hand
23:42:20
##forth
<vms14>
if ON does not turn things ON then it's a scam and I want my money back
23:42:36
##forth
<veltas>
And assume that the 'lexical scope' as some would call it will protect you from messing up stuff (and if not then removing defs from the dictionary lookup list is trivial usually anyway)
23:43:16
##forth
<veltas>
My point vms14 is that the nature of 'ON' depends on the argument, but that shouldn't stop you from defining ON to make sense in your specific app
23:43:39
##forth
<vms14>
yeah but you are right anyways
23:44:03
##forth
<vms14>
I should not bend the hardware to work with ON but instead define a new word that makees forth bend to the hardware instead
23:45:00
##forth
<veltas>
Often LEDs are connected directly to a GPIO and to leave the LED off you keep it tri-stated (e.g. set to 'input' direction), and to turn it off you connect it to ground (e.g. set to open-drain output, logic level 0).
23:45:41
##forth
<veltas>
So turning it ON/OFF you often would change the direction, or if open-drain mode then maybe set logic level to 1 to turn off and 0 to turn on.
23:46:33
##forth
<veltas>
If you have a Forth BLOCK that defines the LED behaviour then define ON and OFF in that block to turn the LED on or off
23:46:46
##forth
<veltas>
And then in another BLOCK you can define it to do something else, based on context
23:47:15
##forth
<veltas>
And those blocks can coexist
23:47:45
##forth
<veltas>
Should have said "turn it on* you connect it to ground" earlier
23:49:33
##forth
<vms14>
veltas do you use vocabularies?
23:51:35
##forth
<veltas>
I've used vocabs and wordlists and I have found both to not feel very 'Forthy'
23:52:08
##forth
<anthk_>
and the first m*/ I used as a base for d* and d- didn't work for negative numbers
23:52:17
##forth
<veltas>
My recent favourite thing is to define a word called something like UNLINK which takes a range of words out of the dictionary list, so they cannot be found anymore
23:52:48
##forth
<veltas>
You can do this any time as needed, if irrelevant words hide a useful word, or use it to make words 'private' in a module
23:53:29
##forth
<veltas>
The definition of UNLINK is trivial, doesn't add any overhead, and doesn't change semantics of Forth much; unlike vocabs and wordlists
23:54:52
##forth
<vms14>
but then those words are lost forever?
23:55:02
##forth
<veltas>
anthk_: D* isn't standard is it?
23:55:34
##forth
<vms14>
I saw the smudge bit which is what unlink might be messing with I guess
23:55:37
##forth
<veltas>
They're still there where they're used, but can't be found anymore. Unless you FORGET it all and reload it
23:55:50
##forth
<veltas>
UNLINK works with/without smudge bit support
23:56:25
##forth
<veltas>
The point of UNLINK is to remove the words from the linked list, so you don't need a smudge bit. I don't really like smudge bits, I don't see the point.
23:56:57
##forth
<veltas>
I don't use them for colon defs because I just don't add a word to the dictionary list until ;
23:57:59
##forth
<anthk_>
100 200 m* works
23:58:27
##forth
<anthk_>
but just with two 'integers' giving me a double
23:59:04
##forth
<anthk_>
I don't have m*/
23:59:09
##forth
<anthk_>
which could be the useful one