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

[Mark Slicker <maslicke@xxxxxxxxxxx>]

On Tue, 16 Dec 2003, Roman Pavlyuk (personal) wrote:

> 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?

If you need a temporary buffer, do you even need allot? Why not just use
the dictionary pointer, wherever it is currently located?

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

Could you elaborate on what you are doing here? There may be a better
way.

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

Actually   -1 ?   is the construct to set the flags.

The use of flags intoduces a global state with possibly complex
concequences. I would be tempted to use the machineForth  if  except I
think this   if   can be managed so long as you don't abuse the
construct. I would like to see how portability is affected in practice.

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

No I haven't implemented this. It seems to be useful for implementing
somewhat odd features. It might be a natural extension to the current
semantics for words:

         macro     forth
yellow     ?      execute
green   execute   compile
cyan    compile      ?

>
> 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?

No.

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

I've thought a web browser would be interesting. People generally don't
have a web browser which doesn't hog resources or spam their system with
pop-up advertisements. There is a possibility of original work here,
since web browsers seem to simply copy the features of each other.

I think colorForth has the most promise for interactive applications. The
bar is already set pretty low by past efforts. There is an opportunity for
a simple language for creating simple light-weight and responsive user
applications.

I would rather gain more experience with these types of applications, then
to promote colorForth as a development platform. Maybe at a latter stage
the lessons learned can benefit a much larger audience.

Some of forthcoming developments merit a delay in any kind of detailed
documentation, notably colorForth in colorForth.

In the mean time, there is the community compiled word list:

http://kristopherjohnson.net/cgi-bin/twiki/view/Main/ColorForthWord

Mark

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