On: raising the semantic level of a program

Overloading is always a problem in Forth. It is so easy to do that one sometimes loses the context. I was writing an assembler for my 4004 project. I wanted to overload words like IF THEN for cleaner to read assembly so I didn't have a lot of branch labels. I like indenting to show beginning and ends of program flow control. I don't like doing things like IFa and THENa or such to show the context. I still wanted to write my macros in Forth and not in assembly, so I made a word Macro: to replace : so that it would automatically keep the context straight. It is a crutch but sometimes a well placed crutch can solve such context problems. I now have my "CARRY IF ... THEN" in assembler and still can easily switch to Forth's "IF ... THEN" for making macro commands that need flow control and are for completely different context than the assembled code. Dwight ________________________________ From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Peter Corlett via cctalk <cctalk at classiccmp.org> Sent: Sunday, June 28, 2020 3:00 AM To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org> Subject: Re: On: raising the semantic level of a program On Sat, Jun 27, 2020 at 07:15:25PM -0600, ben via cctalk wrote: [...] What, auto-generated "documentation" which just lists function names and type signatures is not useful? This is news to pretty much every Java project I've had the misfortune of interacting with. That does of course depend on the strictness of the language's type system and whether the developer has exercised good taste and discretion when using operator overloading in their API. I would normally expect the compiler to reject attempts to add two incompatible types, but this is often a triumph of hope over experience. (But avoid PHP, JavaScript, and similar junk languages hacked together in a Coke-fuelled bender to solve the immediate problem, and you're 90% of the way there.) I'm unclear on what you're trying to say here. Source-to-source translators are of course a well-trodden path, such as early C++ "compilers" which emitted C. A weaker variant is to abuse operator overloading to create a minilanguage that is directly compilable without translation. Such corner-cutting techniques are useful for prototyping new ideas, but tend to cause more trouble than they are worth if used as-is in production. My day job currently involves PureScript, a Haskell-inspired language which is translated into JavaScript. It is quite an experience.