A Standard to Teach Forth (was Re: Chuck Moore on ANSI) 
Author Message
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)

Quote:


>    Having a Forth for teaching is a very good idea. But you
>have to ignore the meaning of the word "standard" as it is used
>in the computer industry. I don't care if a Forth for teaching
>is standard or not; I just want it to work exactly the same
>way on every computer a student is likely to use.

  Doesn't that then, describe a standard?

Quote:
>     Every Forth program that solves an exercise on one student's
>computer has to solve it on every other student's computer. That
>means the Forth systems all have to use exactly the same model
>and implementation details, something ANS Forth carefully avoids
>dealing with. You could skip this stringent requirement by
>just using a small part of Forth's capabilities. But then you'd
>only be teaching a language with little more power than Basic.

  I don't see that.  Where I'm at, C is currently being used to teach
programming, and there are implementation details left up to the compiler
that may differ from system to system, plus constructs that produce
undefined behavior ( printf("%d %d %d",i++,i++,i++) for instance).

  I would contend that hiding such details harms the student in the long
run.  Integers are not always 32 bits, nor are pointers always 32 bits, nor
are characters always 8 bits, nor can you count on a separate floating point
stack.

Quote:
>     We had a good language for teaching Forth back in 1978
>with the fig model. It was ported to nearly all the affordable
>computers of the time and worked pretty much the same way
>on all of them.

  Would these be primarily CPUs that could address 65,536 8-bit quantities?
How well would the fig model work on the PDP-8, or the PDP-10 or PDP-11?
Granted, those at the time were hardly affordable like Z80 based systems
were, but there's more to life than 8 bit bytes with 16 bit addresses.

  For instance, I can name a system with 8 bit bytes, 32 bit ints, 64 bit
longs, 80 bit floats and 48 bit pointers and it's a fairly cheap commodity
today (although I doubt anyone really uses the 48-bit address).

Quote:
>platforms as fig-Forth and the 1983 standard was not used
>to write identical multi-platform systems for teaching. The
>ANS standard is even worse in this respect.

  How so?

Quote:
>     Those who would like to have a version of Forth for
>teaching have a lot of work to do. Not only do we have the
>problems with Forth standards, we have the problem of multiple
>hardware platforms. I don't think you can get a group of
>Forth programmers to agree to write the same implementation
>for multiple CPU's and operating systems.  

  What's wrong with the ANS standard?

  -spc (I mean, besides not specifying your standard of FORTH)



Mon, 24 Jan 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)

Quote:

>      We had a good language for teaching Forth back in 1978
> with the fig model. It was ported to nearly all the affordable
> computers of the time and worked pretty much the same way
> on all of them. There are many Forth textbooks that use fig
> Forth as the main language of instruction.  fig Forth became
> old-fashioned, obsolete, not worth using. The new 1983 standard
> was supposed to replace it. F83 by Laxen & Perry started off
> quickly to show how the 1983 standard could be made to work
> on several different platforms. But F83 never ran on as many
> platforms as fig-Forth and the 1983 standard was not used
> to write identical multi-platform systems for teaching. The
> ANS standard is even worse in this respect.

I would not say so. Gforth is an ANS Forth system that runs on many
different platforms (We even received a report from a Sun 3 user:-).

PFE also works on several platforms.

Quote:
> I don't think you can get a group of
> Forth programmers to agree to write the same implementation
> for multiple CPU's and operating systems.

Bill Ragsdale could and did. Laxen and Perry could and did. We (the
Gforth team) can and do.

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

http://www.complang.tuwien.ac.at/anton/home.html



Tue, 25 Jan 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)

Quote:


> >  But F83 never ran on as many
> > platforms as fig-Forth and the 1983 standard was not used
> > to write identical multi-platform systems for teaching. The
> > ANS standard is even worse in this respect.

In '83, the computer market was cleaned up compared to '78. F83 ran on
the important platforms of it's days.

Quote:
> I would not say so. Gforth is an ANS Forth system that runs on many
> different platforms (We even received a report from a Sun 3 user:-).

With the Gforth-EC effort, Gforth currently runs even on two virtually
non-existent platforms (MISC and 4stack CPU). The more important hosts
are to follow (8086 reportedly said "ok", PSC1000 and C16x too, 6502
runs Tetris). It takes us a day to port Gforth to a new CPU, given we
have a Forth-written assembler for it. It takes from minutes to hours to
port Gforth to a CPU where GCC is available. We could add a ANSI-C style
NEXT to target even more environments with almost no effort (volunteers
here?).

Quote:
> PFE also works on several platforms.

> > I don't think you can get a group of
> > Forth programmers to agree to write the same implementation
> > for multiple CPU's and operating systems.

> Bill Ragsdale could and did. Laxen and Perry could and did. We (the
> Gforth team) can and do.

It's interesting that someone with a mail account at gnu.ai.mit.edu
doesn't seem to know about GNU Forth. Wake up, and look into your ftp
server. Maybe you could invest some time and add to it what you claim
doesn't exist for Forth, i.e. documentation or code comments. All the
hidden secrets of how to write a target compiler or a Forth kernel is
free and open to everyone in Gforth's sources. The heart of our cross
compiler is so small, that the only thing you really should document
IMHO is the place where it actually is ;-).

--
Bernd Paysan
"Late answers are wrong answers!"
http://www.informatik.tu-muenchen.de/~paysan/



Wed, 26 Jan 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)



     (Mike Coughlin) writes:

:>      We had a good language for teaching Forth back in 1978
:> with the fig model. It was ported to nearly all the affordable
:> computers of the time and worked pretty much the same way
:> on all of them. There are many Forth textbooks that use fig
:> Forth as the main language of instruction.  fig Forth became
:> old-fashioned, obsolete, not worth using. The new 1983 standard
:> was supposed to replace it. F83 by Laxen & Perry started off
:> quickly to show how the 1983 standard could be made to work
:> on several different platforms. But F83 never ran on as many
:> platforms as fig-Forth and the 1983 standard was not used
:> to write identical multi-platform systems for teaching. The
:> ANS standard is even worse in this respect.

:I would not say so. Gforth is an ANS Forth system that runs on many
:different platforms (We even received a report from a Sun 3 user:-).

    Sounds like you mean just one Sun 3 user. I'll have to study
Gforth more so I can write about it on comp.sys.sun to see if more
Sun 3 users will try it.

     But couldn`t you write an even better version if you didn't
have to follow the ANS standard?

:PFE also works on several platforms.

:> I don't think you can get a group of
:> Forth programmers to agree to write the same implementation
:> for multiple CPU's and operating systems.

:Bill Ragsdale could and did. Laxen and Perry could and did. We (the
:Gforth team) can and do.

     These efforts lasted for a few years. Unfortunately while writing
Forth systems, people think of new ways to do things that they like
are better than the standard or model that they start with. I hope
these improvements will get copied to all the versions and be well
documented.

     Does Gforth or PFE work on the old or new MacIntoshes?

--



Fri, 28 Jan 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)



Quote:

(Mike Coughlin) writes:
>>    Having a Forth for teaching is a very good idea. But you
>>have to ignore the meaning of the word "standard" as it is used
>>in the computer industry. I don't care if a Forth for teaching
>>is standard or not; I just want it to work exactly the same
>>way on every computer a student is likely to use.
>  Doesn't that then, describe a standard?

    It certainly doesn't describe a standard for the computer industry.

Quote:
>>     Every Forth program that solves an exercise on one student's
>>computer has to solve it on every other student's computer. That
>>means the Forth systems all have to use exactly the same model
>>and implementation details, something ANS Forth carefully avoids
>>dealing with. You could skip this stringent requirement by
>>just using a small part of Forth's capabilities. But then you'd
>>only be teaching a language with little more power than Basic.
>  I don't see that.  Where I'm at, C is currently being used to teach
>programming, and there are implementation details left up to the compiler
>that may differ from system to system, plus constructs that produce
>undefined behavior ( printf("%d %d %d",i++,i++,i++) for instance).
>  I would contend that hiding such details harms the student in the long
>run.  Integers are not always 32 bits, nor are pointers always 32 bits, nor
>are characters always 8 bits, nor can you count on a separate floating point
>stack.

     Once apon a time I used computers that had 6 bit characters, and
others that had 7 bit characters. There were others that had 5 bit
characters with a shift. I never had to use these, thank goodness.
Then one day IBM said all characters would have 8 bits, no more,
no less, and they would be called "bytes". A great burden was
lifted from all programmers. A big source of bugs went away. There
is no such uniformity with integer or floating point numbers. Now
I hear that we have to go back to the bad old days with different
bit numbers for characters on different computers. Society does
not always make progress with time.

     A Forth that is good for teaching programming to beginners
would use the same number of bits for the same items on all
computers, with a footnote in the instruction book that the
student will find a big source of crashes and other bugs in the
real world of computers with various bit sizes.

Quote:
>>     We had a good language for teaching Forth back in 1978
>>with the fig model. It was ported to nearly all the affordable
>>computers of the time and worked pretty much the same way
>>on all of them.
>  Would these be primarily CPUs that could address 65,536 8-bit quantities?
>How well would the fig model work on the PDP-8, or the PDP-10 or PDP-11?
>Granted, those at the time were hardly affordable like Z80 based systems
>were, but there's more to life than 8 bit bytes with 16 bit addresses.

     I don't know the details of the fig model on the various PDP's,
but it was available. Yes, the different bit sizes of numbers is
a pain. Its was a pain with fortran too. A 16 bit address Forth
with 16 bit integers was sort of standard at one time, but a
more general Forth standard is to use all the bits you have on
the bus on whatever computer you are using. A beginner to Forth
will have to learn about the treachery of different bit sizes,
but he doesn't have to use all of them right away.

Quote:
>  For instance, I can name a system with 8 bit bytes, 32 bit ints, 64 bit
>longs, 80 bit floats and 48 bit pointers and it's a fairly cheap commodity
>today (although I doubt anyone really uses the 48-bit address).

    Sure you use the 48 bit address. There are computers that don't
have more than 48 address lines on their printed circuit boards.
You just program with 64 bit addresses, but the high order bits
don't do anything. A standard Forth for beginners doesn't have to
be written for 48 bit or 64 bit addresses today, but in a few years
it will be. Even the old 16 bit address and 16 bit data versions of
Forth could be used to teach beginners today, but they couldn`t do
as much as they would like. So it would be better to use a 32 bit
model. Forth can be used on strange sized hardware, but why have
people start learning with extra complications such as address
sizes that aren't round numbers in binary and having to remember
that numbers for addresses and data are different sizes? Let them
deal with that after they have learned something about Forth on
a simpler system.

Quote:
>>platforms as fig-Forth and the 1983 standard was not used
>>to write identical multi-platform systems for teaching. The
>>ANS standard is even worse in this respect.
>  How so?

     Well it allows a lot of different bit sizes for characters
and numbers. Thats just one example. ANS Forth is not meant to
make Forth easy to learn for beginners. Lets make a Forth that
is easy to learn for beginners and port it to many platforms.
Lets make sure there is a good clear textbook that includes
everything a beginner needs to know about programming in Forth
and every example and problem to be solved works on every
platform. This not what the ANS standard committeee tried to do.

Quote:
>>     Those who would like to have a version of Forth for
>>teaching have a lot of work to do. Not only do we have the
>>problems with Forth standards, we have the problem of multiple
>>hardware platforms. I don't think you can get a group of
>>Forth programmers to agree to write the same implementation
>>for multiple CPU's and operating systems.  
>  What's wrong with the ANS standard?

     Sorry I can't answer that in a finite time.

--



Fri, 28 Jan 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)




Quote:
|(Mike Coughlin) writes:

|>  I would contend that hiding such details harms the student in the long
|>run.  Integers are not always 32 bits, nor are pointers always 32 bits, nor
|>are characters always 8 bits, nor can you count on a separate floating point
|>stack.

|    Once apon a time I used computers that had 6 bit characters, and
|others that had 7 bit characters. There were others that had 5 bit
|characters with a shift. I never had to use these, thank goodness.
|Then one day IBM said all characters would have 8 bits, no more,
|no less, and they would be called "bytes". A great burden was
|lifted from all programmers.

  But you still had to contend with EBCDIC and ASCII.  Less with EBCDIC
today, but there is Unicode looming just ahead.

|A big source of bugs went away. There
|is no such uniformity with integer or floating point numbers. Now
|I hear that we have to go back to the bad old days with different
|bit numbers for characters on different computers. Society does
|not always make progress with time.
|
  But Bill Gates is trying, that's for sure.

|     A Forth that is good for teaching programming to beginners
|would use the same number of bits for the same items on all
|computers, with a footnote in the instruction book that the
|student will find a big source of crashes and other bugs in the
|real world of computers with various bit sizes.
|
  Well, back in the late 70s, Pascal was supposed to be *the educational*
programming language.  I certainly learned it.  I even learned UCSD Pascal,
which had the distinction of being *the same* across all implementations (in
fact, a UCSD binary could run on multiple platforms).

  Funny how that pretty much died.

  Java now took its place and it mandates certain sizes for characters,
integers and reals.  Great if the machine you're writing code for has
support for 16 bit characters, 32 bit integers and 64 bit IEEE floating
point.  Bad for just about any other architecture.

|>>     We had a good language for teaching Forth back in 1978
|>>with the fig model. It was ported to nearly all the affordable
|>>computers of the time and worked pretty much the same way
|>>on all of them.
|
|>  Would these be primarily CPUs that could address 65,536 8-bit quantities?
|>How well would the fig model work on the PDP-8, or the PDP-10 or PDP-11?
|>Granted, those at the time were hardly affordable like Z80 based systems
|>were, but there's more to life than 8 bit bytes with 16 bit addresses.
|
|     I don't know the details of the fig model on the various PDP's,
|but it was available. Yes, the different bit sizes of numbers is
|a pain. Its was a pain with Fortran too. A 16 bit address Forth
|with 16 bit integers was sort of standard at one time, but a
|more general Forth standard is to use all the bits you have on
|the bus on whatever computer you are using. A beginner to Forth
|will have to learn about the treachery of different bit sizes,
|but he doesn't have to use all of them right away.
|
  You make it sound like it's a bad thing that there are computers out there
that are non-2 complement, 8 bit byte, 16 bit word, 32 bit double word
(almost like a certain person from comp.lang.asm.x86).

|>  For instance, I can name a system with 8 bit bytes, 32 bit ints, 64 bit
|>longs, 80 bit floats and 48 bit pointers and it's a fairly cheap commodity
|>today (although I doubt anyone really uses the 48-bit address).
|
|    Sure you use the 48 bit address. There are computers that don't
|have more than 48 address lines on their printed circuit boards.
|You just program with 64 bit addresses, but the high order bits
|don't do anything. A standard Forth for beginners doesn't have to
|be written for 48 bit or 64 bit addresses today, but in a few years
|it will be. Even the old 16 bit address and 16 bit data versions of
|Forth could be used to teach beginners today, but they couldn`t do
|as much as they would like. So it would be better to use a 32 bit
|model.

  Why limit yourself to just 32 bits?  64-bit CPUs are out already.  Heck,
skip the curve, use a 128bit version TODAY!  (Sorry, you hit one a button
there).

|Forth can be used on strange sized hardware, but why have
|people start learning with extra complications such as address
|sizes that aren't round numbers in binary and having to remember
|that numbers for addresses and data are different sizes? Let them
|deal with that after they have learned something about Forth on
|a simpler system.

  Because I'm sick and tired of fixing code, that's why.  Two weeks wasted
porting some code because some SOB *knew* that all C compilers save
parameters on the stack and could do something like:

        foobar(int a,int b,int c,int d)
        {
          int *pa = &a;
          int x;

          x = pa[2] + pa[3];
          /* ... */
        }

(Well, not exactly that, but close enough).  It worked on HIS compiler.
Hell, it worked on enough systems for him not to worry about it.  It did not
work, however, on the system I was trying to port this code to.  And it was
not a trivial problem to fix either.

  Because I'm sick and tired of fixing code that assumes a predominately
Intel bias (Windows, actually).  Because I'm sick and tired of programmers
who are blissfully unaware that anything ELSE exists besides the Wintel
cartel.

  Because I'm scared to death of actually having to "port" an ANS Forth
program.  Forth already has a reputation for being "read-only", and if it
takes me two weeks to track down some bug because a programmer "knew"
something would work when in fact it doesn't, I'm not going to bother
working with ANS Forth much longer (as it is, I'm getting very close to not
wanting to work with C, primarily because of{*filter*}poor programmers who
haven't learned, or bothered to learn, what is portable, and what isn't).

  So now you have a bind - if you use a non-standard Forth for teaching, it
doesn't help the student when faced with a real system (or ANS system).  Yet
ANS Forth isn't (in your opinion) simple enough to use for teaching.

|>>platforms as fig-Forth and the 1983 standard was not used
|>>to write identical multi-platform systems for teaching. The
|>>ANS standard is even worse in this respect.
|
|>  How so?
|
|     Well it allows a lot of different bit sizes for characters
|and numbers. Thats just one example. ANS Forth is not meant to
|make Forth easy to learn for beginners. Lets make a Forth that
|is easy to learn for beginners and port it to many platforms.
|Lets make sure there is a good clear textbook that includes
|everything a beginner needs to know about programming in Forth
|and every example and problem to be solved works on every
|platform. This not what the ANS standard committeee tried to do.
|
  Nor should they have.  But a "Teaching Forth" would, I'm afraid, suffer
the same fate as UCSD Pascal - not useful in the real world.

|>>     Those who would like to have a version of Forth for
|>>teaching have a lot of work to do. Not only do we have the
|>>problems with Forth standards, we have the problem of multiple
|>>hardware platforms. I don't think you can get a group of
|>>Forth programmers to agree to write the same implementation
|>>for multiple CPU's and operating systems.  
|
|>  What's wrong with the ANS standard?
|
|     Sorry I can't answer that in a finite time.
|
  Then what's stopping you from writing a "Teaching Forth"?

  -spc (Or rather, will the Real Version of Forth, please stand
        up?)



Fri, 28 Jan 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)



Quote:
>I even learned UCSD Pascal,
>which had the distinction of being *the same* across all implementations (in
>fact, a UCSD binary could run on multiple platforms).

>  Funny how that pretty much died.

>  Java now took its place

So you missed the point about Microsoft trying to make Java platform
specific, rather than general then, so that Java stuff ran better on the
PC (so everyone would buy PCs and have windows).  

--

James Coupe (remove .nospam to reply by e-mail)

I think I saw another ship in the sky today.  A big white one.  I've never seen
a big white one.  Only six small black ones.  Perhaps six small black ones can
look like one big white one.  Perhaps I would like a glass of whisky.  Yes, that
seems more likely.



Sat, 29 Jan 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)


....

Quote:
>  Because I'm scared to death of actually having to "port" an ANS
>Forth program.  Forth already has a reputation for being "read-only",
>and if it takes me two weeks to track down some bug because a
>programmer "knew" something would work when in fact it doesn't, I'm
>not going to bother working with ANS Forth much longer (as it is, I'm
>getting very close to not wanting to work with C, primarily because of
>piss poor programmers who haven't learned, or bothered to learn, what
>is portable, and what isn't).

That's a real problem.  Standard Forth _allows_ you to write portable
programs.  It's entirely up to you to do it correctly, and it's
entirely up to you to document any special conditions you rely on.  If
you fail at that, the first warning you get might be when someone else
tries to port it to their standard system and it doesn't work.

It would be possible to develop tools that deal with this.  We could
with some small difficulty have run-time tools that unambiguously check
for problems with the particular datasets you chose to test with.  We
could withsome small difficulty have compile-time tools that check many
things over all execution paths.  These tools could be designed to warn
consistently when there was a problem, at the expense of some spurious
warnings.

I set up such a run-time tool.  It warned about every coding practice
that deviated from the standard with the Core wordset; it warned about
every environmental dependency.  At least as I understood the standard.

It's tedious to use.  It warns about things that would matter only if
you intended to port to a 1's-complement or sign magnitude machine.  It
warns about some valid practices that it can't tell from errors.  (For
example, it doesn't let you take two double numbers ( lo1 hi1 lo2 hi2)
and do SWAP ROT to get ( lo1 hi2 lo2 hi1 ).  These look like perfectly
good double numbers, but they might not be the _same_ double numbers on
different systems.  But in preventing this it disallows many perfectly
good moves, for example OVER OVER in place of 2DUP .  2DUP works
( lo1 hi1 -- lo1 hi1 lo1 hi1 ) and OVER OVER which gives the exact same
result generates a warning.  So for each warning you have to look at
the code and figure out whether it really matters.  It's a lot of
trouble.  I only bother with it when I really want to write portable
code.  ( And then there's the chance that I made some mistakes....)

My tool includes only the core wordset.  It would be fairly easy to add
more wordsets.  It would be fairly easy to make versions that work with
various environmental dependencies.  Like, it warns about arithmetic
that overflows on a 16-bit system.  If you're running on a 32-bit
system you can have 32-bit addresses but only 16-bit offsets to those
addresses.  See, if you ran the same program on a 16-bit system the
addresses ( which are assigned by the system) would be 16-bit addresses
but the overflowing offsets could fail.  It isn't hard to change it
around to set an environmental dependency on 32 bits, and relax those
constraints.

The thing is, it looks like there just isn't a market for such tools.
Portability isn't really an issue in the Forth world.  To the extent
that it is, we solve it by sheer brain-power.  We look at the code and
think out what ought to be portable, and don't test portability at all
unless we try to run it on a few sample systems.  So we have this nice
standard that potentially allows as much portability as we're willing
to create.  And we don't use it that way.

The obvious choice, then, is don't try to port Forth *programs*.  Port
Forth *tools*, little routines that do useful things.  You can test
them to see whether they work.  The smaller the tool, the better you
can understand it and test it.  A really good tool is useful out of all
proportion to its size.  And one of the big advantages of porting it is
that it might take you a long time to design something that small and
that useful yourself.



Sun, 30 Jan 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)


Quote:
> The thing is, it looks like there just isn't a market for such tools.
> Portability isn't really an issue in the Forth world.  To the extent
> that it is, we solve it by sheer brain-power.  We look at the code and
> think out what ought to be portable, and don't test portability at all
> unless we try to run it on a few sample systems.  So we have this nice
> standard that potentially allows as much portability as we're willing
> to create.  And we don't use it that way.

        In the context of the discussion of teaching Forths, one approach
is to provide a 16-bit ASCII forth for writing small programs, and a
32-bit Unicode Forth for writing big programs, and have exercises include
writing a program and debugging it on one of the systems, and then porting
it and debugging it on the other.  In any event, only the experience of
porting between systems with different assumptions will permit students to
learn to use the tools that permit us to avoid the most dangerous
assumptions.

Virtually,

Bruce R. McFarling, Newcastle, NSW



Mon, 31 Jan 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)


Quote:
Conner) writes:



Napalm'

>  [ I wrote I'm scared to port code where the programmer didn't
>    consider portability (or the fact that other systems then PC
>    actually exist).
>    Jonah repled about a link like tool for Forth he developed ]
>>It's tedious to use.  It warns about things that would matter only if
>>you intended to port to a 1's-complement or sign magnitude machine.
>>It warns about some valid practices that it can't tell from errors.
>>(For example, it doesn't let you take two double numbers ( lo1 hi1
>>lo2 hi2) and do SWAP ROT to get ( lo1 hi2 lo2 hi1 ).  
>  The ANS spec does indicate which order doubles occupy on the stack
>(sec. 3.1.4.1 - LS part is top of stack),

The most significant part is top of stack.

Quote:
>but I would be very suspicious of theabove sequence - why are you
>splitting the two doubles up like that?  What purpose does it serve?

If you have a 2's-complement 16-bit system, you can do it and get
consistent results.  I don't know why you'd want to, but it would work.
On other systems you'd get other results and I wanted to put in a
warning.  I consider this one an error.

Quote:
>>These look like perfectly
>>good double numbers, but they might not be the _same_ double numbers
>>on different systems.  But in preventing this it disallows many
>>perfectly good moves, for example OVER OVER in place of 2DUP .  2DUP
>>works ( lo1 hi1 -- lo1 hi1 lo1 hi1 ) and OVER OVER which gives the
>>exact same result generates a warning.
>  Both 2DUP and OVER are in the CORE part of ANS Forth, so what does
>OVER OVER buy you that 2DUP doesn't?  If you mean 2DUP, why not say
>2DUP?

Yes, I do it that way myself.  But suppose you were testing code for
portability, and you started getting warnings for things like OVER OVER
that you knew were perfectly OK, and when you dug down into it to find
the problem you found that to get the mechanical tester to approve it
you had to change this perfectly good code to something else that was
almost an exact equivalent -- just because of a limitation of the tool.
And then you got a warning for DUP 0< when you meant D0< .  And say it
kept happening, say a high proportion of the warnings it gave were
really things that were OK.  If you were used to the tool you could
program to fit its limitations from the start and not run into that.
If you had a lot of mistakes then a higher fraction of the warnings
would be real.  But if you write very good code already then it's
tedious to wade through the false warnings to catch the true ones.

In my own code I only found a few errors that way that I wouldn't have
found by testing.  I occasionally used < to compare addresses when I
needed U< (which makes a tricky bug that only shows up when one address
is above and one below the midline -- unlikely in 32-bit systems
anyway).  I sometimes did BLOCK and kept the address after it wasn't
guaranteed to be valid.  (It worked on _my_ system.)  A few things like
that.

Quote:
>  If you have though,
>    : 2DUP  OVER OVER ;
>  Then that's part of the implementation of the ANS Forth system you
>are using, and presumedly shouldn't have to be checked (rather, the
>user of such a system shouldn't be running Forth-lint over the system
>code is what I mean).

Yes.  I assumed that the core wordset was present and working
correctly.  I assumed more than that, I used all the words I needed.
And the thing is extensible, if you have a new word that you've tested
to your satisfaction, you can define its stack effects etc and add it
in.

Quote:
>>So for each warning you have to look at
>>the code and figure out whether it really matters.  It's a lot of
>>trouble.  I only bother with it when I really want to write portable
>>code.  ( And then there's the chance that I made some mistakes....)
>  But if I had some ANS Forth code with poor documentation (which
>shouldn't exist, right?) then this is something I would use
>immediately to see where "problem" spots are and if any of the
>assumptions made will still "work" on the system, or even simple fixes
>made, such as:
>    CREATE myarray 20 ALLOT

> to
>    CREATE myarray 20 CELLS ALLOT

>to pick a straw man example 8-)

This is a run-time checker, not compile-time like lint.  So

signed number and multiplies by two.  It adds to myarray and gets
something that isn't an address.  myarray is an unsigned number, and
the result of adding the signed and unsigned numbers is either a
negative number, zero, a low positive number, or a high unsigned

address error, you can look at the stacks and the source code and a 1K
warning message etc.

Quote:
>>The thing is, it looks like there just isn't a market for such tools.
>>Portability isn't really an issue in the Forth world.  
>  Heck, change "Forth world" to "computer industry" and you have a
>pretty acurate (if disturbing) picture of the current state of the
>art, especially with respect to a certain company out in Redmond.
>  Do I believe that all code should be portable?  No, I'm realistic, I
>know that certain portions of code aren't portable.  But programmers
>should be aware of what is and isn't portable (or even what might not
>be portable) and plan accordingly.  One of the products I'm currently
>working on uses shared libraries and threads, written under Windows.
>Most of the code is littered with #ifdefs (okay, it's C, but the
>generalities remain) for the various Unix ports.  Only the small
>section I'm working on has a system independant API and all the ugly
>non-portable code is isolated in one file, instead of spread
>throughout the code base.  Why?  It's not like writing wrapper

functions (or macros in some cases) is a new idea.

Quote:
>  -spc (Oh, a few #ifdefs here, a few #else's there, and voila!  
>    Portable code (yea, right ... ))

When I look at it, it makes sense.  Each different platform has its
special abilities as *selling points*.  If you don't use those, the
application won't be as good as a competing application that does use
them.  If you build the application around the special capabilities of
one platform, it certainly won't be portable.  If you try to make big
sections of code portable, you're likely to find on the next platform
that when you use *its* special capabilities your portable code is not
ideal.  It could be more trouble to pick out what's usable and adapt it
than to rewrite from scratch.  (That will be worse for the maintenance
guys, but who pays attention to them?  By the time they get really
bogged down both platforms will have new releases and you'll be
rewriting anyway.)

The plain fact is that it's slower and more expensive to write portable
code, and the benefits come later if at all.  The application might get
cancelled before it's even finished, it might never get ported
anywhere.  Half of the large projects get cancelled.  Those aren't good
odds for spending extra now, to help later.

When I was doing it Greg Bailey told me it had no commercial potential.
I thought the standard wouldn't be very useful without tools like that,
and the standard would be useful, so the tools needed to exist.  Well,
people can learn to write pretty good portable code just by eyeballing
it, and the code they write that way will be more portable than Forth
code has ever been before.  To the extent that programmers train their
habits to do the right things, it doesn't cost much extra at all.  The
debugging will happen when the porting is done, when the money is there
to do the port instead of earlier when the money wasn't there.  Good
Forth programmers don't need complex tools to do debugging anyway.  It
all works out.



Wed, 02 Feb 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)


In the discussion between (Sean 'Captain Napalm' Conner) and

something like:

(Jonah)
 It's tedious to use.  It warns about things that would matter only if
 you intended to port to a 1's-complement or sign magnitude machine.
 It warns about some valid practices that it can't tell from errors.
 (For example, it doesn't let you take two double numbers ( lo1 hi1
 lo2 hi2) and do SWAP ROT to get ( lo1 hi2 lo2 hi1 ).

Obviously this is not a useful thing to do if the double numbers are
true 64-bit quantities. They could, however, stand for a "vector" of

these vectors from memory. The operation above could be a very natural
operation for some graphical algorithm, and a checker should not
interfere.



slightly more interesting trick, where a Forth-lint would be actually

an evil grin on her face.

On Intel processors a Forth double number (64-bit) is reversed from the
native format, which creates problems when interfacing with the OS (WIN32
is full of LARGE_INTEGER's).

I'm sorry if I missed the point of this (sub)discussion.

-marcel



Wed, 02 Feb 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)



Quote:
>  No, I'm aware of what Microsoft is trying to do, and it seems what
>Microsoft is trying to do is remove the impetus to portable code.  Why write
>code to run on multiple systems when hell!  Every {*filter*}y person who uses a
>computer uses an Intel x86 processor running Windows 95 or NT so why even
>bother writing code that'll never run on any other system anyway?

Though that's a valid point anyway (you don't need multi-platform
languages if there's only one platform) they were offering developers
various incentives if they made there Java only work on the PC (or, as I
recall, it was more a case of not supporting those who didn't).

{*filter*}y microsoft.

--

James Coupe (remove .nospam to reply by e-mail)

I think I saw another ship in the sky today.  A big white one.  I've never seen
a big white one.  Only six small black ones.  Perhaps six small black ones can
look like one big white one.  Perhaps I would like a glass of whisky.  Yes, that
seems more likely.



Wed, 02 Feb 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)

Quote:


>Conner) writes:



>Napalm'

>>  [ I wrote I'm scared to port code where the programmer didn't
>>    consider portability (or the fact that other systems then PC
>>    actually exist).
>>    Jonah repled about a link like tool for Forth he developed ]

>>>It's tedious to use.  It warns about things that would matter only if
>>>you intended to port to a 1's-complement or sign magnitude machine.
>>>It warns about some valid practices that it can't tell from errors.
>>>(For example, it doesn't let you take two double numbers ( lo1 hi1
>>>lo2 hi2) and do SWAP ROT to get ( lo1 hi2 lo2 hi1 ).  

>>  The ANS spec does indicate which order doubles occupy on the stack
>>(sec. 3.1.4.1 - LS part is top of stack),

>The most significant part is top of stack.

  Hmmm, I think you're right, although the lanaguge isn't quite as clear as
it could be:

        3.1.4 Cell-pair types
                A cell pair in memory consists of a sequence of two
                contiguous cells.  The cell at the lower address is
                the first cell, and its address is used to identify
                the cell pair.  Unless otherwise noted, a cell pair
                on a stack consists of the first cell immediately
                above the second cell.

        3.1.4.1 Double-cell integers
                On the stack, the cell containing the most significant
                part of a double-cell integer shall be above the cell
                containing the least significant part.

                ...

                Placing the single-cell integer zero on the stack above
                a single-cell unsigned integer produces a double-cell
                integer with the same value.

  It comes down to what 'above' means in the standard wrt the stack, and I
could not find a definition of what 'above' means.

  In 3.1.4 it simply mentions that two consecutive cells in memory are
addressed by the one with the lower address.  It then makes a rather cryptic
remark about the first cell (the one at the lower address) being "above" the
second cell when on the stack.

  Then, if the stack grows downward (and I could not find a mention in the
ANS standard that mandated the stack(s) have to grow downward although in
most implementations it seems to grow downwards), then yes, the top of the
stack is at the lower address and the storage on the stack meets the same
layout as the double-cell stored in memory, even though to say the first
cell is "above" the second-cell requires a rather liberal interpretation
to the word "above" as to me, it seems to be stored "below".

  But if the stack grows upward [1], then the storage of a double-cell on
the stack fits my mental notions of "above", but the storage is then the
opposite of how it's stored in memory.

  But you have to read these two sections very carefully or else you may
make the same mistake I did.  

Quote:
>In my own code I only found a few errors that way that I wouldn't have
>found by testing.  I occasionally used < to compare addresses when I
>needed U< (which makes a tricky bug that only shows up when one address
>is above and one below the midline -- unlikely in 32-bit systems
>anyway).

  Don't assume that a program on a 32-bit system will never use an address
above the 2G limit - the system may just put the kernel in low memory and
the user process(es) in high memory.  I seem to recall someone about 10 to
15 years ago saying we'll never need more than 640K of memory.

- Show quoted text -

Quote:
>>  But if I had some ANS Forth code with poor documentation (which
>>shouldn't exist, right?) then this is something I would use
>>immediately to see where "problem" spots are and if any of the
>>assumptions made will still "work" on the system, or even simple fixes
>>made, such as:

>>        CREATE myarray 20 ALLOT

>> to

>>        CREATE myarray 20 CELLS ALLOT

>>to pick a straw man example 8-)

>This is a run-time checker, not compile-time like lint.

  Ah.  But surely there could be a way to mark words as already being
checked (or don't bother checking), so that a word with OVER OVER to do 2DUP
can be flagged as "okay" so you don't have to check it again?

Quote:
> So

>signed number and multiplies by two.  It adds to myarray and gets
>something that isn't an address.  myarray is an unsigned number, and
>the result of adding the signed and unsigned numbers is either a
>negative number, zero, a low positive number, or a high unsigned

>address error, you can look at the stacks and the source code and a 1K
>warning message etc.

  My assumption (thus proving that it's never wise to assume) was a compile
time like "lint".  Using a notation I'm working on, the first example would
be:


        2       ( -- c )        ( -- )          ( c )
        *       ( n n2 -- n3 )  ( n -- )*       ( n )
        myarray ( -- a )        ( n -- )        ( n a )
        +       ( i i2 -- i3)** ( n -- )        ( error )

* The stack diagram for the word starts out as ( -- ) and the stack is
assumed empty, but both are modified as the word is compiled.  '*' takes two
parameters, but there's only one item on the stack, so the stack diagram for

';', anything left on the stack becomes the right side of the stack diagram.

** Certain words can work on different datatypes, but the assumption is that
the two types on the stack are of the same type.

  You can see that we get an error.  Make the change, and you get:

        CELLS   ( n -- a )      ( n -- )        ( a )
        myarray ( -- a )        ( n -- )        ( a a )
        +       ( i i2 -- i3 )  ( n -- )        ( a )

        ;                       ( n -- n )


Quote:
>>  -spc (Oh, a few #ifdefs here, a few #else's there, and voila!  
>>        Portable code (yea, right ... ))

>When I look at it, it makes sense.  Each different platform has its
>special abilities as *selling points*.  If you don't use those, the
>application won't be as good as a competing application that does use
>them.  If you build the application around the special capabilities of
>one platform, it certainly won't be portable.  If you try to make big
>sections of code portable, you're likely to find on the next platform
>that when you use *its* special capabilities your portable code is not
>ideal.  It could be more trouble to pick out what's usable and adapt it
>than to rewrite from scratch.  (That will be worse for the maintenance
>guys, but who pays attention to them?  By the time they get really
>bogged down both platforms will have new releases and you'll be
>rewriting anyway.)

  The trick is to figure out what parts are portable, what isn't and
separate the two.  The project I'm working in already runs on 17 different
platforms (although now the main development platform is unfortunately
Windows NT) and new functionality is being added - in this case, shared
libraries (to dynamically load up modules at run time), threads (to increase
through put) and semaphores (to ensure nothing gets clobbered).  All three
of those are pretty much system dependant yet that didn't stop the current
developers in using Windows NT specific calls EVERYWHERE, and then patch
things up to include the other 16 platforms.

  The small section I'm working on I went ahead and encapsulated the
threads, semaphores and shared libraries within an API I created, thus
isolating the non-portable stuff from the rest of the application.  That
way, not only is it easier to test the non-portable stuff, but the main
application code is cleaner.

  So far, I've had to write the code for three platforms (the NT platform
code was written by another programmer) and when the fifth platform needs to
be supported, it shouldn't take as long.

Quote:
>The plain fact is that it's slower and more expensive to write portable
>code, and the benefits come later if at all.  

  And I claim that's so because programmers don't know what is involved in
writing portable code, so yes, it's going to be more expensive later on.

  I remember working on another project a few years ago when I helped port a
program from MS-DOS to Unix [2]

Quote:
>The application might get
>cancelled before it's even finished, it might never get ported
>anywhere.  Half of the large projects get cancelled.  Those aren't good
>odds for spending extra now, to help later.

  But some of the things that help portability aren't that expensive to do
upfront, unless the programmers have no experience with other systems, which
is why I think it's a bad idea to hide system dependancies when teaching.
Heck, something as simple as forcing students to write code that works under
Unix (available at all major universities) and MS-DOS (or Windows or Mac -
common enough) should be enough to drive the point home.

  -spc (Had to maintain my own code for four years across two different
        platforms when I worked at the university I attended)

[1]     Upward?  Who ever heard of a stack growing upward?  Well, it may
        not be as strange as it sounds.  I'm playing around with a Forth
        like derivative (of my design) where the stacks grow upward and
        it does simplify the design quite a bit.

[2]     I was at the company for two weeks, but when it came apparent that

                a) the Unix department was porting v6 while the rest of the
                   development team was working on v7 and NO effort was
                   being made to make v7 "portable" so that meant that
                   v7 would have to be ported as well [3]

                b) their coding standards I felt lead to more bugs than
                   it prevented by being a standard [4] and they were not
                   about to change one bit of it

        I left.  It was a hopeless cause that the company lost money on, and
        the Unix division was later disbanded.  Pity too, because they could
        charge more
...

read more »



Wed, 02 Feb 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)

  [ I wrote I'm scared to port code where the programmer didn't consider
    portability (or the fact that other systems then PC actually exist).
    Jonah repled about a link like tool for Forth he developed ]

Quote:
>It's tedious to use.  It warns about things that would matter only if
>you intended to port to a 1's-complement or sign magnitude machine.  It
>warns about some valid practices that it can't tell from errors.  (For
>example, it doesn't let you take two double numbers ( lo1 hi1 lo2 hi2)
>and do SWAP ROT to get ( lo1 hi2 lo2 hi1 ).  

  The ANS spec does indicate which order doubles occupy on the stack (sec.
3.1.4.1 - LS part is top of stack), but I would be very suspicious of the
above sequence - why are you splitting the two doubles up like that?  What
purpose does it serve?

Quote:
>These look like perfectly
>good double numbers, but they might not be the _same_ double numbers on
>different systems.  But in preventing this it disallows many perfectly
>good moves, for example OVER OVER in place of 2DUP .  2DUP works
>( lo1 hi1 -- lo1 hi1 lo1 hi1 ) and OVER OVER which gives the exact same
>result generates a warning.

  Both 2DUP and OVER are in the CORE part of ANS Forth, so what does OVER
OVER buy you that 2DUP doesn't?  If you mean 2DUP, why not say 2DUP?

  If you have though,

        : 2DUP  OVER OVER ;

  Then that's part of the implementation of the ANS Forth system you are
using, and presumedly shouldn't have to be checked (rather, the user of such
a system shouldn't be running Forth-lint over the system code is what I
mean).

Quote:
>So for each warning you have to look at
>the code and figure out whether it really matters.  It's a lot of
>trouble.  I only bother with it when I really want to write portable
>code.  ( And then there's the chance that I made some mistakes....)

  But if I had some ANS Forth code with poor documentation (which shouldn't
exist, right?) then this is something I would use immediately to see where
"problem" spots are and if any of the assumptions made will still "work" on
the system, or even simple fixes made, such as:

        CREATE myarray 20 ALLOT

 to

        CREATE myarray 20 CELLS ALLOT

to pick a straw man example 8-)

Quote:
>The thing is, it looks like there just isn't a market for such tools.
>Portability isn't really an issue in the Forth world.  

  Heck, change "Forth world" to "computer industry" and you have a pretty
acurate (if disturbing) picture of the current state of the art, especially
with respect to a certain company out in Redmond.

  Do I believe that all code should be portable?  No, I'm realistic, I know
that certain portions of code aren't portable.  But programmers should be
aware of what is and isn't portable (or even what might not be portable) and
plan accordingly.  One of the products I'm currently working on uses shared
libraries and threads, written under Windows.  Most of the code is littered
with #ifdefs (okay, it's C, but the generalities remain) for the various
Unix ports.  Only the small section I'm working on has a system independant
API and all the ugly non-portable code is isolated in one file, instead of
spread throughout the code base.  Why?  It's not like writing wrapper
functions (or macros in some cases) is a new idea.

  -spc (Oh, a few #ifdefs here, a few #else's there, and voila!  
        Portable code (yea, right ... ))



Wed, 02 Feb 2000 03:00:00 GMT  
 A Standard to Teach Forth (was Re: Chuck Moore on ANSI)

Quote:



>>I even learned UCSD Pascal,
>>which had the distinction of being *the same* across all implementations (in
>>fact, a UCSD binary could run on multiple platforms).

>>  Funny how that pretty much died.

>>  Java now took its place

>So you missed the point about Microsoft trying to make Java platform
>specific, rather than general then, so that Java stuff ran better on the
>PC (so everyone would buy PCs and have windows).  

  No, I'm aware of what Microsoft is trying to do, and it seems what
Microsoft is trying to do is remove the impetus to portable code.  Why write
code to run on multiple systems when hell!  Every {*filter*}y person who uses a
computer uses an Intel x86 processor running Windows 95 or NT so why even
bother writing code that'll never run on any other system anyway?

  Perhaps I'm a bit bitter, having gone through this with not only MS-DOS,
then Unix (All the world's a Sun - blah) and now again with Windows.  It's
not like code is ever ported to other systems, right?

  -spc (Doesn't even HAVE Windows at home ... )



Wed, 02 Feb 2000 03:00:00 GMT  
 
 [ 22 post ]  Go to page: [1] [2]

 Relevant Pages 

1. A Standard to Teach Forth (was Re: Chuck Moore on ANSI)

2. Evolutionary Forth (was: Chuck Moore on ANSI)

3. Chuck Moore on ANSI (was Re: On Saturday July 26)

4. Chuck Moore's Take on ANS Forth

5. Chuck Moore's Color Forth

6. cf. Chuck Moore, VLSI, Forth

7. Chuck Moore and Forth

8. Chuck Moore's 1x Forth

9. Online interview with Chuck Moore!

10. Chuck Moore

11. Chuck Moore to be interviewed on Slashdot

12. Slashdot interview with Chuck Moore

 

 
Powered by phpBB® Forum Software