HDTenEightyP/NetNews huggingface dataset:
From: Ted.W.Lawson@cm.cf.ac.uk (Ted Lawson)
Newsgroups: comp.lang.eiffel,uk.events,comp.object,uk.announce
Subject: UK & Ireland Eiffel Interest Group, 3rd Seminar, Eiffel & Databases
Date: 10 Sep 92 14:03:49 GMT
Organization: University of Wales College of Cardiff, Cardiff, Wales, UK.
X-Mailer: Cardiff Computing Maths PP Mail Open News Gateway


	Eiffel Interest Group of UK and Ireland

		3rd Quarterly EIG Seminar

	Relational Databases vs 00 Databases

	Wednesday, 23 September, 1992 - 14:00 to 17:00

	University of the West of England, Bristol
	(formerly Bristol Polytechnic)

	Coldharbour Lane, Frenchay, Bristol, BS16 10Y, UK

13:30			Registration

14:00 - 15:00	Gary Mumford, Applied Logic Developments
		Topic: Relational Databases

15:00			Refreshments

15:15 - 16.15	Wayne Harris, University of the West of England
			Topic: Object-oriented Databases

16:15			Question and Answer Session

			Panel to include
			Wayne Harris, University of the West of England
			Gary Mumford, Applied Logic Developments
			Tom Carnduff, University of Wales
			Simon Parker, Independent Consultant

17:00			Close of Seminar


The fee is STG 10.00 per person for EIG Members, and STG 20.00 per person
for non-members and will include refreshments during the afternoon.
Non-members will have the opportunity to join the EIG on the day, and
take advantage of the membership entry fee.

To register, please complete (in block capitals) and return this form
to the address shown below, together with a cheque for the appropriate
amount made payable to the Eiffel Interest Group. Please photocopy if
more than one representative from your company would like to attend.

Name......................  Organisation.........................
Address........................................................
...............................................................
Tel: ..........................................................

EIG Membership No:.............................................

I enclose a cheque for STG........and look forward to receiving
confirmation of my place and directions.

Return to: A. Upperton, EIG, 9 Princeton Court, 55 Felsham Road,
London SW15 1A
Tel: 081 780 1088, Fax: 081 780 1941.
Newsgroups: comp.lang.eiffel
From: wbtt001@dutrun2.tudelft.nl (E. Maryniak)
Subject: (ISE-) Eiffel experiences on PC's
Originator: wbtt001@dutrun2.tudelft.nl
Keywords: ISE Eiffel, PC, Unix, performance, graphics
Reply-To: wbtt001@dutrun2.tudelft.nl (E. Maryniak)
Organization: Delft University of Technology
Date: Wed, 9 Sep 1992 07:54:23 GMT


I would like to hear about experiences with Eiffel on PC's (>= 386) under
one of the Unix-es for which ISE Eiffel is supported (ie. SCO Unix, SCO ODT,
Esix, Interactive Unix, others?): performance, compile-times, size of execu-
tables, re-use possibilities of ISE libraries (esp. graphics (X)) and others,
user-friendliness, etc.
Concrete question: which Unix should I put on my 33Mhz, 16/210 MB 486 (IDE-bus)
in order to run ISE Eiffel (2.3, later 3.0) optimally ?

Thanks !

Eric Maryniak
e-mail: ericm@dutw34.tudelft.nl
From: wesley@pws.ma30.bull.com (Wesley Dunnington)
Newsgroups: comp.lang.eiffel
Subject: Are there any public domain implementations of Eiffel Available?
Keywords: eiffel public domain
Date: 11 Sep 92 15:55:21 GMT

I would like to start learning eiffel so I need a compiler. Are there any
free or low cost implementations of the Eiffel compiler out there?

Thanks
Wesley Dunnington

--
==============================================================================
++Wesley Dunnington                       phone: (508)-294-6149
Bull Worldwide Information Systems        fax:   (508)-294-6109
Billerica, MA                             (at work): wesley@pws.ma30.bull.com
From: nick@sw.stratus.com (Nicolas Tamburri)
Newsgroups: comp.lang.forth
Subject: Re: Forth in the Marketplace
Date: 14 Sep 92 17:51:33 GMT
Organization: Stratus Computer, Inc.


> S.BAKER41 [S.E.Baker]        at 18:04 EDT
>  
> > FLOATING POINT default with a toggle words called FLO and INT.
> 
>         That would be ok but I would suggest a simpler answer.  For the
> beginner it would be great to simply have floating point words; "ADD", "SUB",
> MUL", "DIV" and maybe "SQUARE", "SQROOT", etc.  Yes, I know that this is very
> "COBOL-like" -- deliberately so.  If you can make a COBOL programmer
> comfortable with a transition into Forth then you will see the language gain
> acceptance.  Converting him to more brief words can be accomplished later.

Forth generally does as you state, except that the usual names are F+ , F- etc.
I believe the original statement had to do with numeric input from the
keyboard or files being converted to floating point numbers automatically.
(Correct me if I'm wrong, someone.)

I kind of like the idea of having a float or integer input mode, but I would
modify the above suggestion to only convert to floating point if a decimal
point appears in the number, (ala double precision numbers.)  Double precision
numbers are becoming somewhat less useful as 32-bit Forths running on platforms
with FPUs become the norm.

> >                    RPN is controversial
> 
>         Why?  I see no reason for this to be a problem.  It is easily learned
> and the value becomes obvious to anyone who learns the use of stacks.

One of our favorite time-wasters way, [way, way, ...] back in college was
which company made better calculators, Texas Instruments or Hewlett-Packard.
More people bought TI because H-P were RPN based.  You have to pity those
TI people, but facts are facts.

> > and then compile it.  Type RPN and you simply go back to usual
>  > RPN entry.
> 
>         Please don't waste time worrying about this!  There are far bigger
> holes in Forth that simply MUST be plugged before it is a "language".  Right
> now, IMO, Forth is a piece of a language.  I won't be able to make use of it
> until it becomes whole.

Please don't waste time, is right. Dick Pountain published a rudimentary Algebraic
Notation input parser in BYTE a couple years back.  It looked pretty portable
and extensible for anyone sick enough to want to use it.  :-)

							/nt
From: xtifr@netcom.com (Chris Waters)
Subject: Re: Sampler Forth
Date: Wed, 09 Sep 92 17:39:28 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

In <11041@minnie.informatik.uni-kiel.dbp.de> uho@informatik.uni-kiel.dbp.de (Ulrich Hoffmann) writes:

>In this sense, a 'smudge' bit becomes really nasty, since not FIG, nor F83/F-PC
>allow for full 8-Bit characters in word names :-(.

FIG and F-PC may use the "smudge" bit, but it's not a requirement of the
Forth 83 standard by any means.  In fact, you can even have a fairly
traditional header without it.  If you eliminate the FIG concept of
"WIDTH" (so the header always has all the characters saved), you can get
from anf to alf with "COUNT +".  And if you restrict the characters in a
name to BL or greater, and the count to 31 or less, you can easily test
for the length byte when going from alf to anf (31 <).
-- 
Chris Waters    | the insane don't | NOBODY for President!
xtifr@netcom.COM| need disclaimers | Because Nobody's perfect!!
From: esj@harvee.billerica.ma.us (Eric S Johansson)
Newsgroups: comp.lang.forth
Subject: Re: Forth will Replace C
Date: 12 Sep 92 19:04:12 GMT
Reply-To: esj@harvee.billerica.ma.us
Organization: gators 'r us
X-Software: HERMES GUS 1.03 Rev. Apr 14 1992

In <4052.UUL1.3#5129@willett.pgh.pa.us>, Doug Philips writes:
>But I like the idea of the contest.  Would you want to restrict it to a
>particular dialect of Forth?

YES! ANS forth! :-)

--- eric
-- 
HOME: esj@harvee.billerica.ma.us  HAM  ka1eec
WORK: 617.630.4687 (w)   esj@ruby.polaroid.com
source of the public's fear of the unknown since 1956
Newsgroups: comp.lang.forth
From: dak@kaa.informatik.rwth-aachen.de (David Kastrup)
Subject: Re: AI in Forth
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen
Date:  9 Sep 92 15:53:22 GMT

kormann@watson.bms.com (JOSEPH KORMANN (X3167 LAWRENCEVILLE)) writes:

>Hi. I'm most likely to be flamed out of my mind for this one but:

>    What does anyone think of the (as I see it) the natural ability to adapt 
>Forth to AI? Being it's the only bottom-up language that I know of and it's 
>the only language that's built to be self-referencing, it seems like a logical 
>selection to me. (or am I barking up the wrong binary-tree?)
Self-referencing? Well..., in what respect?
In case you have not heard, there is a language which can be employed
bottom-up, and is quite clearly self-referential. It is called Lisp.
Naturally, its importance in AI fades beside that of Forth...
Newsgroups: comp.lang.forth
From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl)
Subject: Re: Forth will Replace C
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Tue, 8 Sep 1992 07:47:16 GMT

In article <1992Sep5.150256.17881@mintaka.lcs.mit.edu>, mikc@hal.gnu.ai.mit.edu (Mike Coughlin) writes:
|>  I do think that Forth will
|> attain the popularity of C.
 
It will even surpass the popularity of C. This will happen as soon as
99% of the C programmers will have switched to C++ :-\

- 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
From: mikc@hal.gnu.ai.mit.edu (Mike Coughlin)
Newsgroups: comp.lang.forth
Subject: Re: Free Forth
Date: 5 Sep 92 15:12:45 GMT
Organization: /etc/organization

In article <BtCvML.Lzu@starnine.com> mikeh@starnine.com (Mike Haas) writes:
>
>The trend is more & more memory in the machine, so what do I care
>if a Forth takes up 100k or 500k if I have Megs to work with?
>

   A small Forth fits in a human mind better than a big one. You can
do more with a system that you understand very well than you can with
a big system that you don't understand. Forth works very well in a
small space since it uses a few good ideas put together in a clever
way. It is a much better way to do things than filling up all
available memory with more code than a single person can comprehend.
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: ANS TC Magnet for Interpreter
Date: 4 Sep 92 11:20:48 GMT
Organization: EIEI-U

Category 10,  Topic 24
Message 51        Thu Sep 03, 1992
ELLIOTT.C                    at 12:08 EDT
 
 -----via CRS Premium Bulletin Board

 Date: 08-29-92 (03:04)
   To: JACK WOEHR
 From: MARCEL HENDRIX
 Subj: SEMICOLONING PATTERN HER

 jw> ; was broken by an ill-considered change to DOES>

 Ok. I looked it up. They added a line to the definition of DOES>
 : ``Whether or not the current definition may be found in the
   dictionary after DOES> is implementation defined.''

 I'd expect the current definition to be the definition that is
 being built when DOES> *executes* , but this is hardly useful (
 for BanzaiForth equivalent to VARIABLE ans  FORGET ans ).

 Thus the ``current definition'' is the definition X that is busy
 compiling the word DOES> . But surely it can never be
 ``implementation defined'' wether X can be found in the
 dictionary: it *must* be findable. ( uh... unless  :NONAME ..
 CREATE .. DOES> ... ; )

 I guess they're trying to say you can't use DOES> together with
 RECURSE and expect unambiguous results?

 BTW BTW articles.
 Just let me know which articles you want (better: FD wants :-) )
 and we'll contact the author. We can arrange translation too.
 But we very much appreciate it that you seem prepared to handle
 some of the details for us, and be our champion!

 jw> FORTH Dimensions, a genuinely international magazine
 Why doesn't it have a specially assigned editor that scans
 the Figs in outer space?
 I didn't get much European response yet (only Germany and UK),
 but 50% of it looked professional.

 Marcel Hendrix,
 Secretary Dutch FIG (for parts of this message).

 PCRelay:OLEF -> #181 RelayNet (tm)
 4.11            OLEF BBS London England. +(44)-81-882-7353


-----
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
Newsgroups: comp.lang.forth
From: anton@mips.complang.tuwien.ac.at (Anton Martin Ertl)
Subject: Re: cross compilers
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Tue, 15 Sep 1992 09:23:17 GMT

In article <memo.627478@cix.compulink.co.uk>, spelk@cix.compulink.co.uk (MPE Ltd) writes:
|> Right, except that "metacompiler" is misnomer that should be avoided.
|> A metacompiler produces a compiler for another language. Metacompiler
|> is the general term for tools such as YACC, and Forth cross compilers
|> do not yet perform that task. I use the term cross compiler as the
|> general class. The term target compiler is sometimes used for cross
|> compiler.

I have never seen yacc called a metacompiler, only as compiler
compiler (And it really is only a parser generator :-).

I'm somewhat uneasy about the term metacompiler myself, but it seems
quite appropriate: Interpreters for LISP and Prolog that are written
in LISP and Prolog respectively, are called metainterpreters (You ask
what metainterpreters are good for? You change them slightly, and you
get a debugger, or a different language etc.)

- 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: int452w@lindblat.cc.monash.edu.au (Michael R. Geddes)
Subject: Re: Sampler Forth
Organization: Monash University, Melb., Australia.
Date: Mon, 14 Sep 1992 23:55:17 GMT

Nick_Janow@mindlink.bc.ca (Nick Janow) writes:

>> (a) Forth is NEVER  going to be the fastest executing language.

>That's not necessarily true.  If Forth had the support C has, it would also
>have nice systems with Forth CPUs, and I think for equal investment in hardware
>and programming time, the application in Forth would run a lot faster.

I agree with this, but also, I have been told that better hardware can often
give you a reasonable increase in speed, but better algorithms give you an 
order of magnitude increase in speed.  Forth is 'slow' on most systems 
because of the forth 'engine' that goes between machine code and forth code.. 
Forth is 'fast' because you can code all the critical bits with an efficient
algorithm (not just by putting it into assembler, you don't always get small 
critical bits.).

Michael

-- 
Michael Geddes                         int452w@linblat.cc.monash.edu.au 
-----------------------------------------------------------------------
A blink, I think, is the same as a wink, But a blink is a wink that grew.
For a wink you blink with one eye, and a blink you wink with two.
Newsgroups: comp.lang.forth
From: mikeh@starnine.com (Mike Haas)
Subject: Re: Sampler Forth
Date: Fri, 11 Sep 1992 22:06:53 GMT
Organization: StarNine Technologies, Inc.

In article <11041@minnie.informatik.uni-kiel.dbp.de> uho@informatik.uni-kiel.dbp.de (Ulrich Hoffmann) writes:
>In <4303@wet.UUCP> jpeters@wet.COM (John A. Peters) writes:
>
>>DOCUMENTATION; Use the resources of the machine!  The compiler
>>doesn't do anything with numbers above 127, so use control-C to
>>toggle the high-order bits to 1 and all incoming bytes are 128 or
>>above and are ignored by the compiler.  They can be used for
>>comments.  On the screen they're dimmer; the printer outputs then
>>as italics. I (Jerry Mueler) did all this a couple of years a go. 
>>Type control-C again and you're back into normal forth input.
>
>So you probably don't speak any foreign languages? 
>
>7 Bit Ascii is just not enough to hold all our native (you may call them foreign)
>characters (such as German Umlauts). 
>
>Unfortunately even this mail software insists on using only 7 bits, 
>so I can't show you any of these, now.
>
>Yes - we use these letters!  
>Yes - we have special keys on our keyboards to produce them.
>
>Please DO NOT use the extended ASCII character set for any other purpose than 
>representing literal characters!

ABSOLUTELY!  And it's not just foriegn language concerns, either.
Modern computing platforms use the entire 8-bit range to represent
characters.  Two of the most common on Mac and Amiga are the
registered trademark & copyright characters.

It is hard to believe that in 1992, there are still those who think
that $80-FF is available to do with as they will.

And if we talk foriegn character sets, be aware that some standards
require TWO bytes to represent one visible character!  It would be
good for the Forth community to start considering these things.

>
>In this sense, a 'smudge' bit becomes really nasty, since not FIG, nor F83/F-PC
>allow for full 8-Bit characters in word names :-(.

As far as I know, the only reason this limitation was in effect
was to facilitate TRAVERSE.  The count byte and the last character
had their top bits set.

This is not satisfactory, as the rest of the world has determined
there are more valid uses for that bit.
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Forth in print
Date: 9 Sep 92 12:17:32 GMT
Organization: EIEI-U

Category 4,  Topic 7
Message 144       Tue Sep 08, 1992
E.RATHER [Elizabeth]         at 23:46 EDT
 
The book in question, which makes a "Forth" in C++, is by Norman Smith, who
has been around Forth a long time.
-----
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: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: ANS FORTH TECHNICAL COMMITTEE
Date: 1 Sep 92 11:08:09 GMT
Organization: EIEI-U

Category 10,  Topic 2
Message 171       Mon Aug 31, 1992
E.RATHER [Elizabeth]         at 23:50 EDT
 
Thanks to Anton Ertl for publishing the info about electronic availability of
dpANS LISP.  I  will pursue this at once and see what we can do.  I made a
plea last January at one of their meetings about this, and they promised to
pursue it.  Looks like progress is being made.
-----
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
Newsgroups: comp.lang.forth
From: spelk@cix.compulink.co.uk (MPE Ltd)
Subject: cross compilers
Reply-To: spelk@cix.compulink.co.uk
Date: Tue, 15 Sep 1992 00:04:00 +0000

 
>The first step in standardising cross compilers should be to write
>a clear explanation of how a cross compiler works and publish code
>that does it in an efficient manner.  We will know the code is good
>when it gets copied into various new Forth systems.
 
>>Sorry, I have to disagree with this.  This seems to be saying that
>>we should have one cross-compiler, period....which would by default
>>be standard!  I'd rather see variety in cross-compiler approaches.
 
Then we would have to standardise their features. In practice the
Forth source code to be passed through a cross compiler is
standardised by the standard/dialect being used. Any deviation
from this is usually recognised as a deviation or failure by
both the author and the user. Most of us who develop cross
compilers work hard to minimise these deviations. I will find
it hard to summon any enthusiasm for standardising what are quite
rightly regarded as implementation deficiencies.
 
It is only the control of the cross compiler that could be
standardised. For example how do you define the base address of the
output.
   addr ROM-BASE
   addr n ORG/DB
   addr ROM-ORG
have all been used. How are named labels defined? How are equates
handled. Since I hear many statements that Forth has a major role
to play in the embedded systems area, which is the domain of cross
compilers for many users, surely the ANSI committee is neglecting
a substantial proportion of users by choosing not to consider thes
issues for the moment. Perhaps the major cross compiler vendors
(MPE, LMI, Forth Inc ...) may care to prpare a joint submission?
MPE would be willing to coordinate this.
 
The next step would be to standardise assembler syntax -
assembler facilities are VERY important when cross compiling
a kernel. For example, even within an 8086 assembler the following
may be found between Forth implementations.
   MOV AX, # 0100
   MOV AX, 0100
   MOV AX 0100
   AX, 0100 MOV
   AX, # 0100 MOV
   # 0100 AX MOV
Trying to standardise that many variants across twenty or thirty
processors is an udesirable task.
 
>BTW, I think Stephen Pelc has devised a useful nomenclature
>for metacompilers:
>a "cross-compiler" can produce code for a different CPU.
>A "recompiler" --
>e.g. Pygmy -- can simply regenerate the kernel for the host CPU;
>it can't produce code for a new CPU.
>I think "metacompiler" is the general class.  (Please correct me if
I'm
>wrong, Stephen.)
 
Right, except that "metacompiler" is misnomer that should be avoided.
A metacompiler produces a compiler for another language. Metacompiler
is the general term for tools such as YACC, and Forth cross compilers
do not yet perform that task. I use the term cross compiler as the
general class. The term target compiler is sometimes used for cross
compiler.
From: ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Forth in the Marketplace
Date: 9 Sep 92 12:17:30 GMT
Organization: EIEI-U

Category 2,  Topic 11
Message 122       Tue Sep 08, 1992
E.RATHER [Elizabeth]         at 23:42 EDT
 
Mueller and SV-FIG presented some interesting ideas, although I have
reservations about whether concealing fundamental concepts e.g. postfix
notation  is the way to present it successfully. If people want to use BASIC,
they can and will.

But I am intrigued by the concept of a shell like a set of training wheels
that could go on top of various implementations. Rather than develop "yet
another Forth" with these characteristics, it seems like a great idea to
present it as a shell, much like some of the UNIX shells that helped overcome
some of its more obnoxious features a few years ago.
-----
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