HDTenEightyP/NetNews huggingface dataset:
From: mbk@lyapunov.ucsd.edu (Matt Kennel)
Newsgroups: comp.lang.eiffel
Subject: Re: creation
Date: 20 Jan 1993 21:33:08 GMT
Organization: Institute For Nonlinear Science, UCSD
NNTP-Posting-Host: lyapunov.ucsd.edu
X-Newsreader: Tin 1.1 PL3

ram@eiffel.com (Raphael Manfredi) writes:
: I think there are some situations where a creation procedure may require a
: postcondition, completing the assertions coming from the invariant. For
: instance, assume you are creating an object representing a Finite State
: Automaton (FSA). You may want to have two or three creation procedures
: to make sure the FSA is put in one of its "begining" states. The postcondition
: would express that the FSA is indeed in the correct state.

I have a basic question here.

How are postconditions useful?  It seems that they express little
beyond the correct functioning of a class feature.

: Note that aside from the fact '!!' involves a run-time call to create the
: object, it also has a semantic meaning: it tells the compiler NOT to check the
: invariant when calling 'o.make' on the newly allocated object. Usually, the
: invariant is checked BEFORE and AFTER a remote call (see OOSC for a detailed
: explaination).

It seems then that you could always write some sort of invariant as
either (object_is_not_initialized) or (regular_conditions).

Also it seems that frequently data structures have "lifecycles", i.e.
initialization, normal_use, and destruction, and that an invariant that
is supposed to be true during normal use doesn't necessarily have to be
so during initialization.

In what way can invariants express relationships between different objects.
That's where the most non-trivial problems seem to come into play.

cheers
Matt
: -- 
: Raphael Manfredi <ram@eiffel.com>
: Interactive Software Engineering Inc.
: 270 Storke Road, Suite #7                      / Tel +1 (805) 685-1006 \
: Goleta, California 93117, USA                  \ Fax +1 (805) 685-6869 /

--
-Matt Kennel  		mbk@inls1.ucsd.edu
-Institute for Nonlinear Science, University of California, San Diego
-*** AD: Archive for nonlinear dynamics papers & programs: FTP to
-***     lyapunov.ucsd.edu, username "anonymous".
Newsgroups: comp.lang.eiffel
From: richieb@bony1.bony.com (Richard Bielak)
Subject: Re: postconditions on creation procedures
Organization: multi-cellular
Date: Thu, 21 Jan 93 13:28:17 GMT

In article <mod.727464101@cs.man.ac.uk> mod@cs.man.ac.uk (Mike O'Docherty (Teaching Company Associate)) writes:
>On page 128 of "Eiffel: The Language", it is stated (in the definition of 
>consistency) that postconditions need not be checked on return from a
>creation procedure. I see no reason why they they should be let off the hook;
>is this a mistake?
>
>Mike.
>

Sounds like a mistake to me also. A creation procedure must establish
the invariant, but it can also have its own pre- and postconditions.
Here is a simple example:

class CHECKING_ACCOUNT 
        creation make

feature{NONE}

        make (initial_deposit:INTEGER) is
                require
                        initial_deposit > 100;
                do
                        balance := initial_deposit
                ensure
                        balance = initial_deposit
                end;

[...stuff ommited...]

invariant

        balance >= 0;

end;


...richie




-- 
* Richie Bielak   (212)-815-3072   |                                          *
* Internet:       richieb@bony.com | Rule #1: Don't sweat the small stuff.    *
* Bang {uupsi,uunet}!bony1!richieb | Rule #2: It's all small stuff.           *
*    - Strictly my opinions -      |                                          *
From: duncan@nic.cerf.net (Ray Duncan)
Newsgroups: comp.lang.forth
Subject: Re: Recent FORTHs' guts  (was: Documenting)
Date: 26 Jan 1993 19:20:46 GMT
Organization: CERFnet Dial n' CERF Customer Group
NNTP-Posting-Host: nic.cerf.net

In article <1993Jan26.141606.12503@exu.ericsson.se> exuhag@exu.ericsson.se writes:
>
>>: More and more I'm discovering one of the reasons for Forth's lack
>>: of popularity is that, while it doesn't have to be used solely for 
>>: embedded systems, there isn't much support outside of that area.
>>
>>I guess this statment will be flamed by the FORTH vendors, who are
>>suppose to 'support [products] outside of that area'.
>
>I'm seriously hoping it will be.

One of the reasons the surviving Forth vendors have concentrated
on embedded systems is that this is one of the few market niches
that has not been systematically destroyed by the FIG-public domain-
hacker cabal.  Now that people like Ting are circulating atrocities
like EFORTH, even the embedded systems market is dying. This is not
a flame, it's just the sad truth.

The Forth community can't have it both ways. It can't have free
Forth everywhere with complete access to source code and rapid 
evolution to support all the latest FORML coding fads-du-jour,
and still have vendors investing serious time in bringing Forth
up on new processors, providing stable programming interfaces
over a period of many years, developing extensive printed documentation,
and deploying man(woman)power to technical support services.  As
far as I know, all the vendors that are still in business are 
selling Forth development environments really as a sideline, and
paying the bills some other way (consulting, hardware development,
whatever). 

It's certainly been clear to me from lurking in this newsgroup for
months that *this* sector of the Forth community, although it
prides itself on being a center of Forth expertise, has no clue
whatsoever as to what the Forth vendors (Forth Inc., LMI, 
Harvard Softworks, Vesta, Creative Solutions, etc.) have to offer
or the capabilities of their systems.  Thus, newcomers to Forth,
who come here for advice, are being steered to EFORTH, FPC, and
other undocumented unstable unsupported public domain Forth systems
as "solutions."  No wonder Forth is in decline!

Harsh words, perhaps, and certainly a vendor-centric viewpoint, but
a viewpoint that has received little attention here.

Ray Duncan, LMI

Newsgroups: comp.lang.forth
From: hoyt@isus.UUCP (Hoyt A. Stearns jr.)
Subject: Echelon
Followup-To: comp.lang.forth
Summary: Forth for Echelon chips?
Keywords: Echelon local operating network chips, forth.
Organization: International Society of Unified Science
Date: Fri, 22 Jan 1993 17:55:07 GMT

Is there a forth available for the Echelon chip sets?
I'm planning to use them in a project with 100 or more nodes, with
their carrier current tranceivers.

Echelon supplies a development system which uses "c", but I could
undoubtedly complete the project faster in forth.  If no forth is available,
then I might write one (which may still make the project duration shorter
then in "c", and post it if there's interest).

Also, are there any Echelon tools that run under unix?

Thanks.

-- 
Hoyt A. Stearns jr.|hoyt@          | International Society of Unified Science|
4131 E. Cannon Dr. |isus.tnet.com -| Advancing Dewey B. Larson's Reciprocal  |
Phoenix, AZ. 85028 |ncar!enuucp!   | System- a unified physical theory.      |
voice_602_996_1717 telesys!isus!hoyt The Universe in two postulates__________|
From: bevan@cs.man.ac.uk (Stephen J Bevan)
Newsgroups: comp.lang.forth
Subject: Re: forth type checker
Date: 22 Jan 93 15:13:33 GMT
	<1993Jan20.093607.20349@email.tuwien.ac.at>
	<1993Jan20.183012.1078@csi.uottawa.ca>
	<1993Jan21.082304.28301@email.tuwien.ac.at>
Organization: Department of Computer Science, University of Manchester
In-reply-to: anton@mips.complang.tuwien.ac.at's message of 21 Jan 93 08:23:04 GMT

In article <1993Jan21.082304.28301@email.tuwien.ac.at> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
   somebody writes:
   |> I mildly disagree: "strong" tends to refer to systems that attempt to
   |> forbid the type errors; the fact that they aren't PERFECTLY strong
   |> doesn't deny the ATTEMPT.  "Weakly" typed languages tend either to
   |> either enforce few or no type errors.

Unfortunately, the above makes no distinction between compile and
run-time and so the attributes "strong" and "weak" have very little
meaning.

   That would be alright, if the terms were used with these meanings.
   Unfortunately they aren't. Pascal, which (as usually implemented) has
   holes in it's type system, is usually called strongly typed, whereas
   Lisp, which has no holes, is usually called weakly typed (and some
   people even call it untyped).

Which just shows that we are in a sorry state wrt categorisation of
languages.  All the rest of this is with a big IMHO :-

Lisp is a strongly, latently typed language, whereas Pascal is
generally a strongly, statically typed language.  This means that they
both ensure type safety, but Lisp does it at runtime whilst Pascal
generally does it at compile time.  The "hole" such that it is in the
Pascal type system is in the _static_ type system, not the type system
in general.  I don't have the standard to hand, but the VDM definition
of Pascal that I have in front of me does ensure that at runtime you
are not allowed to access a field of a variant record unless the tag
type is correct.  As to "untyped" languages i.e. languages which
generally don't enforce any type constraints, the only ones I can
think of are BCPL and FORTH.

These categories are not mutually exclusive and there is considerable
scope for bluring around the edges.  This mainly happens where the
language doesn't have a standard (or the standard is written in a
"natural" language) and so it is difficult to separate the language
from its various implementations.

bevan
Newsgroups: comp.lang.forth
From: bible@iastate.edu (Anthony E Bible)
Subject: Re: POINTLESS OBSERVATION: "Forth" in subject line
Organization: Iowa State University, Ames, IA
Date: Wed, 27 Jan 1993 15:15:47 GMT

In article <piggy.728131714@newsroom.utas.edu.au> piggy@hilbert.cc.utas.edu.au (La Monte Yarroll) writes:
>Feel free to flame this abuse of the Net.  It's late and my code still
>doesn't work :-(.
>
>Every time I read comp.lang.forth, I notice that an EXTRAORDINARY
>number of subject lines mention the word "Forth".
>

[stuff deleted]

>
>Why does this happen?  Do forth users have a greater devotion to the
>name of their language than lisp users?  Does everybody cross-post to

Onomatomania.  I hope this fixes your code.

Regards,
tony
Newsgroups: comp.lang.forth
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Subject: GNU Emacs and Forth (Was: What's wrong with screens)
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Wed, 27 Jan 1993 10:05:05 GMT

In article <1k57vqINNjgk@transfer.stratus.com>, nick@sw.stratus.com
(Nicolas Tamburri) writes:
|> penev@venezia (Penio Penev) writes:
|> > I use GNU emacs to write these lines. It has its virtues. But if I
|> > wanted to write a FORTH-major-mode, It would have to mimic my FORTH
|> > editor. So why bother?
|> 
|> If you used text files, you wouldn't have to bother.  Text mode works just fine
|> for Forth, (although a major mode wouldn't hurt.)

There actually is a forth mode for GNU emacs and you can find it in
the TILE distribution (ftp from a GNU archive site). IMO it needs a
bit more work.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
Newsgroups: comp.lang.forth
From: larry@tsd.arlut.utexas.edu (Larry Maturo)
Subject: Use of Forth
Organization: Applied Research Labs, The University of Texas at Austin
Date: Thu, 28 Jan 1993 17:31:37 GMT

I was reading An OPS5 Primer on the rule-based expert system OPS5.  It had an
introduction to AI and in the intro was:

DELTA - A rul-based expert system developed by General Electric to help in the
diagnosis and repair of diseal locomotives.  ... This rule-based expert system
has taken the knowledge of a locomotive expert who has spent 40 years in the
field and encapsulated it into a program that the mid-level locomotive mechanic
can access. ... DELTA was developed in LISP and ported to FORTH (an efficient,
stack-oriented programming language).  It has approximately 1200 rules.

The above is all a direct quote (with parts left out for brevity).

Thought this might be of interest.


+-----------------------------------+----------------------------------------+
|                                   |                                        |
| Larry Maturo                      | Opinions expressed herein must be      |
| Tactical Simulation Division      | yours, neither I nor my employer have  |
| Applied Research Laboratories     | any.                                   |
| University of Texas at Austin     |                                        |
| P.O. Box 8029                     +----------------------------------------+
| Austin, Texas 78713-8029          |                                        |
|                                   | When you're as great as I am it's hard |
| larry@titan.tsd.arlut.utexas.edu  | to be modest, but I succeed where      |
|                                   | others fail.                           |
+-----------------------------------+----------------------------------------+
From: duncan@nic.cerf.net (Ray Duncan)
Newsgroups: comp.lang.forth
Subject: Re: Forth's Adaptability
Date: 23 Jan 1993 03:29:25 GMT
Organization: CERFnet Dial n' CERF Customer Group
NNTP-Posting-Host: nic.cerf.net

In article <BEVAN.93Jan22131846@panda.cs.man.ac.uk> bevan@cs.man.ac.uk (Stephen J Bevan) writes:
>In article <1jk69lINNhjo@news.cerf.net> duncan@nic.cerf.net (Ray Duncan) writes:
>   It is a mistake to judge the "Forth community" by the public
>   domain implementations of Forth.  People who insist on using
>   public domain Forths and reinventing the wheel time after time
>   get what they paid for.
>
>Agreed, but :-
>
>   [ LMI FORTH has files & blocks, floating point ... etc. ]
>
>   they've [LMI users] had access to these capabilities, if they
>   needed them, for many years.    
>
>And I'm sure they are happy with them, but consider what happens if
>they decide, for one reason or another, that they don't want to use
>LMI FORTH anymore, but prefer to use a different vendor's system.
>What are they to do with all the code they've developed using LMI
>specific extensions?  Unless the "extensions" are either standard or
>defacto standards then there may be significant effort involved in
>changing the code, so much so you may have to stick with the system
>you have even though you know you can get better/cheaper elsewhere
>(I've suffered just this situation with large amounts of code written
>using VAX FORTRAN + extensions).  This is good for vendors since it
>keeps users locked into their system, but it is definitely not a good
>deal for users.

I must admit I don't quite see your point.  At the time we added
these capabilities to our systems, they were relatively novel in
the Forth world.  Certainly, nothing in the standards of the time
(polyForth, Forth-79, Forth-83, figForth) spoke to these issues.
Does that mean our users should have gone without these capabilities
until the Forth standards-body-du-jour got around to codifying
these capabilities?  Forget it!  I could just as easily make the
argument that the reason the ANSI committee is in a position to
standardize file management, memory management, floating point,e tc.
is that companies like LMI (and their customers) were willing to
prove the usefulness of these capabilities in real-world
applications.
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: LMI Forth(s)
Date: 25 Jan 93 11:18:47 GMT
Organization: EIEI-U

Category 7,  Topic 23
Message 169       Sun Jan 24, 1993
ELLIOTT.C                    at 10:00 EST
 
 -----via CRS Premium Bulletin Board -
 USR Dual Standard 16.8K  (416) 629-7000

 Date: 01-21-93 (20:29)
   To: RANDY YOUNG
 From: RAY DUNCAN
 Subj: WINFORTH

 You can contact LMI at (310) 306-7412, or via our BBS at (310)
 306-3530,or send us a FAX at (310) 301-0761.

 The 16-bit version of WinForth is shipping, and the 32-bit
 version is well along. We hope to release the 32-bit version
 (which will be WIN32S and thus able to run on either Windows 3.1
 or on Windows NT) around the middle of 1993.

 NET/Mail : LMI Forth Board, Los Angeles, CA (310) 306-3530
 ---
  * The GrapeVine/Ferret Face BBS * NLR,ARK * 501-753-8121 DS *
  * PostLink(tm) v1.04  GRAPEVINE (#318) : RelayNet(tm) Hub


-----
This message came from GEnie via willett.  You *cannot* reply to the author
using e-mail.  Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Subject: Re: Recent FORTHs' guts  (was: Documenting)
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Mon, 25 Jan 1993 14:55:39 GMT

In article <1993Jan23.122739.24899@sol.ctr.columbia.edu>, penev@venezia (Penio Penev) writes:
|> I think, that when one designes a FORTH for a machine with a lot of
|> memory, native code is the better way. It's faster, while not wasting
|> much. On a i386 one have 4-byte 'address' and a 5 byte 'call address'.
|> Well, it's not like having 15 bit 'address' and 16 bit 'call address'
|> like in RTX, but it's still tolerable.

Note that just doing subroutine threading usually makes your system
slower (than direct threading). You have to go native code, i.e., add
inlining and optimization, to reap the benefits.

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
Newsgroups: comp.lang.forth
From: Nick_Janow@mindlink.bc.ca (Nick Janow)
Subject: uP21
Organization: MIND LINK! - British Columbia, Canada
Date: Sat, 23 Jan 1993 09:21:46 GMT

ahaley@eoe.co.uk (Andrew Haley) writes:

> He's [Chuck] much more inclined to spend time working on the
> uP21, his new processor.

uP21?  What happened to the uP20?

Is he never going to actually release a processor for commercial
use?

--

Nick_Janow@mindlink.bc.ca
Newsgroups: comp.lang.forth
From: penev@venezia (Penio Penev)
Subject: Re: Documenting
Organization: Rockefeller University
Date: Wed, 27 Jan 1993 03:11:00 GMT
X-Newsreader: TIN [version 1.1 PL6]
Reply-To: penev@venezia.rockefeller.edu
X-Posted-From: venezia.rockefeller.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

ForthNet articles from GEnie (ForthNet@willett.pgh.pa.us) wrote:
: Category 3,  Topic 3
: Message 99        Tue Jan 26, 1993
: G.LEFAVE [Gene]              at 06:02 EST
:  
: > Building a nucleus to use a particular shared library or a combination
:  > of them is no more than 5 min work in the beginning of the development
:  > of Your application. This ideology should work quite well with all
:  > breeds of Unix which support shared libraries.
: 
: If there was ever a topic for Forth Dimensions this has to be it! Will this
: work with DOS?

I don't know whether DOS uses shared libraries. I know Linux uses
them. The necessity to connect to shared libraries never arose to me
while I was working under DOS. The used mechanism there was to connect
through user-installed interrups. I DOS uses shared libraries though,
I think, that one can connect to it. The trick, which I use, is to
write an empty C program, which declares enough space for FORTH's
nucleus (I put this in the .data segment) and for the dictionary later
( in the .bss segment). If You are willing enough You could use the
malloc function of C for space management.

I implemented this under IRIX (a Unix flavour). I'll have to implement
it for Linux soon, because I'm buying a PC. If anybody is willing to
try for smth. else, I can provide my experience along with some code.

-- Penio.
Newsgroups: comp.lang.forth
From: johnch@test22.sun.com (Sam the Skank from Geezer)
Newsgroups: comp.lang.forth
Subject: anyone get Tile forth to work?
Date: 22 Jan 93 18:33:51
Organization: Impossible Missions Force
Distribution: comp
NNTP-Posting-Host: test22


I got the Tile forth distribution, compiled and installed it, and it
seems to work fine with trivial definitions, but it chokes on all the
example code that comes with the distribution.  The first problem it
has with every file is when it encounters the word, "#include", in a
context like, "#include foo.f83".  I guess either I am supposed to run
all these files through cpp first or there is supposed to be a word
"#include" defined somewhere that does something analogous to "LOAD".

Anyone get any farther?

-- John C
Newsgroups: comp.lang.forth
From: rob@maccs.mcmaster.ca (Rob McDonald)
Subject: Forth for NEC uPD75000 Family Processors
Followup-To: rob@maccs.dcss.mcmaster.ca, or comp.lang.forth
Summary: Is there one now?
Keywords: NEC 75028 75036 forth microcontroller
Organization: Department of Computer Science, McMaster University
Date: Mon, 25 Jan 1993 12:47:57 GMT

Has anybody ported forth to any of the NEC uPD75000 series microcontrollers?
I am using the uPD75028 and uPD75036 controllers for a series of projects,
and would prefer to work in Forth.  Any pointers to a source for this would
be appreciated.
.....rob
EMAIL:   rob@maccs.dcss.mcmaster.ca     <<< Standard Disclaimers Apply >>>
From: eaker@ukulele.crd.ge.com (Chuck Eaker)
Newsgroups: comp.lang.forth
Subject: Re: Documenting/Adaptability @#%&
Date: 21 Jan 93 15:51:32 GMT
Organization: GE Corporate R&D Center

In article <1993Jan21.082208.93@wronz.org.nz>, mentink@wronz.org.nz writes:
|> 
|> 	I have been reading this section for months now and am rapidly
|> being turned off by the inane bickering on the subjects of documentation
|> and adaptability of Forth.
|> 
|> Woudn't it be a far more productive ( and less painfull to the soul ) to
|> swap ideas, help each other out on problems struck etc, than to put up with
|> one or two individuals ( with little better to do ) flaming each other
|> on the network?.
|> 

I don't think that being turned off by something is a good
reason to call for others to avoid it. The recent thread
about Forth for the 8051 is a topic about which I have
absolutely no interest. It is, however, an example of
swapping ideas and helping each other.

I submit that the documenting/adapatability discussions
perform the same two roles for those engaged in them.
They are certainly examples of swapping ideas. And they
have certainly helped me refine my views about these
issues.

The point of a subject line is to allow you to skip over
articles on topics that turn you off.  I suggest that you do
that rather than ask the rest of us to conform to your
preferences.

(And you're right. At the moment I don't have anything better
to do than flame you over the network. I've got to get a life.)

-- 
Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA
eaker@crd.ge.com        eaker@crdgw1.UUCP       (518) 387-5964
Newsgroups: comp.lang.forth
From: rolfe@fraser.sfu.ca (Christopher John Rolfe)
Subject: +LOOP in JFORTH
Organization: Simon Fraser University, Burnaby, B.C., Canada
Date: Mon, 25 Jan 1993 09:53:37 GMT

	What's the deal with 'DO' and '+LOOP' in JFORTH?
	Normally it's
	: myword limit index DO increment +LOOP ;
If you want a loop to decrement with '-1 +LOOP', in some FORTHS you
have to put a  strange number in limit ( as in EMACS where the loop
always ends at the boundary between 'limit' and 'limit minus 1' ).  
But in JFORTH I can't seem to get a decrementing loop at all.  Perhaps there
is an error check to see if index is less than limit?  But then WHY
have the word '+LOOP'???

Puzzled.
-- 
Chris                   | 2617 East 4th,| [047] [037] 
rolfe@sfu.ca            | Van., B.C.    | that serial, major/minor, 
Simon Fraser University | V5M 1K5       | tonic/subdom, inversion
Burnaby,  Canada        | Canada        | thing is hurting my brain.
Newsgroups: comp.lang.forth