Actually why were you so disgusted with Forth83, that you switched to C? I do realize you might not like the changesWell, frankly - I couldn't find a compiler I actually liked. I tried turnkey a few times - to be greeted with actually nothing.
— still you could simply stick with fig-Forth (or whichever variant were you using before F83), as many others did,
from what I saw.
<WARNUNG HUMOR>No matter what stupid ideas the Forth standardization committee comes up with,
in 4tH heaven I'm on Cloud Nine - and I'm the one who calls the shots here now</WARNUNG HUMOR>
F83 I found abhorrent
4tH can quite easily be compiled on any platform with a half decent C compiler
This time we'll take a look at Forth compilation - and 4tH.
https://youtu.be/H0uRX5NLu7c
Hans Bezemer
This time we'll take a look at Forth compilation - and 4tH.
https://youtu.be/H0uRX5NLu7c
Hans Bezemer
This time we'll take a look at Forth compilation - and 4tH.
https://youtu.be/H0uRX5NLu7cPretty boring, actually.
F83 I found abhorrent
Yes, that I was asking my question about: what — in particular — did you find
that repulsing in F83?
This time we'll take a look at Forth compilation - and 4tH.
https://youtu.be/H0uRX5NLu7c
Hans Bezemer--
F83 I found abhorrent
Yes, that I was asking my question about: what — in particular — did you findTrue flag, DO-LOOP, SIGN are some Forth-79 things still in 4tH IIRC.
that repulsing in F83?
He said he left forth because it lacked the tools he expected. It took another 10 years for Forth to have file functions. There's still no
standard way of obtaining command-line arguments.
True flag, DO-LOOP, SIGN are some Forth-79 things still in 4tH IIRC.F83 I found abhorrent
Yes, that I was asking my question about: what — in particular — did you find
that repulsing in F83?
Indeed these changes may be annoying for someone accustomed to earlier behaviour — but to the point of taking decision „enough of this! Switching to C”?
He said he left forth because it lacked the tools he expected. It took
another 10 years for Forth to have file functions. There's still no
standard way of obtaining command-line arguments.
Well, that's Forth — what is lacking, the user needs to add by himself.
It doesn't have to be standard. It just should be working.
It does have to be standard if that's the audience you're trying to attract.
Yes, that I was asking my question about: what — in particular — did you findTrue flag, DO-LOOP, SIGN are some Forth-79 things still in 4tH IIRC.
that repulsing in F83?
F83 I found abhorrent
Indeed these changes may be annoying for someone accustomed to earlier behaviour — but to the point of taking decision „enough of this! Switching to C”?Yes, that I was asking my question about: what — in particular — did you findTrue flag, DO-LOOP, SIGN are some Forth-79 things still in 4tH IIRC.
that repulsing in F83?
But probably the major reason was - I admit - Forth-79 was such a beautiful system for the ZX Spectrum.
The IBM was quite a different beast and Forth felt alien to it. So, in
short, Forth-83 was the straw that broke the camels back. Forth wasn't
suited for it and I hated programming in it.
It does have to be standard if that's the audience you're trying to attract.
Well said — "if"... ;)
But probably the major reason was - I admit - Forth-79 was such a beautifulJust completely off-topic: it reminds me, that somehow I didn't
system for the ZX Spectrum.
see any Forth-79 for PC. Maybe I missed some compiler? Not that
I'm going to use it for anything — but out of pure curiosity: was there any Forth-79 for PC created, that is still somewhere available for download?
P.S. From what I can see someone released new Forth-79 for Spectrum: https://www.sinclairzxworld.com/viewtopic.php?t=4238
MVP Forth by Glenn Hayden was Forth-79 or very close to it.
Barebones kernel that I used in 1981 or so only had floppy disk access to blocks.
I don't know if F83 ever ran on the PC but the CP/M version
looked impressive, based on Ting's book.
(4) SIGN. <# #> is already difficult, because you have to define it in reverse:
<# # # [CHAR] . HOLD #S #>
Now some smart @ss comes along and thinks, "Hey - this is a weird stack diagram.
Let's correct it and make it sheer impossible for people to write a number format".
So yes - I killed that one.
On 12/10/2022 4:12 am, Hans Bezemer wrote:Well, who am I to counter the master of number representations?
(4) SIGN. <# #> is already difficult, because you have to define it in reverse:The culprit is #> which assumes there will always be a number on TOS to drop. Handling it externally, ROT disappears:
<# # # [CHAR] . HOLD #S #>
Now some smart @ss comes along and thinks, "Hey - this is a weird stack diagram.
Let's correct it and make it sheer impossible for people to write a number format".
So yes - I killed that one.
TUCK DABS <# # # [CHAR] . HOLD #S 2DROP SIGN #>
Assuming the remaining number from #S (usually 0. ) is never needed (?), the 2DROP can be built-in:
TUCK DABS <# # # [CHAR] . HOLD #S SIGN #>
As I see it, '83 got SIGN right but failed to fix the real problem.
Hans Bezemer <the.bee...@gmail.com> writes:No, what I'm saying is that the Spectrum was basically a blob of memory,
The IBM was quite a different beast and Forth felt alien to it. So, in short, Forth-83 was the straw that broke the camels back. Forth wasn't suited for it and I hated programming in it.Are you saying the IBM would have felt less alien if it had run
Forth-79? The language differences you mention seem pretty minor. I sympathize about the system interface issues. Did F-PC deal with that
stuff ok? I don't know if F83 ever ran on the PC but the CP/M version
looked impressive, based on Ting's book. I never actually ran it
No, what I'm saying is that the Spectrum was basically a blob of memory, while the IBM was file oriented. On the Spec you manipulated blobs of memory. Files were blobs of memory, that were dumped or loaded in
their entirety. No such thing as reading line by line or writing to disk directly. It had to pass by memory first - and any file actions were
atomic - like blocks.
On Wednesday, October 12, 2022 at 8:10:48 AM UTC+2, dxforth wrote:
On 12/10/2022 4:12 am, Hans Bezemer wrote:Well, who am I to counter the master of number representations?
The culprit is #> which assumes there will always be a number on TOS to drop.
(4) SIGN. <# #> is already difficult, because you have to define it in reverse:
<# # # [CHAR] . HOLD #S #>
Now some smart @ss comes along and thinks, "Hey - this is a weird stack diagram.
Let's correct it and make it sheer impossible for people to write a number format".
So yes - I killed that one.
Handling it externally, ROT disappears:
TUCK DABS <# # # [CHAR] . HOLD #S 2DROP SIGN #>
Assuming the remaining number from #S (usually 0. ) is never needed (?), the >> 2DROP can be built-in:
TUCK DABS <# # # [CHAR] . HOLD #S SIGN #>
As I see it, '83 got SIGN right but failed to fix the real problem.
(And you can consider that to be a well deserved compliment).
I can only say Forth-79 was intuitive for me and simply worked for me.
No, what I'm saying is that the Spectrum was basically a blob of memory,
while the IBM was file oriented. On the Spec you manipulated blobs of
memory. Files were blobs of memory, that were dumped or loaded in
their entirety. No such thing as reading line by line or writing to disk
directly. It had to pass by memory first - and any file actions were
atomic - like blocks.
But — if I'm correct — it was just a matter of using CPM-ish functions 0Fh, 14h, 15h, 16h of DOS interrupt 21h. In general it would do about the same:
put the selected region of memory to mass storage (to disk(ette), in this particular case), in „chunks” — so not as single dump, but within a loop instead.
But that loop can be internal to word and not „visible on the outside”, anyway.
MVP Forth by Glenn Hayden was Forth-79 or very close to it.Yes, I like MVP Forth — in fact it's much better than „pure” F79. Glen Haydon
Barebones kernel that I used in 1981 or so only had floppy disk access to blocks.
created nice „crossover” of fig and F79 standards. And it's well documented.
I'm curious about F79, because somehow I haven't seen any Forth 79
for PC yet, but it seems unbelievable to me not a single one for PC existed?
This might be a stretch but HsForth by Jim Kalihan (which I still have)
is Forth 79 but with the Intel Segmented memory system extensions.
Jim had a library file that added Forth 83 functionality but out of the box DO/LOOP and VOCABULARY all worked per Forth 79.
F83 ran on the PC. As with CP/M version, it looked anemic
compared to what C and Pascal compilers of the day could do.
On Tuesday, October 11, 2022 at 9:57:45 PM UTC+2, Paul Rubin wrote:[...]
Hans Bezemer <the.bee...@gmail.com> writes:
The IBM was quite a different beast and Forth felt alien to it.
No, what I'm saying is that the Spectrum was basically a blob of memory, >while the IBM was file oriented. On the Spec you manipulated blobs of
memory. Files were blobs of memory, that were dumped or loaded in
their entirety. No such thing as reading line by line or writing to disk >directly. It had to pass by memory first - and any file actions were
atomic - like blocks.
That's what I'm saying. It's an environment that fits C like a glove - and >Forth less.
MS-DOS with it's CRLF newline files fits C quite badly, because CWell, I don't agree with you here. Admitted, alternative solutions are possible here.
requires '\n' to be one character. They had to introduce "text files" (automatic translation between MS-DOS representation on disk and C
files in memory) into C for MS-DOS, with lots of resulting problems.
The Forth-94 standard included the text vs. binary file nonsense, butI think files in Forth-94 are a very BAD C-imitation which stick out like a ugly, unForth-like kludge. Sure, if you really want to 4tH will support the wordset almost completely - but unless I want to make a portable or ported program I stay away from it as far as I can.
did not give us a newline character; as a result, you better don't
translate the newlines, and Forth-94's file words fit MS-DOS (and
Windows) much better than C does. But of course it was a decade after Forth-83.
Turbo Pascal generated .COM files at the time, which limited code,Yes - but it was a revolutionary concept. It dumped IIRC a 10K runtime
data and stack to 64KB each. It generated relatively naive native
code, so it looked a bit better than threaded code on speed
benchmarks, but you could put much less code in the 64KB available; so
they added overlays in 2.0 (which F83 had to an extent with FORGET).
Turbo Pascal had an IDE and could IIRC compile and run code without
having to go to disk. In many respects it had caught up with Forth.
C was by far not as popular as Pascal on the PC in 1984. (..)From my own experience I can only agree to that. I was an early TC user.
Turbo C was only introduced in 1987.
MS-DOS with it's CRLF newline files fits C quite badly, because C
requires '\n' to be one character. They had to introduce "text files" (automatic translation between MS-DOS representation on disk and C
files in memory) into C for MS-DOS, with lots of resulting problems.
The Forth-94 standard included the text vs. binary file nonsense, but
did not give us a newline character; as a result, you better don't
translate the newlines
This might be a stretch but HsForth by Jim Kalihan (which I still have)It was a stretch - but not for the same reasons I had, I think. We're talking mid-'80-ies. No Internet. No BBS-es (at least - not that popular at the time).
is Forth 79 but with the Intel Segmented memory system extensions.
Jim had a library file that added Forth 83 functionality but out of the box DO/LOOP and VOCABULARY all worked per Forth 79.
This might be a stretch but HsForth by Jim Kalihan (which I still have)
is Forth 79 but with the Intel Segmented memory system extensions.
Jim had a library file that added Forth 83 functionality but out of the box >> DO/LOOP and VOCABULARY all worked per Forth 79.
It wasn't free neither shareware, I'm afraid?
dxforth <dxforth@gmail.com> writes:
F83 ran on the PC. As with CP/M version, it looked anemic
compared to what C and Pascal compilers of the day could do.
Really? Which day would that be? If we take July 31, 1984, the date
on https://github.com/ForthHub/F83/blob/master/readme.1st, what was
the C and Pascal competition?
I think files in Forth-94 are a very BAD C-imitation which stick out like a ugly, unForth-like kludge.
If we take July 31, 1984, the date on https://github.com/ForthHub/F83/blob/master/readme.1st...
Turbo Pascal generated .COM files at the time, which limited code,
data and stack to 64KB each.
I think files in Forth-94 are a very BAD C-imitation which stick out like a >ugly, unForth-like kludge. Sure, if you really want to 4tH will support the >wordset almost completely - but unless I want to make a portable or ported >program I stay away from it as far as I can.
Hans Bezemer
No, what I'm saying is that the Spectrum was basically a blob of memory, while the IBM was file oriented.
MS-DOS with it's CRLF newline files fits C quite badly, because C
requires '\n' to be one character. They had to introduce "text files"
(automatic translation between MS-DOS representation on disk and C
files in memory) into C for MS-DOS, with lots of resulting problems.
The Forth-94 standard included the text vs. binary file nonsense, but
did not give us a newline character; as a result, you better don't
translate the newlines
I believe the solution like the one used in TCL would be better
(I mean „fconfigure $channel -translation auto / binary / cr / crlf / lf”) >https://www.tcl.tk/man/tcl8.4/TclCmd/fconfigure.html
There is a trap. Do not try to e.g. generate Apple or Windows textThis is exactly what I was talking about: TCL's „fconfigure -translation {inMode outMode}”
files on a Unix system. Generate native text files, and then convert
to another Operating System at hand while using proper transport procedures.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 42:22:54 |
| Calls: | 6,708 |
| Calls today: | 1 |
| Files: | 12,243 |
| Messages: | 5,353,932 |