On: raising the semantic level of a program

[dwight]

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:
[...]
> At what point do variable names end being comments? There needs to be more
> work on proper documenting and writing programs and modules.

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.

> I am not a fan of objects and operator overloading because I never know just
> what the program is doing. apples + oranges gives me what ? count of fruits,
> liters of fruit punch, a error?

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.)

> It would be nice if one could define a new language for problem solving and
> run it through compiler-compiler processor for interesting problems.

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.