XWindows, and FORTH 
Author Message
 XWindows, and FORTH

Dear FORTHers.

        [Just as an aside, I subscribe to and read most of comp.lang.*.  
In every other newgroup, I have seen extensive arguing about "<This
language> vs. <The other language>".  Boy, it gets old.  I am allways
assured that I can move into comp.lang.forth and not hear that.  I'm not
sure if it's because the others have no argument against FORTH (Isn't it
the best?) or we're too professional for that.  :) ]

        For a class project, I am attepting to bring FORTH into the
scene.  Here on campus, if you don't use Pascal, you use C.  If you
don't use C, your not a CS major.  Well, I've used FORTH for years, and
I'm going to try to write this project in FORTH.  I need some advice:

        I'm attepting to write a couple compiler extensions to
Tile-FORTH.  These compiler extensions will basically be a set of forth
words to impliment the XWindows protocol.  I have started to write many
of the XWindows primitives into FORTH words, but I have run into some
dificulties.  Especially:

        o  I'd like to impliment words that are more inteligent using the
        CREATE-DOES> construct.  Something like this could be written:

        SimpleWindow W

        And the word SimpleWindow will automaticaly call
        CreateSimpleWindow() with the apropriate hints (pulled from
        the stack).  This has led to some problems.  Mostly because
        I'm not the best FORTH programmer around.  Any one have any
        sugestions on implimenting this most effecietly?

        o  There is a bigger concern in code size and style.  The few
preliminary FORTH words I have written have allowed me to write some
simple programs to test them out.  They work great, but the code looks
horrible.  It basically resembles this:

: progname
        create display
        display XOpenDisplay
        dup not
        if abort" Cannot open Display"
        else
        swap !          ( place display in variable display)

        Which isn't to bad.  But, the while loop that gets Xevents is
huge.  It's also a {*filter*} case statement.  Any ideas on how to encapsulate
this, but still allow it to be easily expanded; ie. more cases added?

        I'm also thinking of taking the approach to writing the primitive
XWIndows functions into Tile-Forth, and then building more compicated
structures and definitions using FORTH.  I would like to make the
definitions as inteligent as possible (using create-does>) but I'm still
unsure of how this is going to happen.  Are there any good code examples
out there of XWindows in FORTH?

Thanks much,

Mike



Fri, 21 Feb 1997 09:05:22 GMT  
 XWindows, and FORTH
Michel W Pelletier:
           Which isn't to bad.  But, the while loop that gets Xevents
. is huge.  It's also a {*filter*} case statement.  Any ideas on how to
. encapsulate this, but still allow it to be easily expanded;
. ie. more cases added?

Build a structure which represents a condition and its corresponding
handler.  Build a linked list of those.  Write a handler for this
linked list.

--
Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

                         NB.  public e, n, y
                         x -: n&|&(*&y)^:d 1  NB. 1=(d*e)+.p*&<:q



Fri, 21 Feb 1997 11:06:41 GMT  
 XWindows, and FORTH

        Michel> Dear FORTHers.

Hi Michel!

        Michel> I'm attepting to write a couple compiler extensions to
        Michel> Tile-FORTH.  These compiler extensions will basically be a set of forth
        Michel> words to impliment the XWindows protocol.  I have started to write many
        Michel> of the XWindows primitives into FORTH words...

Sounds interesting. I have thought of doing something like that, too, because
I believe Forth could be used like Tcl/Tk but is has the advantage that is allows
more expressive programming and is thus better to extend. Tile-Forth is portable
enough to run on any (most) Unix-machines also.

        Michel> o  I'd like to impliment words that are more inteligent using the
CREATE-DOES> construct.  Something like this could be written:

        Michel> SimpleWindow W

        Michel> And the word SimpleWindow will automaticaly call
        Michel> CreateSimpleWindow() with the apropriate hints (pulled from
        Michel> the stack).  This has led to some problems.  Mostly because
        Michel> I'm not the best FORTH programmer around.  Any one have any
        Michel> sugestions on implimenting this most effecietly?

Maybe I am getting it wrong, but I understand your questions this way:

"CreateSimpleWindow()" constructs a data-structure that is later pointed to somehow in
the code body of "W", right?

Suppose the "DOES>-Code" of W expects a pointer to the
data-structure created by "CreateSimpleWindow":

A simple solution could be like this:

: SimpleWindow ( data_for_CreateSimpleWindow -- )
        create CreateSimpleWindow
        does> do_something_sensible
;

Maybe you want a general constructor "Window" that can be parametrized:

: Window ( data_for_CreateSimpleWindow  pointer_to_constructor -- )
        create execute
        does> do_something_sensible
;

You could call "Window" like that (assuming the appropriate data is pushed onto
the stack already):

' CreateSimpleWindow Window W
CreateComplexWindow Window W

As an optimization you could define a word that generates the appopriate data on the stack
and then calls "CreateSimpleWindow" itself like this:

: CreateSimple ( -- )
        get_simple_defaults
        CreateSimpleWindow
;

and thus be able to write:

CreateSimple Window W

That's Forth! ;-)

If you want to encapsulate the sometimes dangerous appearance of dealing
with pointers to words you can rewrite "CreateSimpleWindow" like this:

: CreateSimpleWindow ( -- )
        ['] CreateSimple Window
;

and result again in:

CreateSimpleWindow W

(although I would prefer the previous version.)

(This should be Forth-83 compatible, I hope it works with Tile-Forth...)

I would like to hear of your progress in this project. Maybe you can send me
more detailed information about your development?

I wonder if there is a collection of libraries for Tile-Forth. Someone knowing of
developments in this direction?

--

Bye,
        Dirk



Fri, 21 Feb 1997 17:56:53 GMT  
 XWindows, and FORTH

[stuff deleted]

Quote:

>    Which isn't to bad.  But, the while loop that gets Xevents is
>huge.  It's also a {*filter*} case statement.  Any ideas on how to encapsulate
>this, but still allow it to be easily expanded; ie. more cases added?

Have you thought about using the equivalent of a jump table? (I'm not
familiar with Tile, so I can't give specifics for that dialect.)
Brodie gave an example of one in "Thinking Forth", a book that I no
longer have (dammit).  I've got an example _somewhere_ on my Forth
disks (Fig-Forth) that I might be able to dig up and post (I *know*
that I'm gonna regret saying that...).

Depending on the size of your case statement and how Tile handles
them, the jump table could be faster.

[remainder deleted]
--
/ ------------------------------------------------------------------------ \
/ Mark Flacy             "There's a lot to be said for a blow to the head" \

/                        "I guess ya had to be there." - Me                \



Fri, 21 Feb 1997 14:51:54 GMT  
 XWindows, and FORTH

        [ lots deleted ]

Quote:
>    o  There is a bigger concern in code size and style.  The few
> preliminary FORTH words I have written have allowed me to write some
> simple programs to test them out.  They work great, but the code looks
> horrible.  It basically resembles this:

> : progname
>    create display
>    display XOpenDisplay
>    dup not
>    if abort" Cannot open Display"
>    else
>    swap !          ( place display in variable display)

>    Which isn't to bad.  But, the while loop that gets Xevents is
> huge.  It's also a {*filter*} case statement.  Any ideas on how to encapsulate
> this, but still allow it to be easily expanded; ie. more cases added?

What you want is a finite state machine compiler. Since I don't use Tile,
I can't guarantee the following will work, but I assume it is a dialect
of F83, so here goes

        : FSM:  CREATE   ,  ,   ;       ( wid 0 --)
        : WIDE  0  ;
        : ;FSM  DOES>  ( col dfa -- xi)


                R>  *  +  2 +  CELLS  OVER  +  DUP  ( -- dfa adr adr)

                ROT !                   \ update state

        0 CONSTANT >0
        1 CONSTANT >1
        2 CONSTANT >2                        \ etc.

        : |   '  ,  ;           \ place xt in next data field cell

Example:

3 WIDE  FSM: (fixed)    ( col#)         \ input fixed-pt #
\ input         |  other        |  digit        |     .      |
\ state         ----------------------------------------------
  ( 0 )         | DROP | >0  | APPEND | >0        | APPEND | >1
  ( 1 )         | DROP | >1  | APPEND | >1        | DROP   | >1    ;FSM

\ use as

variable count
: get_fixed     0 count !                             \ init count
                begin   get_char  dup                 ( char char)
                        digit?  abs   dup  count  +!  \ inc count
                        over  ascii . =   2 and  +    ( char col# )

                        (fixed)
                repeat  2drop  cr  ." All done!"  ;

You should check this carefully before you try it. Something very like
it works well with F-PC (I just don't have the actual version here, how-
ever).

Further reading about FSM's and their compilers in FORTH:

        1. Article by me called "Avoid Decisions" in Computers in Physics
           I think Sept/Oct 1991 (or was it Jul/Aug?).

        2. Talk at 1990 Rochester FORTH Conference (in proceedings).

        3. Forthcoming article (updated for ANS) -- originally submitted
           in 1991, not published because of hiatus, revised and to be
           published REAL SOON NOW -- in J. FORTH Applications and Res.

        4. My book, "Scientific FORTH: a modern language for scientific
           computing" (ordering info & blurb appended) has a lengthy
           section on this, but the code is suitable only for indirect-
           threaded systems. (The above works on direct- and ANS compatible
           FORTHs.)

--jvn

-------------------------- BLURB --------------------------------
What do Yale University, The University of Chicago, Fermilab  and
the technical libraries of many industrial laboratories  have  in
common? "Scientific FORTH: a modern language for scientific  pro-
gramming" (ISBN 0-9632775-0-2) by Julian V. Noble  (Professor  of
Physics at The University of {*filter*}ia), that's what!

FORTH has been called "...one of the  best-kept  secrets  in  the
computing world". Combining the execution  speed  of  a  compiled
language with the immediacy and  convenience  of  an  interpreted
language, FORTH is nevertheless  so  simple  its  kernel  can  be
compressed into a few kilobytes of machine code. Many scientists,
engineers and programmers have recognized that FORTH "...provides
the most direct,  revealing  and  flexible  way  for  controlling
computer hardware yet invented,"  applying  FORTH  to  industrial
control, robotics and laboratory instrumentation.

FORTH is the only completely extensible modern computer language.
User-defined operators, data structures, commands, functions  and
subprograms  act  precisely  like  the   core   operators,   data
structures and commands -- they are  true  extensions  to  FORTH.
Moreover, the FORTH compiler is part of the  language,  available
to the user. These features give FORTH enormous abstractive power
and elegance of expression. A  FORTH  program  to  solve   linear
equations can look as simple as

: }}SOLVE     ( adr[M] adr[y] - - )
              SETUP   TRIANGULARIZE   BACKSOLVE  ;

"Scientific FORTH: a modern language  for  scientific  computing"
extends  the  FORTH  kernel  in  the  direction   of   scientific
problem-solving. It is the  first  book  to  illustrate  advanced
FORTH programming techniques with non-trivial applications:

         . high-speed real and complex floating point arithmetic
         . generic data structures and  operations  ("intelligent
           floating point stack")
         . numerical integration/Monte-Carlo methods
         . linear equations and matrices
         . functional representation of data (FFT, polynomials)
         . function minimization
         . differential equations
         . roots of equations
         . computer algebra
         . FORmula TRANslator

Since (as sayeth the Preacher)  "...time  and  chance  happen  to
everything" (even FORTH!) "Scientific FORTH" devotes considerable
space  to  explaining  the  algorithms  and  ideas   behind   the
illustrative programs.

All programs appear on the diskette included with the book.

The list price  of  "Scientific  FORTH:  a  modern  language  for
scientific computing" (ISBN 0-9632775-0-2) is $49.95 + $3.00  s/h
(in continental US--overseas shipping additional).

To order, send personal check,  money  order  (sorry,  no  credit
cards) or corporate  purchase  order  (terms  for  P.O.'s:  $5.00
handling charge--except educational institutions--payment  due 30

         Mechum Banks Publishing
         P.O. Box 335
         Ivy, {*filter*}ia 22901
         USA

        Phone: 804 295 3530     Fax: 804 296 5488

Address European orders to:

        Microprocessor Engineering, Ltd.
        133 Hill Lane
        Southampton SO1 5AF
        United Kingdom

        Tel: (44)703 631441     Fax: (44)703 339691

or

        MP-7
        17, allee de la Noiseraie
        F-93160 NOISY LE GRAND
        FRANCE

        Tel: (1) 43.03.40.36

Finally, Mechum Banks Publishing offers several discounts:

        1. 20% to students (price = $39.95 + s/h)

        2. Individuals who arrange for their corporation or institutional
           libraries to purchase "Scientific FORTH" are entitled to a
           discount for their personal copy:

           50% if the library purchases 1 copy; 100% if the library
           purchases 2 or more. (s/h extra)

        3. Quantity purchases for instructional use: please inquire.

--
Julian V. Noble



Sat, 22 Feb 1997 00:45:50 GMT  
 XWindows, and FORTH

Quote:

> Brodie gave an example of one in "Thinking Forth", a book that I no
> longer have (dammit).

It (Thinking Forth) is now available from FIG. $20, 10% discount on all
books for FIG members.  (See you latest FD)

John D. Hall, President
Forth Interest Group
P.O. Box 2154
Oakland, CA  94621
(510) 893-6784, Fax (510) 535-1295



Sun, 23 Feb 1997 04:04:19 GMT  
 XWindows, and FORTH

: given me for extending FORTH into XWindows.  One of the major changes in
: my plan is to stop using Tile-Forth, and to use an ANS forth like PFE or
: GNU's Forth.  Still haven't played around enough with either system to be
: sure which yet.

Hello Michel,

if I can help you in any way on the C-side of things, please tell me!
I think your project is most interesting.

Dirk
---

"Software is neither science nor engineering.
 It's really an obscure form of poetry."



Sun, 23 Feb 1997 15:39:03 GMT  
 XWindows, and FORTH
Dear FORTHers,

        Thank you all for your many ideas and contributions that you have
given me for extending FORTH into XWindows.  One of the major changes in
my plan is to stop using Tile-Forth, and to use an ANS forth like PFE or
GNU's Forth.  Still haven't played around enough with either system to be
sure which yet.

        the next biggest concern was code complication.  I wanted it to
be very easy to write an even handler, the part of the code that branches
acording to the event recieved.  I was given several ideas, as follows:

        o  A Linked List of Handlers to events.  Easy to code, a little slow.

        o  A Jump-Table ala Brodie.  Faster, but hard to extend.

        o  A Wordlist, still haven't figured out what this is!

        o  A Finite State Machine.

        Right now I am at a tossup between the linked list and the FSM.  
The FSM would be undoubtedly faster than a linked list.  To help me
decide, I laid out a sketch of how compiling a handler would look like.

:Handler main  ... ;end
:Handler XExpose ... ;end
:Handler ConfigureNotify ... ;end
:Handler ButtonPress ... ;end
:Handler KeyPress ... ;end
:Handler Default ... ;end

        A handler takes and event and handles it.  The main handler would
take all events, and distribute them to it's coresponding handler
(XExpose, ConfigureNotify, etc...)  Since this is a problem of cases with
in cases, here is a more graphical example:

while(main - NextEvent())
  switch(main)
    {
    case XExpose
      switch(XExpose)
        case(Event1)
        ...
        case(Event2)
        ...
    case ConfigureNotify
      switch(ConfigureNotify)
        case(Event1)
        ...
        case(Event2)
        ...

etc...

It's basically a tree, or a list of lists.  This wouldn't be to hard to
impliment in the linked list model.  it would be a list of atoms, each
having a pointer to a handler ala LISP.  So main would be a list of atoms
pointing to the first five handlers, each of which would have a list of
pointers to the next level, all the way to the bottom of the tree, which
would contain pointers to the handlers that would handle the actual event.

        Sound complicated?  It is.  But the top level code would be very
easy to write (compared to the C or PASCAL way of doing things shown
above).  I know from experience there is allways a better way.  And
I can see some problems in it allready.  ex:  How does one distinguish
a handler that distributes events, and a handler that actually handles
events?  How is it represented in memory?  And best yet, how the *HELL*
am I going to write it?  

        The second alternative is a Jump-Table.  I'm not to keen on it
because it doesn't give me the ability to easily tree-out the events.  
Some may object to my using a tree at all, but I think it is the most
natural way of coding XWindows, where events are classes of events, and
Windows are children of other windows (remeber, each window has a
handler, so this has to be reproduced for every window).  Given all this,
the Jump-Table concept falls short.

        The Wordlist was sugested to me the other day.  I have no idea
what it is.  If you would like ti enlighten me, I would be most gratefull.

        The FSM is by far the fastest of all of these.  I was even given
the code to generate a FSM by Mr. Noble (thank you, BTW).  However, I
have no idea of the theory required to write a FSM, nor am I aware of a
FSM possibilities or limitations.  Can an FSM handle the tree like
hierarchy of events?  If you have any input, I would love it.

Thanks to all,

Mike



Sun, 23 Feb 1997 14:04:13 GMT  
 XWindows, and FORTH


[lots deleted]

Quote:

>    The second alternative is a Jump-Table.  I'm not to keen on it
>because it doesn't give me the ability to easily tree-out the events.  
>Some may object to my using a tree at all, but I think it is the most
>natural way of coding XWindows, where events are classes of events, and
>Windows are children of other windows (remeber, each window has a
>handler, so this has to be reproduced for every window).  Given all this,
>the Jump-Table concept falls short.

What prevents you from jumping to another jump table?

[rest deleted]



Mon, 24 Feb 1997 11:43:45 GMT  
 XWindows, and FORTH
Michel W Pelletier wrote in a message to All:

MWP>    I'm also thinking of taking the approach to writing the
MWP> primitive  XWIndows functions into Tile-Forth, and then
MWP> building more compicated  structures and definitions using
MWP> FORTH.  I would like to make the  definitions as inteligent
MWP> as possible (using create-does>) but I'm still  unsure of
MWP> how this is going to happen.  Are there any good code
MWP> examples  out there of XWindows in FORTH?

Some time ago 1-3 years or so, someone presented in DDJ a circular popup menu, written in some Forth under X-Window. I think that article might contain some interesting references.

Groetjes,

Berend (-:
fido: 2:281/527.23



Sat, 22 Feb 1997 06:02:19 GMT  
 XWindows, and FORTH
Michel W Pelletier:
. One of the major changes in my plan is to stop using Tile-Forth,
. and to use an ANS forth like PFE or GNU's Forth.  

Can you say a bit about where you find these?

So far, the only forth's I've been able to use under unix are
tile-forth and cforth.  I used to have a copy of "This Forth", but I
didn't have a zip archiver at the time, and I've mislaid both the
package and my record of where I got it from.  I've not been able to
use "eforth in c" because it has msdos dependencies for i/o (simple to
work around, but I've been busy elsewhere).  Finally, I've never had
my hands on a copy of pfe or "gnu forth" -- when I look at a gnu
archive all I see is tile.

Thanks,

Raul D. Miller           n =: p*q             NB. 9<##:##:n [.large prime p, q

                         NB.  public e, n, y
                         x -: n&|&(*&y)^:d 1  NB. 1=(d*e)+.p*&<:q



Mon, 24 Feb 1997 05:51:17 GMT  
 XWindows, and FORTH

Quote:

> Dear FORTHers,

>    Thank you all for your many ideas and contributions that you have
> given me for extending FORTH into XWindows.  One of the major changes in
> my plan is to stop using Tile-Forth, and to use an ANS forth like PFE or
> GNU's Forth.  Still haven't played around enough with either system to be
> sure which yet.

>    the next biggest concern was code complication.  I wanted it to
> be very easy to write an even handler, the part of the code that branches
> acording to the event recieved.  I was given several ideas, as follows:

>    o  A Linked List of Handlers to events.  Easy to code, a little slow.

>    o  A Jump-Table ala Brodie.  Faster, but hard to extend.

>    The FSM is by far the fastest of all of these.  I was even given
> the code to generate a FSM by Mr. Noble (thank you, BTW).  However, I
> have no idea of the theory required to write a FSM, nor am I aware of a
> FSM possibilities or limitations.  Can an FSM handle the tree like
> hierarchy of events?  If you have any input, I would love it.

I am not sure what a "heirarchy of events" is. Is such a thing
necessary? But see below. There is no theory needed to write an FSM.
You just do it. The CS people, as well as some EEs make a big song
and dance about FSMs, and they draw diagrams that look like squids
in the act of love to complexify what is essentially a very simple
subject. To construct a FSM, decide what the inputs are. They are
the column heads. Then decide how the thing starts off in the initial
state, and what should happen given each input. The different states
(rows of the table) can be labelled but are usually numbered. They
represent different sets of responses to the same input. The idea is
that the present state is the result of actions and state transitions
taken in response to earlier input. For example, if you are
interpreting a string as a floating point number, input of the
first decimal point should put the system in a state where another
decimal point will cause an error message.

By all means read my article "Avoid Decisions!" that appeared
in Computers in Physics, Sep/Oct 1991 (or something like that). The
point was that most of the programming mistakes people make are logic
mistakes from trying to embody branching in a binary decision tree.
If the tree is complex it becomes hard to be sure the tests (for
which branch to take) are properly formulated as mutually exclusive
possibilities. It becomes hard to avoid dead code (branches that can
never be taken because the conditions to reach them are logically
impossible). OTOH, if one expresses a program's logic as a state
transition table, the actions typically become clear.

I generally find that FSM's are sufficiently compact that major
efforts at state reduction are not justified (they also make the
FSM hard to read and modify if maintainance is needed). Such
efforts, BTW, can only reduce space, not increase execution speed.

My only contribution to FSM technology is the realization that they
are very easy to write in FORTH, because a simple word can compile
a clear tabular representation into efficient code. I am pleased that
several professional FORTH programmers (among whose number I cannot
claim to be numbered) have found this method sufficiently useful they
have employed it in commercial applications.

As a final remark let me note that you can place FSMs within other
FSMs. Recursion is also possible. So the structure of rather large
programs can be factored into relatively simple pieces. My FORmula
TRANslator and an algebra program I wrote (to do a specialized
kind of matrix algebra very fast) illustrate different aspects
of FSMs in improving programming style and readability.
--
Julian V. Noble



Mon, 24 Feb 1997 06:18:41 GMT  
 XWindows, and FORTH

Finally, I've never had
|> my hands on a copy of pfe or "gnu forth" -- when I look at a gnu
|> archive all I see is tile.

That's right, it has not yet been released. Two years ago it started
out with the working title ANS fig-Forth (old hands here will remember
it). John Hall did not like it being called like this before he saw
what it was, so we asked the FSF for the GNU name. What's there apart
from the name? It's quite usable, but not quite ready for release. If
anybody is interested in helping us working on it, mail Bernd Paysan

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed



Mon, 24 Feb 1997 19:49:51 GMT  
 XWindows, and FORTH

Quote:
>Michel W Pelletier:
>. One of the major changes in my plan is to stop using Tile-Forth,
>. and to use an ANS forth like PFE or GNU's Forth.  

>Can you say a bit about where you find these?

  You can find the (possibly) latest verion of pfe available for ftp at
ftp.gate.net under /pub/users/spc/pfe .

  If there's a later verion than 0.9.6 then it's not here.  I've been a bit
too busy to keep up with any newer versions.

  -spc (I know it's available elsewhere, just forgot where ... )



Tue, 25 Feb 1997 13:28:29 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. XWindows and FORTH

2. Eiffel and XWindows questions

3. AIX vs. XWindows

4. OSF/Motif and XWindows support for Oberon-2 on VAX/VMS (H2O)

5. Preventing ved from using bold fonts under xwindows

6. X11 / XWindows in Modula-2

7. US-VA-TysonsCorner: Secret/Ada/XWindows/HPUX/-#JD-0158PM082101-0400

8. SPERC Ada Bindings to Motif/XWindows

9. TeleUSE/Ada/Xwindows

10. XWINDOWS with ADA on PC

11. Interface between Ada and XWindows?

12. XWindows libs for Ada wanted.

 

 
Powered by phpBB® Forum Software