XWindows and FORTH 
Author Message
 XWindows and FORTH

Anton Ertl:
: Tcl seems to be quite a bit less extensible. A few weeks ago Richard
: Stallman posted a message (on a gnu group) that Tcl should not be
: used because it does not allow some more complicated stuff.

As I understand, there's quite a bit of stuff that Tcl doesn't allow.
A couple deficits that come to mind are:

(*) No static code analysis (Tcl is slow, and you can't make it faster
without some significant changes in the language), and

(*) a lack of modules (Tcl is intended for small projects and good
luck if you wan to do anything big with it)

The big things Tcl has over ansi forth are: a well rounded set of
string primitives, including especially hash tables (tables of
strings, "indexed" by strings).  That, and it's presented as a linking
library (roughly equivalent to a Forth wordset) which makes it easy to
use in C programs.

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



Sun, 13 Apr 1997 03:14:10 GMT  
 XWindows and FORTH
|> Have you thought about using Tcl/Tk toolkit. I found its soul quite near
|> to Forth. Some references just in case:
|> newsgroup comp.lang.tcl

|> 'home' cs.berkeley.edu
|>
|> This is an extensible (maybe a bit less than Forth but anyway...) X Windows
|> programming environment. It's interpretive and has powerful and reasonable
|> tools for writing X applications.

Tcl seems to be quite a bit less extensible. A few weeks ago Richard
Stallman posted a message (on a gnu group) that Tcl should not be used
because it does not allow some more complicated stuff.

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



Sun, 13 Apr 1997 02:02:00 GMT  
 XWindows and FORTH
Have you thought about using Tcl/Tk toolkit. I found its soul quite near
to Forth. Some references just in case:
newsgroup comp.lang.tcl

'home' cs.berkeley.edu

This is an extensible (maybe a bit less than Forth but anyway...) X Windows
programming environment. It's interpretive and has powerful and reasonable
tools for writing X applications.
--
.............................................................................

: University of Tartu, Dept.Comput.Sci, J.Liivi St 2, Tartu, EE2400 Estonia :
:...........................................................................:



Sat, 12 Apr 1997 04:59:10 GMT  
 XWindows and FORTH

|> |> Have you thought about using Tcl/Tk toolkit. I found its soul quite near
|> |> to Forth. Some references just in case:
|> |> newsgroup comp.lang.tcl

|> |> 'home' cs.berkeley.edu
|> |>
|> |> This is an extensible (maybe a bit less than Forth but anyway...) X Windows
|> |> programming environment. It's interpretive and has powerful and reasonable
|> |> tools for writing X applications.
|>
|> Tcl seems to be quite a bit less extensible. A few weeks ago Richard
|> Stallman posted a message (on a gnu group) that Tcl should not be used
|> because it does not allow some more complicated stuff.

Tcl is actually quite extensible.  Where problems arise, it is because Tcl has
a limited set of "primitives", is basically a string handling language
(expression evaluation proceeds through conversion of strings to numbers,
computation, and then conversion of the result to a string), and is fully
interpreted with a corresponding speed penalty (something like 300x slower than
compiled C, if I remember right).  It's an interesting language
with string-handling capabilities similar to perl and awk.

Tk (Osterhout's graphical tcl add-on) is a fairly nice graphics library (it
uses the Motif "look and feel") which is often separated from tcl (there are
bindings for Scheme, Modula-2, and other HLLs) and is becoming quite popular
in the UNIX world for building graphical interfaces.  A Forth binding for
Tk (in a C-based Forth) should be a good way to play with X in Forth.

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

Loring Craymer



Mon, 14 Apr 1997 11:08:10 GMT  
 XWindows and FORTH

: The big things Tcl has over ansi forth are: a well rounded set of
: string primitives, including especially hash tables (tables of
: strings, "indexed" by strings).  That, and it's presented as a linking

These arrays that can be indexed by strings sound very good. AWK has
that too. Then it lacks several other features like multi-dimensional
arrays that can be emulated using concatenated strings of indices as
one dimensional index. Or structures which can be roughly formed with
these arrays too. It turned out in my work that I never needed strings
as indices except in cases where they had to replace a more appropriate
construct.

Dirk

---



Mon, 14 Apr 1997 18:25:37 GMT  
 XWindows and FORTH
Quote:

>|> programming environment. It's interpretive and has powerful and reasonable
>|> tools for writing X applications.
>Tcl seems to be quite a bit less extensible. A few weeks ago Richard
>Stallman posted a message (on a gnu group) that Tcl should not be used
>because it does not allow some more complicated stuff.

Please read what both sides really wrote. Stallman is not happy about
TCL because he thinks it's not a 'real' programming language.
After followed one of the biggest flam.. aeh discussions i ever saw.
(10 comp.lang groups and numerous attempts to define the one and only
scripting language.)

        Heiko Wengler



Mon, 14 Apr 1997 19:10:18 GMT  
 XWindows and FORTH

Dear FORTHers,

        Well, I have compiled the first trial of an X windows interface to
PFE FORTH and it works.  It can't do much besides open a server connection
and some other simple things like get events and create sijmple windows.
The main reason for this post is to ask for some advice.

        How should I name the new words?

        I am naming the words that call specific Xlib functions under that
name.  So, for the word that calls the C function XCreateSimpleWindow(), I
named the word 'XCreateSimpleWindow'.  For words that retrieved specific
information from structures, I tried to name them the best I could.  There
is a word called 'EventType?'  that gets the XEvent.type from the XEvent
that the word 'XNextEvent' leaves on the stack.  Etc, etc....

        Any sugestions on what would make this interface as easy to program
in as possible?  X can be extaordinarily complex, so I am trying to make
these words as close to self-documenting as possible.

Here are the words so far.  (Probably about 1% of the total in X!)

XOpenDisplay  ( name -- display* )
XCreateSimpleWindow (display* parent x y w h bgrdpixel frgrdpixel -- window)
XMapWindow (Display* Window -- )
XNextEvent (display  EXevent* -- )
EventType?  (XEvent* -- XEvent.type )

        There are a few more, but you get the gist of my naming so far.

Any sugestions?

Michel



Tue, 15 Apr 1997 22:48:16 GMT  
 XWindows and FORTH

: Dear FORTHers,

:       Well, I have compiled the first trial of an X windows interface to
: PFE FORTH and it works.  It can't do much besides open a server connection
: and some other simple things like get events and create sijmple windows.
: The main reason for this post is to ask for some advice.

:       How should I name the new words?

:       I am naming the words that call specific Xlib functions under that
: name.  So, for the word that calls the C function XCreateSimpleWindow(), I
: named the word 'XCreateSimpleWindow'.  For words that retrieved specific
: information from structures, I tried to name them the best I could.  There
: is a word called 'EventType?'  that gets the XEvent.type from the XEvent
: that the word 'XNextEvent' leaves on the stack.  Etc, etc....

This sounds like a useful project.  Why not keep any references to "X"
hidden?  In other words, think of the interface as generic, with X windows
as only one underlying implementation, and write the specifications of
the words with a generic interface in mind.  So the implementation could
be in MacOS, Windows, etc...

--David

------------------------------------------------------------------------
David N. Williams             Phone:  1-(313)-764-5236

University of Michigan
Ann Arbor, MI 48109-1120



Tue, 15 Apr 1997 23:48:55 GMT  
 XWindows and FORTH

|> Anton Ertl:
|> : Tcl seems to be quite a bit less extensible. A few weeks ago Richard
|> : Stallman posted a message (on a gnu group) that Tcl should not be
|> : used because it does not allow some more complicated stuff.

|> The big things Tcl has over ansi forth are: a well rounded set of
|> string primitives, including especially hash tables (tables of
|> strings, "indexed" by strings).

Forth has tables indexed by strings: wordlists. A few problems,
though: they are not guaranteed to work for strings longer than 31
chars, and it is not specified whether they are case-sensitive or not.

|> Please read what both sides really wrote. Stallman is not happy about
|> TCL because he thinks it's not a 'real' programming language.
|> After followed one of the biggest flam.. aeh discussions i ever saw.
|> (10 comp.lang groups and numerous attempts to define the one and only
|> scripting language.)

Sorry (well, not too much), I missed this flamewar (and thus the other
side), until I brought it to c.l.f:-/. I must be reading the wrong
newsgroups. But I'm happy to see Scheme announced as the basis for
GNU's extension languages rather than something awk-like (but maybe
I'm doing Tcl wrong by calling it awk-like?).

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



Wed, 16 Apr 1997 00:15:10 GMT  
 XWindows and FORTH


Quote:

>This sounds like a useful project.  Why not keep any references to "X"
>hidden?  In other words, think of the interface as generic, with X windows
>as only one underlying implementation, and write the specifications of
>the words with a generic interface in mind.  So the implementation could
>be in MacOS, Windows, etc...

>--David

>------------------------------------------------------------------------
>David N. Williams             Phone:  1-(313)-764-5236

>University of Michigan
>Ann Arbor, MI 48109-1120

        Well, that would be dificult.  This implimentation is very PFE
specific, which means I could, in theory, move over any implimentation to
anywhere else.  But, there are tremendous differences in GUI implimentations
throughout the computer industry.  I have nad Mac, OS/2, MSWin, and XWin
experience and I have to say that they are extremely different in form,
function, and flavor.  Perhaps I could develop a set of very high level
words that do jsut the basis Window functions, and those could be ported,
but for example, in MSWin window's do not have to be mapped.  In X, mapping
is an essencial element to programming (via XMapWindow() or
XMapSubWindows()).  Hiding those details would be difficult.  Also, Mac,
OS/2 and MS have one thing in common that X doesn't.  They window clients
run on the same machine as the window server.  In X, the client and the
server are completly seperate entities, seperatable by many miles of
networking (the clients and servers don't even have to be remotely ofthe
same acrchetecture).  These details have been built into X, and are an
essential element of it.

        I have however been considering writing a set of high level words
that use the low level Xlib words.

        Any one have a cool idea on what your ideal high level graphics
language would look like?



Wed, 16 Apr 1997 03:29:27 GMT  
 XWindows and FORTH



|> >
|> >This sounds like a useful project.  Why not keep any references to "X"
|> >hidden?  In other words, think of the interface as generic, with X windows
|> >as only one underlying implementation, and write the specifications of
|> >the words with a generic interface in mind.  So the implementation could
|> >be in MacOS, Windows, etc...
|> >
|> >--David
|> >
|> >-----------------------------------------------------------------------
|>   Well, that would be dificult.  This implimentation is very PFE
|> specific, which means I could, in theory, move over any implimentation to
|> anywhere else.  But, there are tremendous differences in GUI implimentations
|> throughout the computer industry.  I have nad Mac, OS/2, MSWin, and XWin
|> experience and I have to say that they are extremely different in form,
|> function, and flavor.  Perhaps I could develop a set of very high level
|> words that do jsut the basis Window functions, and those could be ported,
|> but for example, in MSWin window's do not have to be mapped.  In X, mapping
|> is an essencial element to programming (via XMapWindow() or
|> XMapSubWindows()).  Hiding those details would be difficult.  Also, Mac,
|> OS/2 and MS have one thing in common that X doesn't.  They window clients
|> run on the same machine as the window server.  In X, the client and the
|> server are completly seperate entities, seperatable by many miles of
|> networking (the clients and servers don't even have to be remotely ofthe
|> same acrchetecture).  These details have been built into X, and are an
|> essential element of it.
|>
|>   I have however been considering writing a set of high level words
|> that use the low level Xlib words.
|>
|>   Any one have a cool idea on what your ideal high level graphics
|> language would look like?
|>

I'd like to put in another plug for building a Forth binding for Tk.  [Tk provides
a library for implementing a high level graphical language].  I think that you'd
find this not overly difficult (although Tk is some 65 Klines, including comments)
and it would eventually be portable to non-UNIX platforms (Osterhout's group
at Sun is doing Windows and Mac ports, as I understand it).  I don't really see
much reason for reinventing this particular wheel.

Loring Craymer



Wed, 16 Apr 1997 07:47:03 GMT  
 XWindows and FORTH


Quote:

>    Well, I have compiled the first trial of an X windows interface to
>PFE FORTH and it works.  It can't do much besides open a server connection
>    How should I name the new words?

Choose a good, commercially available, book on X and use the exact spelling
that the book uses. When it come time to sell your product you will have
some documentation to include with it. Can you do display postscript next?


Wed, 16 Apr 1997 08:01:43 GMT  
 XWindows and FORTH

Quote:

>I'd like to put in another plug for building a Forth binding for Tk.  
[Tk provides
>a library for implementing a high level graphical language].  I think
that you'd
>find this not overly difficult (although Tk is some 65 Klines, including
comments)
>and it would eventually be portable to non-UNIX platforms (Osterhout's
group
>at Sun is doing Windows and Mac ports, as I understand it).  I don't
really see
>much reason for reinventing this particular wheel.

>Loring Craymer

        I think there's a bit of confusion here.  Tk, Motif, OpenLook, and
many other styles of display, are just types of X implimentations.  They
all, in the end, rely on the X protocol.  I'm just trying to tie the lowest
level implimentation of the X protocol (Xlib, in C) into PFE forth.  After
this, it is quite possible, to integrate one, or many of the above mentioned
packages.  One could also compile in PEX, the 3-D extension to X, or Shape,
the Non-Rectangular windows extension to X.  

        I can't get any lower with Xlib, other than writing out the protocol
explicitly using sockets, UDP, and a whole lot of other stuff I'd rather not
write.  the X protocol is probably the most complicated protocol
I've *ever* worked with.

        Then again, I could write an interface with a very high level
display abstraction, such as Motif, or OpenLook.  *But*, it would not be
very usefull without the ability to call explicit Xlib functions.  And,
since Motif and the like are written in Xlib, there is no disadvantage in
size.  Also, an X client is given no guarentee that the server it wants to
connect to can do anything other than X.  Motif and OpenLook require the
server to play a part in the flavor of the application.  Mtif and OpenLook
are popular, but not standard.  X is standard, and therefore it's the only
thing your guarenteed to have with any X station.

        As a mild conterpoint (I agree with your statements above),
NetManage makes a program called XSession, that lets a MSWindows station
impliment the X protocol.  It's a nice package, and I've also seen a
Shareware program much like it.  They both use the Motif interface (although
the NetManage version is a bit more airtight, the Shareware version seemed a
bit smaller and faster...but I didn't do any Benchmarks, so don't take this
as scripture).  I'd hate to reinvent any wheels, but I think any X
implimentation should just impliment the standard X, and any extensions
shoul be just that.  Extensions.  If and when a certain style of X becomes
standard (which I doubt, X is by design *policy free*), then it would be
acceptable to write a program in that style.  

        Perhaps I don't understand Tk that much.  If what I said above could
be contered easily, take the shot!  I want this program to go through a
rigorous peer review.  Please take apart what I say, mangle it, and throw it
back in my face.  It'll make a better program in the end.

Later,



Sat, 19 Apr 1997 03:40:19 GMT  
 XWindows and FORTH

Quote:

>Choose a good, commercially available, book on X and use the exact spelling
>that the book uses. When it come time to sell your product you will have
>some documentation to include with it. Can you do display postscript next?

        I have the mother of all X books, the O'Riely Series.  It is shipped
by Sun, DEC, and several other companies as their standard X manual.  I am
trying my hardest to stick with their name style (and they try their hardest
to stick wit hthe standard name style).  However....

        I am FORTHing the thing a bit.  I doubt any of you wold want to
program the thing if it just looked like C.  And also, due to forth's
implicit paramater passing (ala stack), lot's of words need to be written to
take advantage of that.  An example is thw word 'STYLE?'  STYLE?  takes an
event as it's input off the stack, and leaves the style of the event on the
stack.  In C, this would be an asignment:

        whatever = Event.style;

        All STYLE? does is access the style member ofthe Event construct.
Since this is not factored out of common C code, I had to invent the name
STYLE?  myself.  I have a feeling I'll be inventiong lot's of words like
STYLE?.  
        Rest assured though, when I can use a standard X name (like
XCreateSimpleWindow) I do.

Later,

Michel



Sat, 19 Apr 1997 03:47:57 GMT  
 XWindows and FORTH

        [ snip ]

Quote:
>    All STYLE? does is access the style member ofthe Event construct.
> Since this is not factored out of common C code, I had to invent the name
> STYLE?  myself.  I have a feeling I'll be inventiong lot's of words like
> STYLE?.  
>    Rest assured though, when I can use a standard X name (like
> XCreateSimpleWindow) I do.

It looks to me as though you are missing a wonderful opportunity to
factor the rotten C-like naming conventions of X. Instead of prolifer-
ating zillions of functions that probably differ only a bit, why not
say, e.g.,

        Simple Window XCreate

I bet, by cleverly writing the function calls as jump tables,
and by being a bit clever in what the adjectives ("Simple") and
nouns ("Window") do, you could get away with a trivial amount of
code and no noticeable additional delay.

Just a thought. But that's essentially why a FORmula TRANslator
can be written in 7K of code.   --jvn

--
Julian V. Noble



Sat, 19 Apr 1997 09:14:28 GMT  
 
 [ 23 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