A sensible macro engine

[GARTHWILSON]

Getting away from parentheses was part of what made me so happy with Forth when I found it 25 years ago that I never wanted to pick up another language again (contrasting to before that, when I wanted to collect all the major languages I could that were related to my technical interests). I know some find Forth's stack orientation to be hard to grasp and I've seen where some people (David Wheeler comes to mind) say that people just don't think in RPN. Well, I do; but it's apparently more than just a matter of computer languages, as the Korean language is apparently RPN, and native Korean speakers pick up on Forth very quickly, and I wish English were more RPN.

The writer of the article says the Lisp proponents would say to him, "Lisp allows for creation of mini-languages specific to the problem at hand, Lisp blurs the distinction between run time and compile time, Lisp, Lisp, Lisp..." which are parts of what I like about Forth. I have an HP-50g calculator which uses RPL, or Reverse-Polish Lisp, but I never learned it. Someone gave it to me, and I found that it was going to take a huge investment in learning time before I'd be able to use it anywhere near as well as I can the other HPs I have whose power has been multiplied by third-party software add-ons. The manual that came with the 50g is terrible; but I know there's a much better 500-page one available online. RPL allows putting entire programs on the stack which seems just a tad strange to me.

At viewtopic.php?f=9&t=521&p=3271#p3271, our own Samuel Falvo, professional programmer, starts his post with,

Quote:

Every programmer should learn three kinds of languages MINIMUM: Forth, Lisp, and most any Algol-derived language, including C, and most definitely Oberon in my opinion. Every time you learn a new language, you get new tools in your coding toolbox that can be used to help you solve a problem. This is true even if you never end up using two of the three languages again. But one thing that can rub off on you isn't the specific mechanics of the language, but rather, a specific philosophy.

He continues with other praise items for both, at viewtopic.php?f=1&t=39&p=264#p264, in the topic "A 65C02-based PC".

Although judging from the Lisp discussion Ed linked to (http://www.defmacro.org/ramblings/lisp.html) I won't be learning much about Lisp in an hour or even a month this reply, I will be watching with interest. It's always nice when another light comes on. As you may know by now, my structure macros are heavily stack-dependent, and I wrote them in a very Forth-like way.

[Tor]

I have no problems with RPN and stacks, and the first time I tried a HP calculator (started with TI) I was hooked.
But I can't do anything useful with Forth. It's not really the stack, and definetly not the RPN, it's just that I can't fnd a way to use Forth to solve the issues I solve with other languages. I'm starting to believe those who say that the trick to Forth programming is to carefully select programming problems that are a good match for Forth, and ignore everything else.

-Tor

[GARTHWILSON]

Although I thought Forth was great, I initially thought there was no way to do certain things in it. As I gained experience, I found that not only was there a way, it was a super elegant way—it's just that it didn't initially meet the eye. There are tons of those.

[BigDumbDinosaur]

Tor wrote:

But I can't do anything useful with Forth.

I can visualize solutions in assembly language, in ANSI C and in BASIC (the timesharing version implemented in Linux and UNIX, not the Microsoft dialect used in Commodore 64s et al). I can't visualize solutions for anything in Forth. That statement isn't a condemnation of the Forth environment, as it's patent that some programmers can get things done in Forth. The problem is that I don't think like a machine, and that is what using Forth demands of the programmer. I understand RPN but find it incompatible with my problem-solving methods.

So, like Tor, I can't do anything useful with Forth.

[BigEd]

Both Forth and Lisp are said to change the way you think about programming - that's perhaps both a blessing and a curse. But it may explain why it's difficult to just sit down and start using them.

[GARTHWILSON]

I haven't heard if this is true of Lisp, but Forth is said to be a "programmer amplifier;" it makes good programmers better, and bad ones worse!

[Tor]

That article at http://www.defmacro.org/ramblings/lisp.html is interesting, thanks for posting! Lisp is also one of those languages that I've always wanted to know more about, but over the years the only Lisp I have used is Emacs Lisp, it's necessary to fiddle a bit with that if you want to change or add to Emacs. But that's all. That article takes an approach I haven't seen before for Lisp, and (I have only just started reading) it seems to make infinite sense. Comparing with XML and similar notations is a good idea - I know XML and I'm used to (after having written parsers for similar concepts) keep those kind of trees and nodes in my mind. I'll read the rest of the article with interest. So far this claim by the article seems to hold up: "Lisp is executable XML with a friendlier syntax."

[BigEd]

I've just been trawling for snippets of enlightenment. Without pasting them, I think perhaps I can say this
- Forth is a language which lets you write a language to solve your problem
- Lisp is a language which lets you rewrite your problem into a language

Which is to say, in Forth you proceed by defining words and then using them. In Lisp you can act on program as data - your program can write the program you need. I've read the opinion that you need a sufficiently complex problem to make this worthwhile and to see the value in it.

Paul Graham lists nine interesting properties of Lisp, and notes that in the beginning when it was competing with Fortran for mindshare, they were all novel and unique. Now, with the latest versions of modern languages, only one or two points are still unique to Lisp:

Quote:

9. The whole language always available. There is no real distinction between read-time, compile-time, and runtime. You can compile or run code while reading, read or run code while compiling, and read or compile code at runtime.

Running code at read-time lets users reprogram Lisp's syntax; running code at compile-time is the basis of macros; compiling at runtime is the basis of Lisp's use as an extension language in programs like Emacs; and reading at runtime enables programs to communicate using s-expressions, an idea recently reinvented as XML.

Here's a worked example, slightly contrived. (I've read that one should use the indentation convention appropriate for the language: you see here how the parentheses are placed to become mostly invisible and indentation is used to show structure.)

[White Flame]

GARTHWILSON wrote:

That should be quite a contrast, since Lisp has apparently even a lot more parentheses than BASIC, whereas Forth uses non except to comment-out portions of a line and still allow what's after the ")" to be seen.

Lisp ONLY has parenthesis, whereas other languages have semicolons, commas, colons, square brackets, braces, etc generally in the same quantity, or even greater when it comes to commas. I know in writing JavaScript, many lines end in messes such as );}))]; whereas in Lisp that would just be ))))))) which is much easier to close after writing a nested line. Consider the punctuation difference between [1, 2, 3] and (1 2 3). The latter is simpler punctuation-wise, and easier to parse. There's a little bit of helper syntax in Lisp that is implemented in character macros but not much, and it's all prefix.

Forth is interesting in that its punctuators are just regular symbols (colon, etc), and therefore need to be space delimited. Whereas (1 2 3) is readable syntax in Lisp (because declared punctuating characters such as parens self-delimit), to implement the same syntax in Forth would most straightforwardly be ( 1 2 3 ). The character reader in Lisp is also a first-class object whose behavior can be modified, so that the entire syntax can be changed to support foreign code or DSLs.

I've said in postings elsewhere that if you're into the fundamentals of programming and compilers, the two languages you absolutely should know are Lisp (as an unbounded, fundamental, simple AST system) and Forth (as an unbounded, fundamental, simple expression evaluation mechanism).

[scotws]

So obviously what we need to do is write a Lisp interpreter in Forth for the 65816 .

[barrym95838]

@White Flame: Wow, that's the first time I've seen you pay Forth a compliment, at least in this forum!

@scotws: Awesome plan! I nominate ... you!

Mike B.

[KC9UDX]

GARTHWILSON wrote:

RPL allows putting entire programs on the stack which seems just a tad strange to me.

RPL requires you to put your entire program on one 'line' of the stack (which is very alarming). Upon execution, it is dropped from the stack. Of course, prior to execution, it is very simple to store or replicate the program.

I found it to be elegant in theory, but so-so in practise. It reminds me of the Dvorak keyboard. If all keyboards were Dvorak, we'd all be much happier. But, so long as one must use QWERTY keyboards, Dvorak is not worth learning.

[White Flame]

barrym95838 wrote:

@White Flame: Wow, that's the first time I've seen you pay Forth a compliment, at least in this forum!

I'm certainly not anti-Forth. I just think that higher level language abstractions are much easier constructed in higher level languages. Forth is great at the low level.