What forth systems you use?

[VoidVolker]

1. What forth systems do you use and for what OS?
2. What is your favourite forth system or systems?

My answers:

1. Windows: SP-Forth, Quark Forth Linux: gForth, SP-Forth linux OSX: nop Embedded: one time was Swift Forth
2. SPF, Quark, gForth. I think VFX Forth looks very useful. Have no time to try it :(

[RogerLevy]

We can make blocks a "standard option"

Personally I abandoned blocks a long time ago, files work OK but you can have blocks if you want very easily so it doesn't need to be a mandatory feature to be called a Forth imo

[DRuffer]

Are you going to discard coloForth from these discussions?

DaR

From: RogerLevy Sent: Wednesday, June 28, 2017 9:49 AM To: ForthHub/discussion Cc: Subscribed Subject: Re: [ForthHub/discussion] What forth systems you use? (#2)

We can make blocks a "standard option" Personally I abandoned blocks a long time ago, files work OK but you can have blocks if you want very easily so it doesn't need to be a mandatory feature to be called a Forth imo — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[AndreasKlimas]

We can make blocks a "standard option"

Personally I abandoned blocks a long time ago, files work OK but you can have blocks if you want very easily so it doesn’t need to be a mandatory feature to be called a Forth imo

persistence doesn’t mean files only. I’m using shared memory, distributed shared memory, memory mapped files and SQL storage, all behind the word block. Maybe this is not a good design and things should be named what they are. Anyway, Forth without some kind of storage seems useless to me and hence I probably would add persistence instead of block.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ForthHub/discussion/issues/2#issuecomment-311719985, or mute the thread https://github.com/notifications/unsubscribe-auth/ARuwIxMnqN5cNVogi5-rKPrjyKmjUHIWks5sIoQVgaJpZM4DnBNs.

[ChristerNilsson]

RogerLevy, I think Forth and Factor are in the same family, concatenative languages. http://concatenative.org/wiki/view/Concatenative%20language Factor brings Forth from microcontrollers to the mainframes and desktops. I'm impressed over it's huge functionality.

[MitchBradley]

The easy way to resolve this "issue" is as follows:

• To be ANS Forth, it has to conform to the list of requirements in the ANS Forth standard
• If the name of the system includes "forth", it is very likely to be recognizable as Forth
• There are many interesting languages with similarities to Forth, such as visible stacks and RPN flavor. By and large, those languages have different names, but often, in their descriptions, mention similarities to or influence by Forth.

In my experience, language authors have always gotten the naming right. When it strays too far from Forth, they have changed the name.

[RogerLevy]

@DRuffer no, why? @AndreasKlimas that sounds totally reasonable @ChristerNilsson it's not Forth ... I tried it out for a number of weeks, expecting an easy transition. in the concatenative family of course. but Postscript isn't Forth either @MitchBradley that's my attitude as well and i also think devs have done a good job of responsible naming. it definitely makes categorizing easier.

[larsbrinkhoff]

@RogerLevy, I wrote "for the purposes of this group", by which I mean that it's probably not a problem to leave the interpretation of "Forth" open to each individual. As pertaining to interacting with this group.

[DRuffer]

Are you going to discard coloForth from these discussions? ➢ @DRuffer no, why?

Because it fits some of your objections to compatibility (e.g. blocks and portability).

DaR

From: RogerLevy Sent: Wednesday, June 28, 2017 10:38 AM To: ForthHub/discussion Cc: Dennis Ruffer; Mention Subject: Re: [ForthHub/discussion] What forth systems you use? (#2)

@DRuffer no, why? @AndreasKlimas that sounds totally reasonable @ChristerNilsson it's not Forth ... I tried it out for a number of weeks, expecting an easy transition. in the concatenative family of course. but Postscript isn't Forth either @ MitchBradley that's my attitude as well and i also think devs have done a good job of responsible naming. it definitely makes categorizing easier. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[RogerLevy]

@DRuffer Well, blocks in colorforth don't even work the same way as classic blocks, so I don't see how it even holds up as an example of compatibility. True direct portability is a pipe dream, the conventional concept of it is irrelevant to Forth, when everything is so easy to add yourself. If you're going to have to potentially modify your app to port it to colorforth (and who is doing that anyway? but for arguments sake) and blocks are so easy to implement the way you want it i don't see a need for there to be blocks in every Forth for it to be called a Forth - which is a separate issue from compatibility, which I'm definitely not qualified to or interested in figuring out. (and anyway I think it's largely a lost cause in the pure sense of the word and we'll only ever have something "good enough" for Forth)

[RogerLevy]

@DRuffer and btw, I feel that issues of compatibility in Forth are largely a function of its lack of a namespacing system. Once it has an agreed-upon one, what flavor of block system you use won't matter anymore and it won't matter if a system has it out-of-the-box or not.

[GarthWilson]

RogerLevy wrote,

we can have at least a simple, loose definition - 2 stacks, dictionary, colon definitions - personally I'd also add that it should be typeless, have cells, and be interactive

I would add: RPN, consistent stack cell size, stacks are visible to the programmer, has "the pearl of Forth," ie, CREATE, DOES>, and related words, which enable the programmer to make new kinds of defining words and to specify their compile-time behavior and run-time behavior separately, although not every program needs to use these.

About storage, blocks, etc.: My workbench computer does not have a file or block system. I edit the source code on the PC in MultiEdit in order to have the big keyboard and full screen and file storage, and "print" (or so the PC thinks) marked blocks of text over RS-232 to the workbench computer which interprets, assembles, or compiles, as appropriate, on the fly, as little as a word at a time or as much as many pages or an entire file at a time, sometimes while doing something else at the same time. This is done without any special software on the host PC, and without leaving or suspending the editor (since it just thinks it's printing a block to an old-fashioned RS-232 printer). Any computer that can print blocks of plain text from a text editor to RS-232 could act as the host in this way. It doesn't have to be a PC or use any particular OS. The workbench computer just thinks you're typing at an RS-232 keyboard (one that sends out ASCII, not keycodes), and that you're a lightning-fast typist who never makes any mistakes; but actually the source code is coming from the PC. I set this system up when doing some automated test equipment at work in 1990. (See http://6502.org/users/garth/projects.php?project=6) The final programs were in ROM; but I worked on new portions interactively, letting the SBC do its own compilation in RAM this way. Every so often, after accumulating a fair amount of new working code, I ran the metacompiler again to transfer the new code to EPROM. A couple of years later I designed a product that ran Forth but code was again in ROM; so neither of these had a file or block system.

I had to use blocks for a short time in about 1999 but I hated it. They have a few good points but these are generally greatly outweighed by their disadvantages.

[rdrop-exit]

Blocks aren't necessarily about persistence, Chuck switched to the equivalent of : block 1024 * ;.

[rdrop-exit]

I think Forth and Factor are in the same family, concatenative languages. http://concatenative.org/wiki/view/Concatenative%20language

Since Forth pre-dates that denominative by decades, I prefer to think of Factor as part of the family of Forth-like languages.

[AndreasKlimas]

Garth, thank you very much for the insight you gave.

I had to use blocks for a short time in about 1999 but I hated it. They have a few good points but these are generally greatly outweighed by their disadvantages.

do you want to share some of those disadvantages, I am relative new to Forth and missing some experience.

thank you

[GarthWilson]

@AndreasKlimas, that experience was close to 30 years ago. As I remember, an advantage of the blocks was that one or another could tell the Forth system to load a particular block, or range of blocks, based on a condition for example. But if you had to insert a block, the numbers of the blocks after it would get bumped up, so they no longer had their original block numbers. For example what had been block 61 would become 62; so if you say 61 LOAD, now you'd get the one before the one you intended. I can imagine ways to remedy that only to a limited extent. In a text file, I envision a way to get the capability of loading various sections by using labels that would be searched for, so you could say for example, "Is true? If so, load from to ." What you can do with text files is have several different ones and optionally INCLude or or another, meaning pull them in at that point, like calling them for compilation.

I did not like that the lines were only 64 characters long. Even with shadow screens, that only made for 128 characters, and with an immovable barrier in the middle. I got more than that (132) on my monitor with the1990's MultiEdit text editor running under DOS. Yes, DOS could do more than 80 columns. I usually kept it set to 132x43, and occasionally 132x60, as much as approximately a triad of screens plus their shadow screens, viewable simultaneously; but I could tile and window it any way I wanted. Sometimes I had as many as 35 files open at once, and the editor was point-and-click, drag-and-drop, etc..

I also didn't like the blocks being only 16 lines each. If I'd change my mind and needed to add more material in the middle than would fit without losing lines off the bottom, it was a mess to fix.

The professional programmers' text editor was just far more flexible. But I can see why, back in the day of very limited resources, it made sense to keep to the simple block disc interface. I sometimes wondered how it would be if blocks were 4K each, 128 columns by 32 lines.

[AndreasKlimas]

Garth, thank you for sharing your experience with source blocks. Maybe this is the wrong place for this discussion, so I apologize.

I’m using blocks for persistence data storage. What is needed is any kind of (simple) block management. I think using blocks is in the spirit of simplicity.

Andreas Klimas

Am 29.06.2017 um 09:43 schrieb Garth Wilson notifications@github.com:

@AndreasKlimas https://github.com/andreasklimas, that experience was close to 30 years ago. As I remember, an advantage of the blocks was that one or another could tell the Forth system to load a particular block, or range of blocks, based on a condition for example. But if you had to insert a block, the numbers of the blocks after it would get bumped up, so they no longer had their original block numbers. For example what had been block 61 would become 62; so if you say 61 LOAD, now you'd get the one before the one you intended. I can imagine ways to remedy that only to a limited extent. In a text file, I envision a way to get the capability of loading various sections by using labels that would be searched for, so you could say for example, "Is true? If so, load from to ."

I did not like that the lines were only 64 characters long. Even with shadow screens, that only made for 128 characters, and with an immovable barrier in the middle. I got more than that (132) on my monitor with the1990's MultiEdit text editor running under DOS. Yes, DOS could do more than 80 columns. I usually kept it set to 132x43, and occasionally 132x60, as much as approximately a triad of screens plus their shadow screens, viewable simultaneously; but I could tile and window it any way I wanted. Sometimes I had as many as 35 files open at once, and the editor was point-and-click, drag-and-drop, etc..

I also didn't like the blocks being only 16 lines each. If I'd change my mind and needed to add more material in the middle than would fit without losing lines off the bottom, it was a mess to fix.

The professional programmers' text editor was just far more flexible. But I can see why, back in the day of very limited resources, it made sense to keep to the simple block disc interface. I sometimes wondered how it would be if blocks were 4K each, 128 columns by 32 lines.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ForthHub/discussion/issues/2#issuecomment-311888502, or mute the thread https://github.com/notifications/unsubscribe-auth/ARuwI6W77zrk6_Xh8NgoxMVEfOQtXXU7ks5sI1WKgaJpZM4DnBNs.

[RogerLevy]

@AndreasKlimas True, but simplicity is an idea, and blocks are just a manifestation. They have their limitations. There was a time when they were considered all you'd need, but it's been a long time since then and computers are a lot bigger and faster.

For reasons of speed and utility my old Gamecube Forth fetched blocks on demand from disk in 64kb aligned chunks. If you read from block 0 after initial load you could assume blocks 1-63 were in memory, ColorForth style.

[MitchBradley]

One should distinguish between blocks and screens. Blocks are a form of software-managed virtual memory, while screens are a way of storing source code in blocks.

I personally disliked screens intensely, for all of the reasons below and more. They were sort of barely justifiable in the very early days of Forth when you only had a few K of memory and maybe an 80Kbyte 8-inch floppy disk, but it did not take long before being forced into a sequential numerical "name space" for source objects seemed pretty silly. And the 16x64 lines thing was famous for causing comments, indentation, and phrasing to disappear as you ran out of space.

I found very few uses for blocks as virtual storage over my career. The only use of block in any of my "keeper" code is inside a file system driver, where I use it to manage a write-back cache of disk blocks containing index information.

I know some good programmers who really like blocks, but they never really did that much for me.

On 6/29/2017 11:11 AM, Andreas Klimas wrote:

Garth, thank you for sharing your experience with source blocks. Maybe this is the wrong place for this discussion, so I apologize.

I’m using blocks for persistence data storage. What is needed is any kind of (simple) block management. I think using blocks is in the spirit of simplicity.

Andreas Klimas

Am 29.06.2017 um 09:43 schrieb Garth Wilson notifications@github.com:

@AndreasKlimas https://github.com/andreasklimas, that experience was close to 30 years ago. As I remember, an advantage of the blocks was that one or another could tell the Forth system to load a particular block, or range of blocks, based on a condition for example. But if you had to insert a block, the numbers of the blocks after it would get bumped up, so they no longer had their original block numbers. For example what had been block 61 would become 62; so if you say 61 LOAD, now you'd get the one before the one you intended. I can imagine ways to remedy that only to a limited extent. In a text file, I envision a way to get the capability of loading various sections by using labels that would be searched for, so you could say for example, "Is true? If so, load from to ."

I did not like that the lines were only 64 characters long. Even with shadow screens, that only made for 128 characters, and with an immovable barrier in the middle. I got more than that (132) on my monitor with the1990's MultiEdit text editor running under DOS. Yes, DOS could do more than 80 columns. I usually kept it set to 132x43, and occasionally 132x60, as much as approximately a triad of screens plus their shadow screens, viewable simultaneously; but I could tile and window it any way I wanted. Sometimes I had as many as 35 files open at once, and the editor was point-and-click, drag-and-drop, etc..

I also didn't like the blocks being only 16 lines each. If I'd change my mind and needed to add more material in the middle than would fit without losing lines off the bottom, it was a mess to fix.

The professional programmers' text editor was just far more flexible. But I can see why, back in the day of very limited resources, it made sense to keep to the simple block disc interface. I sometimes wondered how it would be if blocks were 4K each, 128 columns by 32 lines.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ForthHub/discussion/issues/2#issuecomment-311888502, or mute the thread https://github.com/notifications/unsubscribe-auth/ARuwI6W77zrk6_Xh8NgoxMVEfOQtXXU7ks5sI1WKgaJpZM4DnBNs.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ForthHub/discussion/issues/2#issuecomment-312109821, or mute the thread https://github.com/notifications/unsubscribe-auth/AEoszYkxGbrOsfF99YCfpCMV6drJm5HDks5sJBMOgaJpZM4DnBNs.

[Lecrapouille]

What about macFORTH ? Nobody :) http://bitsavers.informatik.uni-stuttgart.de/pdf/creativeSolutions/MacFORTH_1.2_Oct84.pdf

[MitchBradley]

MacFORTH was very influential in the '80s, and its author, Don Colburn, was a highly respected member of the Forth community. Those of us who knew him miss him very much. He spoke, showing his multi-tasking 68000 Forth, at the very first FIG meeting that I ever attended. Here is a thread of reminiscences from his passing:

https://groups.google.com/forum/#!topic/comp.lang.forth/Y1db1tdl68Q

On 6/29/2017 1:57 PM, Lecrapouille wrote:

What about macFORTH ? Nobody :) http://bitsavers.informatik.uni-stuttgart.de/pdf/creativeSolutions/MacFORTH_1.2_Oct84.pdf

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ForthHub/discussion/issues/2#issuecomment-312138622, or mute the thread https://github.com/notifications/unsubscribe-auth/AEoszVvX-1vIbO6iNuEl6fWYqIDLYi_Kks5sJDnYgaJpZM4DnBNs.

[MitchBradley]

Don was very witty. Here is a story he told me (and Mike Perry) firsthand, over hot wings and beer at a Rochester Forth conference: A MacForth customer called with a problem. Don's solution was as follows: Don instructed the customer to remove the battery from the Mac, hold it in his right hand, and follow Don in reciting a particular verse from the Bhagavad Gita. Upon subsequently replacing the battery, the system worked again.

The solution, of course, depended on leaving the battery out long enough for the "PRAM" parameter storage RAM to discharge, thus restoring factory default configuration settings. The recitation was just to kill time with a magical flavor.

On 6/29/2017 8:31 PM, Mitch Bradley wrote:

MacFORTH was very influential in the '80s, and its author, Don Colburn, was a highly respected member of the Forth community. Those of us who knew him miss him very much. He spoke, showing his multi-tasking 68000 Forth, at the very first FIG meeting that I ever attended. Here is a thread of reminiscences from his passing:

https://groups.google.com/forum/#!topic/comp.lang.forth/Y1db1tdl68Q

On 6/29/2017 1:57 PM, Lecrapouille wrote:

What about macFORTH ? Nobody :) http://bitsavers.informatik.uni-stuttgart.de/pdf/creativeSolutions/MacFORTH_1.2_Oct84.pdf

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ForthHub/discussion/issues/2#issuecomment-312138622, or mute the thread https://github.com/notifications/unsubscribe-auth/AEoszVvX-1vIbO6iNuEl6fWYqIDLYi_Kks5sJDnYgaJpZM4DnBNs.

[RigTig]

My first Forth was on a VIM-1 board (got renamed to SYM-1); a Rockwell 6502. I hand keyed 8K of Intel hex code twice (once to key in, second one to verify). But it needed disk and I could not afford one, so I buffered 8 blocks in another 8K and wrote a driver to read/write 1K blocks to a cassette tape. Manually controlled tape movement!! Fun, fun, fun!! The blocks were just a simple unit of storage. Of course, they were numbered and called screens for source code. Oh yes, my display was a modified TV and anything more than 64 characters across was too fast for the video bandwidth. So many of the 'standards' were just practical limitations and/or convenient choices based upon the technology available at the time. They worked at the time, but that doesn't mean they ought to be kept. That said, sometimes revisiting the quaint old ways is still fun.

[GarthWilson]

@RigTig I used a 65c02 (CMOS, more instructions and addressing modes than NMOS) in some automated test equipment in about 1990 at work. It worked out very well. See it at http://6502.org/users/garth/projects.php?project=6 . I mentioned it further up but did not give the link. If you wander around that section of the site, I should comment that the page on my 65c02 workbench computer on which I use Forth there is quite outdated. I have github access to that site, but those oldest pages are not on it. Making additions and edits took too long there, so I started my own 6502-oriented site, http://wilsonminesco.com/, with loads of articles and information. One of the major features is the stacks treatise, at http://wilsonminesco.com/stacks/, which has 19 chapters plus appendices. While Forth is mentioned quite a few times, several chapters are about doing things in assembly in a very Forth-like way.

BTW, the 65xx family has come a long way since the SYM-1, although not as far as the x86. All the off-the-shelf ones being made today are guaranteed for at least 14MHz and usually top out at about twice that (if the supporting parts can keep up, since it's only a slight exaggeration to say a read happens in basically half a cycle which is 20ns @ 25MHz, including time for glue logic), and the fastest ones are running over 200MHz (but in ASICs). The '02 is still selling in volumes over a hundred million (100,000,000) per year, but you don't see them because they're hidden as the processor at the heart of ASICs embedded in automotive, industrial, appliance, toy, and even life-support equipment. The 65816 is the 16-bit upgrade, with more instructions and addressing modes than the 65c02, and is more suitable for multitasking, multithreading, relocatable code, and compilation of higher-level languages. My 65816 Forth runs approximately 2.5 times as fast as my 65c02 Forth at a given clock speed.

[RigTig]

My current projects include working with a Forth on STM8 (by Thomas, https://github.com/TG9541/stm8ef). STM8eForth is derived from Dr. Ting's eForth. It is fun to squeeze out of a 8-bit CPU such magical things as a GCODE interpreter for a 3D printer, and multilateration (see https://en.wikipedia.org/wiki/Multilateration#Solution_with_limited_computational_resources). Someone said I needed a bigger CPU, but they haven't any idea of how much punch you can get with a well-crafted Forth solution. I've temporarily digressed into the internal implementation of the Forth and the debug module of the STM8, but that is because it is interesting and fun. I look at Forth as a toolbox; some tools get used often and others far less so. I am only a hobbyist, but I still surprise some much younger developers with what can be done.

[GarthWilson]

@RigTig I should have commented earlier— If you still have any interest in the '02, join us on the 6502.org forum at http://forum.6502.org/ . There's a section of the forum dedicated to discussions of various Forth models on the 6502, 65816, and related microprocessors and microcontrollers. The distinguished Dr. Brad Rodriguez, author of CamelForth and somewhat of a giant in the field of Forth, is on there.

[hcchengithub]

I use jeforth for all small things like to remind me something at a time, to try Microsoft AI services, or simply as a calculator to do some maths. It works on HTA, Node.js, NW.js on Windows 10 or web browsers : http://cdn.rawgit.com/hcchengithub/jeforth.3we/r2/index.html?cr%20.%22%20Show%20%27Hello%20ForthHub!%27%20through%20HTML%22%20cr%20%3Co%3E%20%3Ch1%3EHello%20ForthHub!!%3C/h1%3E%3C/o%3E

On Mon, Jul 3, 2017 at 5:04 PM, Garth Wilson notifications@github.com wrote:

@RigTig https://github.com/rigtig I should have commented earlier— If you still have any interest in the '02, join us on the 6502.org forum at http://forum.6502.org/ . There's a section of the forum dedicated to discussions of various Forth models on the 6502, 65816, and related microprocessors and microcontrollers. The distinguished Dr. Brad Rodriguez, author of CamelForth and somewhat of a giant in the field of Forth, is on there.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ForthHub/discussion/issues/2#issuecomment-312590836, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPKd3h_Km67UQEBozSTNQs4vvlzE7GMks5sKK6qgaJpZM4DnBNs .

-- Just undo it! 陳厚成 H.C. Chen Nothing real can be threatened. Nothing unreal exists. Herein lies the peace of God. JavaScript Forth http://github.com/hcchengithub/jeforth.3we

[AndreasKlimas]

Am 03.07.2017 um 13:43 schrieb H.C. Chen notifications@github.com:

I use jeforth for all small things like to remind me something at a time, to try Microsoft AI services, or simply as a calculator to do some maths. It works on HTA, Node.js, NW.js on Windows 10 or web browsers : http://cdn.rawgit.com/hcchengithub/jeforth.3we/r2/index.html?cr%20.%22%20Show%20%27Hello%20ForthHub!%27%20through%20HTML%22%20cr%20%3Co%3E%20%3Ch1%3EHello%20ForthHub!!%3C/h1%3E%3C/o%3E http://cdn.rawgit.com/hcchengithub/jeforth.3we/r2/index.html?cr%20.%22%20Show%20%27Hello%20ForthHub!%27%20through%20HTML%22%20cr%20%3Co%3E%20%3Ch1%3EHello%20ForthHub!!%3C/h1%3E%3C/o%3E

this looks very promising. I’m a big fan of Forth. Unlike most Forth-developers I’m absolutely not in the business of embedded systems. Because of simplicity of Forth I would like to make a smooth switch from C to Forth but don’t know which Forth I should use. HTML5 and ajax is my daily work and I’m running many servers on Linux. I have played with SwiftForth (and I like it :-) but unfortunately SF is 32 Bits only and for some applications my memory mapped database already has reached 2.5G.

Are there other Forthers around here which are not working in the area of embedded computing (and using Forth for their work :-)

Best Wisches Andreas Klimas

On Mon, Jul 3, 2017 at 5:04 PM, Garth Wilson notifications@github.com wrote:

@RigTig https://github.com/rigtig I should have commented earlier— If you still have any interest in the '02, join us on the 6502.org forum at http://forum.6502.org/ . There's a section of the forum dedicated to discussions of various Forth models on the 6502, 65816, and related microprocessors and microcontrollers. The distinguished Dr. Brad Rodriguez, author of CamelForth and somewhat of a giant in the field of Forth, is on there.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ForthHub/discussion/issues/2#issuecomment-312590836, or mute the thread https://github.com/notifications/unsubscribe-auth/ABPKd3h_Km67UQEBozSTNQs4vvlzE7GMks5sKK6qgaJpZM4DnBNs .

-- Just undo it! 陳厚成 H.C. Chen Nothing real can be threatened. Nothing unreal exists. Herein lies the peace of God. JavaScript Forth http://github.com/hcchengithub/jeforth.3we — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ForthHub/discussion/issues/2#issuecomment-312624277, or mute the thread https://github.com/notifications/unsubscribe-auth/ARuwI6LJtrfr4kC2SSFuSBzh6S1j-midks5sKNPogaJpZM4DnBNs.

[hcchengithub]

@AndreasKlimas welcome to join us with jeforth where j is JavaScript so it should work anywhere JS is available. Its kernel is 'project-k' @ https://github.com/hcchengithub/project-k , a tiny forth VM with only two words, code and end-code, so 'code Hi console.log("hello world!!") end-code' generates your 3'nd word based on project-k kernel.

[RigTig]

@GarthWilson: thanks for links. Not using 6502s right now, but good to know where to touch base. I am enjoying the challenge of the 8-bit STM8 for the time being. And I have recently used punyforth on esp8266 too.

[gordonjcp]

I've been using Forth on a 6809-based system for a while now, having adapted Dave Dunfield's Forth for his homebrew machine to the Ensoniq Mirage, a 1980s sampler. This has allowed me to poke at the hardware and build some diagnostic tools to help repair them, as well as making some very peculiar noises.

[wejgaard]

@MitchBradley Thanks for making "blocks versus screens" clear. Thirty years ago I learned to like blocks and screens with a simple constraint: One word definition per screen. IOW, dedicate a whole block to each word in the dictionary. - Suddenly you have ample space for both definition and a good comment. And there is more. You can easily implement hypertext links in the screen editor, and add "structure headers" to the dictionary (with blocks for text) to present the words in a Smalltalk-like browser. You get new options for handling cross-development, e.g. selective loading (only words that are actually used), or single stepping the target code through the source text in the screen. Ex. www.holonforth.com/using.html.

[rdrop-exit]

@wejgaard Kudos for taking the block/screen concept so far. How does Holonforth's 1 screen = 1 word definition approach deal with any interpreted Forth source interspersed between the word definitions?

[wejgaard]

@rdrop-exit Thanks - Usually, the units contain word definitions, and the name of the unit is also (made) the name of the word. But a unit can have any source chunk to interpret immediately and then gets a describing name. The chunk is loaded between the adjacent units. - For the full story (initial version 1989) see www.holonforth.com/ef89.html. Experience it in Holon86 or -11. Note: In Holonforth the editor creates the dictionary, the structure is permanent, the compiler merely inserts code addresses.

[rdrop-exit]

@wejgaard Thanks for the explanation, very interesting approach.