Forth lecture 10. Scripting. 
Author Message
 Forth lecture 10. Scripting.

I am currently working on my thesis on an ai subject. As a
stepping stone I have made this learning expert shell d++ in
Forth. Learning means interacting with a lot of people,
preferably an unruly bunch. Yes the Net. This means that
currently I am adding tools to Forth in the direction of CGI
programming, such that you can consult d++ via the Net.

I am through with "Cgi programming on the world wide web" by Shishir
Gundavaram, published by O'Reilly. He does some plugging for perl.
I am through reading. If I am through programming there will be few
advantages left of perl over Forth for web scripting. Yes familiarity.
I know how I want to handle regular expressions, associative arrays,
the use of external programs in Forth.

Some people have been talking about Forth as a Scripting
language lately. I mean bussiness.

I have decided to formulate my Forth idea's in lectures that
are supposed to improve over time and are present on my web
site. Forth Scripting is lecture 10.

See below the first section of lecture 10, about shutting up.
--------------------------------------------------------

Forth as a scripting language.

What do we need for scripting?

A lot of things, but let us order them by subject.

No messages during startup, or later.

For scripting we must get rid of messages during startup. At
startup, normally a sign on message is presented, showing what
Forth and what version you are talking to.

It helps if we have all this information gathered in a single
word called .SIGNON . Typically it prints the contents of the
environment queries NAME SUPPLIER VERSION CPU . Of course CPU
is a double number printed in base hexatrentical.

The FIG tradition printed this sign on message with each ABORT
. Coos Haak insists that ABORT should be silent, because QUIT
is supposed to be silent. I am not quite convinced this is a
correct interpretation of the ISO Forth standard. I see systems
like GForth printing a lot of information on ABORT's (or any
THROW) and I think that is a Good Thing. It is a good idea to
have diagnostics information printed at the place where the
final and fatal exception is caught, but I also think is is
good to separate this from code that is supposed to do a
reinitialisation. Of course error detection and post mortem
analysis is an area where there should be much room for
customization, and a possibility to insert sophisticated tools.
Later on, because it definitely doesn't belong in the kernel of
a Forth system.

So ideally we have about this situation. ABORT executes 2
THROW. The exception is caught and all possible help is given
to find out about the error. Then execute a silent
reinitialisation that for a lack of a better name we could call
(ABORT). (Sane people would call it INIT.) This word has the
effect of QUIT plus cleaning of stacks.

Bottom line is that COLD calls (ABORT) and this doesn't result
in any messages.

We are left with two sources of messages:

     The word OK that is responsible for printing "OK" after
     each line of code is executed.
     The sign on message.

So in scripting during cold startup we just don't print the
sign on message. If we are not talking to a terminal, we just
suppress .SIGNON . And we make OK shut up. Now that is easy.

'NOOP 'OK 3 CELLS MOVE

At least in ciforth that is easy. The above code copies the
behavior of NOOP (a no operation word) into OK .

If you didn't factor out the printing of "OK" to a separate
word, now is the time. It is a great place to insert a stack
print if you are debugging too.

Now the last trick. How do we find out whether we are talking
to a terminal? This is a bit system-dependent.
In linux that goes like this:

CREATE TERMIO 60 ALLOT
HEX 0 5401 TERMIO 36 LINOS 0<

This asks Linux, using an operating system call 36, to fill in
TERMIO with the properties of the terminal. If it gives a
negative result, that means it failed, and we are not connected
to a terminal at all, but to a stream.

The constants 60, 5401 and 36 are looted from c after a long
and {*filter*}y battle. On a typical Red Hat system, there are 8
files called termios.h , and one of them includes a file that
defines TCGETS as 5401. (Or includes a file that includes ...
). So at last, this is the code to be present in COLD :

0 5401 TERMIO 36 LINOS 0< IF
    'NOOP 'OK 3 CELLS MOVE
ELSE
    .SIGNON
THEN

And if you don't want to do it yourself.

ALSO ENVIRONMENT
: .SIGNON
CR SUPPLIER TYPE "is proud to present "

;
PREVIOUS

This assumes that environment queries are Forth words present
in an ENVIRONMENT word list. This is not ISO, but this approach
is taken by GForth, iForth, tForth, ciforth and probably
others.

--------------------------------------------------------
Don' go away.
Coming up next: Unix environment strings.
---
Albert.
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.

--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.



Sun, 21 Mar 2004 16:15:54 GMT  
 Forth lecture 10. Scripting.

Quote:

> ... Of course CPU is a double number printed in base hexatrentical.
> ...

Fah! This is needlessly repetitive innecessary redundancy. Would you
write "base decimal"? Of course not! Perhaps you believed that
"hexatrentical", being a new (for me, anyway) coinage needed explanation
in this group? Maybe, but I hope not.

I like your new word and I will adopt it if you permit. I can just hear
myself explaining: "That's base 36, not a mutilated octopus. I said
'hexatrentical', not 'hexatentacle'."

Thanks for your gifts.

Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------



Tue, 23 Mar 2004 00:51:55 GMT  
 Forth lecture 10. Scripting.
I've a few years of experience at web scripting.. So hopefully I can add in
some of my desires...
I actually just got into forth after seeing it mentioned on slashdot. I've
been programming in PHP for a few years, can read C/Perl/Java, and do minor
hacks with them.
Forth just seems like the right approach. Its the only language I know that
can practically be stretched from being embedded in refridgerators to being
scripting language.

I've been awake and working far too long, sorry if I ramble at any time..

I witnessed the rise of PHP in the internet.. I first got into it when I
found out that I could code the functionality of some shopping cart scripts
in 1/10th the file size.
The actual syntax and internal programming of PHP can't really be used for
reference, but the functions that have popped up evolved out of use, and I
think that they
should be analyzed.
These functions are designed around web scripting.. and decent web scripting
involves being able to communicate with other sites, and use a database.

PHP is the one that got MySQL its popularity. They just work hand in hand
for what the bulk of web scripting involves.
now I think I read somewhere that there is a forth that interfaces nicely
with postgres. PostgreSQL is prefered by the experienced programmers by far
over MySQL..

It looks like all the tools are there to introduct forth as a player in the
web scripting area. This is positive for Forth because a very large
community would develop if it were to be accepted. There are two primary web
servers, IIS and Apache. Creating a forth that could be compiled for both
would be the goal.. just call it mod_forth.. minimal c coding required to
interface it. If postgresql is supported, then the db end is set, I've seen
tcp/ip packages, and thats all it needs to start.. Of course people would
like to do neat things with some of the c libraries around, gdlib and
pdflib.. The only concern I'd have would be working with strings. It needs
to be easy, I get by just by using substr/strpos/strlen fairly well.

I needed to get all that off my chest.. I've been looking around for awhile
for decent forth driven websites to little success.

If there is an effort to get forth to start powering websites, I'd like to
be in on the news.

-Charles



Quote:
> I am currently working on my thesis on an ai subject. As a
> stepping stone I have made this learning expert shell d++ in
> Forth. Learning means interacting with a lot of people,
> preferably an unruly bunch. Yes the Net. This means that
> currently I am adding tools to Forth in the direction of CGI
> programming, such that you can consult d++ via the Net.

> I am through with "Cgi programming on the world wide web" by Shishir
> Gundavaram, published by O'Reilly. He does some plugging for perl.
> I am through reading. If I am through programming there will be few
> advantages left of perl over Forth for web scripting. Yes familiarity.
> I know how I want to handle regular expressions, associative arrays,
> the use of external programs in Forth.

> Some people have been talking about Forth as a Scripting
> language lately. I mean bussiness.

> I have decided to formulate my Forth idea's in lectures that
> are supposed to improve over time and are present on my web
> site. Forth Scripting is lecture 10.

> See below the first section of lecture 10, about shutting up.
> --------------------------------------------------------

> Forth as a scripting language.

> What do we need for scripting?

> A lot of things, but let us order them by subject.

> No messages during startup, or later.

> For scripting we must get rid of messages during startup. At
> startup, normally a sign on message is presented, showing what
> Forth and what version you are talking to.

> It helps if we have all this information gathered in a single
> word called .SIGNON . Typically it prints the contents of the
> environment queries NAME SUPPLIER VERSION CPU . Of course CPU
> is a double number printed in base hexatrentical.

> The FIG tradition printed this sign on message with each ABORT
> . Coos Haak insists that ABORT should be silent, because QUIT
> is supposed to be silent. I am not quite convinced this is a
> correct interpretation of the ISO Forth standard. I see systems
> like GForth printing a lot of information on ABORT's (or any
> THROW) and I think that is a Good Thing. It is a good idea to
> have diagnostics information printed at the place where the
> final and fatal exception is caught, but I also think is is
> good to separate this from code that is supposed to do a
> reinitialisation. Of course error detection and post mortem
> analysis is an area where there should be much room for
> customization, and a possibility to insert sophisticated tools.
> Later on, because it definitely doesn't belong in the kernel of
> a Forth system.

> So ideally we have about this situation. ABORT executes 2
> THROW. The exception is caught and all possible help is given
> to find out about the error. Then execute a silent
> reinitialisation that for a lack of a better name we could call
> (ABORT). (Sane people would call it INIT.) This word has the
> effect of QUIT plus cleaning of stacks.

> Bottom line is that COLD calls (ABORT) and this doesn't result
> in any messages.

> We are left with two sources of messages:

>      The word OK that is responsible for printing "OK" after
>      each line of code is executed.
>      The sign on message.

> So in scripting during cold startup we just don't print the
> sign on message. If we are not talking to a terminal, we just
> suppress .SIGNON . And we make OK shut up. Now that is easy.

> 'NOOP 'OK 3 CELLS MOVE

> At least in ciforth that is easy. The above code copies the
> behavior of NOOP (a no operation word) into OK .

> If you didn't factor out the printing of "OK" to a separate
> word, now is the time. It is a great place to insert a stack
> print if you are debugging too.

> Now the last trick. How do we find out whether we are talking
> to a terminal? This is a bit system-dependent.
> In linux that goes like this:

> CREATE TERMIO 60 ALLOT
> HEX 0 5401 TERMIO 36 LINOS 0<

> This asks Linux, using an operating system call 36, to fill in
> TERMIO with the properties of the terminal. If it gives a
> negative result, that means it failed, and we are not connected
> to a terminal at all, but to a stream.

> The constants 60, 5401 and 36 are looted from c after a long
> and {*filter*}y battle. On a typical Red Hat system, there are 8
> files called termios.h , and one of them includes a file that
> defines TCGETS as 5401. (Or includes a file that includes ...
> ). So at last, this is the code to be present in COLD :

> 0 5401 TERMIO 36 LINOS 0< IF
>     'NOOP 'OK 3 CELLS MOVE
> ELSE
>     .SIGNON
> THEN

> And if you don't want to do it yourself.

> ALSO ENVIRONMENT
> : .SIGNON
> CR SUPPLIER TYPE "is proud to present "

> ;
> PREVIOUS

> This assumes that environment queries are Forth words present
> in an ENVIRONMENT word list. This is not ISO, but this approach
> is taken by GForth, iForth, tForth, ciforth and probably
> others.

> --------------------------------------------------------
> Don' go away.
> Coming up next: Unix environment strings.
> ---
> Albert.
> Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
> To suffer is the prerogative of the strong. The weak -- perish.

> --
> Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
> To suffer is the prerogative of the strong. The weak -- perish.




Tue, 23 Mar 2004 02:19:14 GMT  
 Forth lecture 10. Scripting.

Quote:

>I've a few years of experience at web scripting.. So hopefully I can add in
>some of my desires...
>I actually just got into forth after seeing it mentioned on slashdot. I've
>been programming in PHP for a few years, can read C/Perl/Java, and do minor
>hacks with them.
>Forth just seems like the right approach. Its the only language I know that
>can practically be stretched from being embedded in refridgerators to being
>scripting language.

>I've been awake and working far too long, sorry if I ramble at any time..

>I witnessed the rise of PHP in the internet.. I first got into it when I
>found out that I could code the functionality of some shopping cart scripts
>in 1/10th the file size.
>The actual syntax and internal programming of PHP can't really be used for
>reference, but the functions that have popped up evolved out of use, and I
>think that they
>should be analyzed.
>These functions are designed around web scripting.. and decent web
scripting
>involves being able to communicate with other sites, and use a database.

>PHP is the one that got MySQL its popularity. They just work hand in hand
>for what the bulk of web scripting involves.
>now I think I read somewhere that there is a forth that interfaces nicely
>with postgres. PostgreSQL is prefered by the experienced programmers by far
>over MySQL..

>It looks like all the tools are there to introduct forth as a player in the
>web scripting area. This is positive for Forth because a very large
>community would develop if it were to be accepted. There are two primary
web
>servers, IIS and Apache. Creating a forth that could be compiled for both
>would be the goal.. just call it mod_forth.. minimal c coding required to
>interface it. If postgresql is supported, then the db end is set, I've seen
>tcp/ip packages, and thats all it needs to start.. Of course people would
>like to do neat things with some of the c libraries around, gdlib and
>pdflib.. The only concern I'd have would be working with strings. It needs
>to be easy, I get by just by using substr/strpos/strlen fairly well.

>I needed to get all that off my chest.. I've been looking around for awhile
>for decent forth driven websites to little success.

>If there is an effort to get forth to start powering websites, I'd like to
>be in on the news.

>-Charles

>                <snip>

It is true that Forth can be used as a scripting language. It can even be
used as a network language for robotics, and it has been. The difficulty, as
always, is to convince the great unwashed multitude of programmers of this
reality.

A big problem in using Forth for web servers or browsers is that Forth is
too late. As a labor of love and information, all right, but as a source of
revenue???  That said, it would be great to have iNet code available in
Forth that every other language seems to have fo its users.

Walter Rottenkolber

Walter Rottenkolber



Tue, 23 Mar 2004 12:18:15 GMT  
 Forth lecture 10. Scripting.


Quote:
>No messages during startup, or later.

>For scripting we must get rid of messages during startup. At
>startup, normally a sign on message is presented, showing what
>Forth and what version you are talking to.

Gforth produces its welcome message after processing the OS command
line and before entering interactive mode.  When using Gforth as a
scripting language, it never enters interactive mode and therefore
never displays the welcome message.  Does that satisfy your
requirement?

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html



Tue, 23 Mar 2004 23:06:44 GMT  
 Forth lecture 10. Scripting.


Quote:


> >I've a few years of experience at web scripting.. So hopefully I can add
in
> >some of my desires...
> >I actually just got into forth after seeing it mentioned on slashdot.
I've
> >been programming in PHP for a few years, can read C/Perl/Java, and do
minor
> >hacks with them.
> >Forth just seems like the right approach. Its the only language I know
that
> >can practically be stretched from being embedded in refridgerators to
being
> >scripting language.

> >I've been awake and working far too long, sorry if I ramble at any time..

> >I witnessed the rise of PHP in the internet.. I first got into it when I
> >found out that I could code the functionality of some shopping cart
scripts
> >in 1/10th the file size.
<snip>

> >-Charles

> >                <snip>

> It is true that Forth can be used as a scripting language. It can even be
> used as a network language for robotics, and it has been. The difficulty,
as
> always, is to convince the great unwashed multitude of programmers of this
> reality.

> A big problem in using Forth for web servers or browsers is that Forth is
> too late. As a labor of love and information, all right, but as a source
of
> revenue???  That said, it would be great to have iNet code available in
> Forth that every other language seems to have fo its users.

> Walter Rottenkolber

> Walter Rottenkolber

That's actually no problem at all. All the end-business cares about is that
it's running on Linux. None of my clients have ever heard about PHP, but
that has not hurt their confidence in me. As a source of revenue, you can
use any programming language you want for web scripting -- you simply
advertise the operating system that you will be running it on.

As for the programmers -- they've all shown great interest in learning new
scripting languages. Did any of you notice the response when Ruby and Zope
came out? There is also Perl 6 on the way which will no doubt gain instant
acceptance.  The nice part about scripting languages is that you can easily
run a few of them at a time. Many people run mod_perl and php concurrently.

As for the actual development of the forth code that would allow people to
use it instead of one of the multitude of other scripting language, it would
be foolish to expect any kind of revenue from the project. However, if the
project did succeed (even just a little bit), it would give enough
credibility to allow for a decent stream of clients. I've gotten a few

the core code, it helps your resume.

-Charles



Wed, 24 Mar 2004 02:42:14 GMT  
 Forth lecture 10. Scripting.

Quote:

[...]

> The constants 60, 5401 and 36 are looted from c after a long
> and {*filter*}y battle. On a typical Red Hat system, there are 8

        ^^^^^^^^
to guarantee for that, never care noticing the works of others...

Quote:
> files called termios.h , and one of them includes a file that
> defines TCGETS as 5401. (Or includes a file that includes ...
> ). So at last, this is the code to be present in COLD :

those are all documented quite obviously, e.g. in the "a{*filter*}ils" package,
whithin several forth' sources, in the linux sources, "Documentation"
directory, "ioctl-number.txt", and by a few (growing) number of web
sites...

I'd implement a very simple and memory/time efficient means to executing
syscalls by names, supplying every (at compile time) in the actual kernel
known name, in an eforth variant and in "lib4th", plain assembly:
e.g.

("4th>abs" required w/ "lib4th")

best,
        hp

--
"a{*filter*}ils" at http://www.*-*-*.com/ , "projects" page
"e4a", an experimental eForth (wrt "as" in att & intel syntax modes)
                http://www.*-*-*.com/ #e4
"lib4th"       http://www.*-*-*.com/ #l4
--

        .hpr - h.-peter recktenwald, berlin - t: +49 30 85967858
Linux,Assembly,Forth: http://www.*-*-*.com/ (en,de)



Fri, 26 Mar 2004 06:15:05 GMT  
 Forth lecture 10. Scripting.

Quote:



>>No messages during startup, or later.

>>For scripting we must get rid of messages during startup. At
>>startup, normally a sign on message is presented, showing what
>>Forth and what version you are talking to.

>Gforth produces its welcome message after processing the OS command
>line and before entering interactive mode.  When using Gforth as a
>scripting language, it never enters interactive mode and therefore
>never displays the welcome message.  Does that satisfy your
>requirement?

Of course. Maybe I was too focussed on the very primitive (let's say
simple) Forth's like mine, where you don't want separate modes. But
now I have discovered that if one implements options in the simplest
way possible, you automatically get into what could be called a mode.
Unix command interpreters (shells) more or less impose a -s option for
all would be scripting languages. So there.

These lectures are an ongoing project and this insight will be
in the second edition.

Quote:
>- anton

--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
To suffer is the prerogative of the strong. The weak -- perish.



Thu, 01 Apr 2004 20:59:24 GMT  
 Forth lecture 10. Scripting.


Quote:


>>Gforth produces its welcome message after processing the OS command
>>line and before entering interactive mode.  When using Gforth as a
>>scripting language, it never enters interactive mode and therefore
>>never displays the welcome message.  Does that satisfy your
>>requirement?

>Of course. Maybe I was too focussed on the very primitive (let's say
>simple) Forth's like mine, where you don't want separate modes. But
>now I have discovered that if one implements options in the simplest
>way possible, you automatically get into what could be called a mode.

Right, Gforth starts up and processes its command line (scripting
mode), then it waits for user input (interactive mode).  There is no
non-modal way.  This is unlike modes in some other systems which enter
either script mode or interactive mode (depending on a flag or whether
there is a script), but not both.

Quote:
>Unix command interpreters (shells) more or less impose a -s option for
>all would be scripting languages. So there.

I have no idea what you mean by that.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html



Mon, 12 Apr 2004 22:26:57 GMT  
 
 [ 11 post ] 

 Relevant Pages 

1. Forth lecture 10. Scripting.(Suite)

2. modulus 10 script?

3. Problems with running Expect script on AIX 4.x (works fine on HP-UX 10.x)

4. Lectures in Forth: Regular expressions.

5. Lectures in Forth 15: code highlighting.

6. Top 10 Language Constructs (Forth)

7. Hello all-new to group Forth Programmer for 10+ years

8. Mind.Forth PD AI: 10.Aug.1999 Progress Report

9. North (S.F.) Bay Forth Interest Group (10/14, Berkeley)

10. Forth Opinion Poll from internet 10/94 results

11. Mind.Forth PD AI: 10.Aug.1999 Progress Report

12. Numbers from 1 to 10 (was Numbers from 1 to 10 in Over 4500 Languages)

 

 
Powered by phpBB® Forum Software