> Mark W. Humphries wrote:

>> On Mar 13, 9:07 pm, John Doty whispertel.LoseTheH.net> wrote:

>>> Mark W. Humphries wrote:

>>>> This is getting old. Why don't you just put together a list of
>>>> ==explicit requirements== for your desired language and see if it
>>>> generates interest, instead of incessantly repeating the same
>>>> question?

>>> I did.

>>> 1. Interactive.
>>> 2. Based on the iron.
>>> 3. Acceptable to ordinary users.

>> Do you intend it to be a fully extensible language like Forth,

> Well, first of all, I have no clear vision of how these requirements
> should flow down into a concrete design. If I really had that, I'd be
> building it. Who really knows what will work? A lot of very bright
> people worked on a lot of extended Algols before C finally came along.

> So, the rest of this is guesses as to what might work.

>> Would
>> development follow the Forth approach of extending the language until
>> an application specific vocabulary is achieved?

> Well, I think the history of scientific and mathematical notation shows
> that more discipline is needed. Successful notational extensions have
> primarily come about by generalizing the symbols, but keeping the
> grammar ("overloading"). Occasionally one needs to go farther, but there
> is no need to torture the language to make it easy to do so.

>> Would it follow a two stack model?

> At the very least, stacks should be less visible. They're an
> implementation concept, not a language concept.

>> RPN?

> Users' discretion at edit time. Reversible automatic translation between
> RPN and infix. Mathematica is a fine example of how a readable
> traditional notation can coexist with a more powerful and flexible (but
> less readable) fundamental notation.
>
> But make it *real* RPN: discipline or eliminate the "stack gymnastics"
> words. Don't just pretend to have RPN.

>> How far from Forth are you willing to go to cater to the masses?

> I prefer to think of it as catering to the genius who isn't a Forth
> programmer.

> Yesterday at breakfast, at the Cutthroat Cafe in Bailey, Colorado, I
> found myself sitting next to an industrial physical chemist. He was
> asserting that although there were too many incompatible programming
> languages, the nice thing is that they are similar enough that you can
> usually read the code in any of them, even if you don't know the
> language. Now, obviously, he'd never encountered Forth (or Lisp, APL, ...).
>
> For him this was a good thing. But Forth is cut off from such users by
> being willfully different. And it seems to me that a physical chemist
> working in a lab full of equipment operated by microcontrollers is a
> serious potential user of something like Forth.
>
> From the implementation perspective, syntax is a relatively trivial
> part of the language. What really distinguishes different programming
> systems is the underlying foundation. But from a human perspective,
> syntax makes a big difference.

>>>> It would help to understand if what you desire is Forth-
>>>> related enough to be of interest to clf. If it ends up being more like
>>>> Python than Forth than it belongs in comp.lang.python.

>>> Pythonians generally cannot conceptualize the need for (2), I think.
>>> Their approach is to import C as needed.

>> That may be, but if your language ends up being more like Python than
>> Forth it still would be more appropriate to comp.lang.python than
>> comp.lang.forth.

> I'll stick to where I think the actual expertise to make it happen is,
> thank you. Besides, I don't really know where those requirements will
> lead. Surprise me.