Re: [colorforth] How is colorForth different from other Forths?

["Roman Pavlyuk \(personal\)" <john@xxxxxxxxxxxxx>]

Hi All,

First, apologies for some unclear pieces of text, it's almost midnight here
now :).

I do think that a specification of what colorForth _is_ would be better than
description of how it's different.

I would like to see colorForth as a closed self-sufficient meta system, with
clear separation into layers, or wordset, or whatever.

If you look at FORTH-83 standard, for instance, at
http://forth.sourceforge.net/standard/fst83/fst83-12.htm
you'll see that words are grouped into Nucleus, Device, Interpreter and
Compiler layers.

But if you try describing colorForth as it is now this way, you'll see it's
not self sufficient, nor "closed". I do not like adding features via
compiling x86 code, I'd prefer cf equivalents to be present in the core.

Here are a few examples of things I do not like:

1) IF, -IF are written in cf, while THEN is in assembly (color.asm). It's
because THEN modifies LIST variable (look-back optimizer stopper, as I
understand it, though cf optimizer requires a separate chapter in the
specifications), and this variable is not accessible from cf code, so you
cannot write your own branch construct like that.

2) There is no ALLOT or equivalent, you have to use 1, 2, 3, ,. What if you
need a larger buffer? Top of dictionary used to be a nice temporary buffer
in F-83, but since there is no _core_ way to move here back, this technique
is harder to use. I can write my own temp buffer word and comma-words that
work with this buffer, but why create extra entities?

I used [ 0 drop -if ]  to compile a jump that skips a compiled string. While
possible, it's a bit ugly J Though, I did not want to compile a forward
branch - as to be, either core has to support constructs like this, or
explain why you shouldn't use them. I'd prefer F-83's >MARK <RESOLVE
approach - to me it's a bit clearer.

3) Using flags in branches. Construct like [ 1 2 0 push + pop if A then ]
will execute A, though top of the stack is 0. It's a nice optimization,
sometimes, but sometimes you have to do ugly tricks like 0 +, which does not
improve readability. Anyway, this is a minor concern. And I'd not like code
IF's differently for each platform (see previous post, 6502 style vs. x86
style)

4) Things like using cyan color for compiling words (as far as I understand,
Mark Slicker has implemented this) would be nice to have.

5) LITERAL actually can be avoided for yellow-to-green transition. Though it
's hard to compile two numbers this way (look at the tricks I used to return
address and length of ascii string)

To summarize, I'd like to see a standard, describing what is included, why,
what is not included, why, how to use what is included, why not to use what
was not included :)

One more reason why I would not like to focus on comparing cf and "other"
forths is that I would not like to see cf crystallized in it's present
state. Does everyone thinks that it's in the best shape and cannot be
improved and cleaned up? Well, there should be some goal for us to reach,
maybe, it'd be reasonable to think about where cf is and where it can be
headed? Maybe, considering it as a development IDE and make it generate
small standalone applications and write drivers for QNX? Windows DirectX
games? Web server that hosts a Wiki-in-CF? Anyway, as to me, in present
state it's not a development platform, it requires more cleanup and
documenting, though I find the environment very nice and well thought for
the tasks it was designed for.


BR,
Roman


---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com