HDTenEightyP/NetNews huggingface dataset:
From: tobbe@erix.ericsson.se (Torbj|rn T|rnkvist)
Subject: Re: Practicality of functional and logic languages?
Nntp-Posting-User: tobbe
Reply-To: tobbe@erix.ericsson.se (Torbj|rn T|rnkvist)
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Date: Tue, 12 Jan 1993 14:11:58 GMT
Keywords: functional, design

Mirek Benes <benes@dcse.fee.vutbr.cs> writes:
> I would like to know some opinions concerning functional and logic
> programming languages (Haskell, Miranda, ML / Prolog) and their practical
> usability for programming: 
> 
> [How useful are they for practical work?]

The functional, real-time language: Erlang, developed at the Ellemtel
Computer Science Lab has been used, among other things, for implementing
telephony applications. For more information read these two papers that
were presented at ISS-92 in Yokohama:

1. 'A Switching Software Architecture Prototype Using 
   Real Time Declarative Language', M.Persson,K.Oedling,D.Eriksson

2. 'Prototyping Cordless Using Declarative Programming',
   A.Danne,John-Olof Bauner

|> * Are there any (comercially?) successful applications ...

Erlang will be used in commercial applications.

|> * How effective these applications are comparing with applications 
|>   written in classic procedural languages like Pascal?

It is impossible to give any general figures, it differs to much between
different applications. The interesting question is: Is it enough for the
application in question ? . For Telephony, the capacity of Erlang of today
is enough.
 
|> I want to start courses of these programming styles at the university, 
|> so any opinions on the subject will clear up my situation.

It should be possible to receive an Erlang- acedemic/research license
for free (send a mail to erlang@erix.ericsson.se if you are interested).
-- 
/Tobbe (tobbe@erix.ericsson.se)
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: martin@bdsgate.com (Martin Harriss)
Subject: Re: Another Compiler book to add to the FAQ
Reply-To: martin@bdsgate.com (Martin Harriss)
Organization: Beechwood Data Systems
Date: Mon, 11 Jan 1993 18:13:57 GMT
Keywords: books, interpreter, comment

Paul Robinson (TDARCOS@MCIMAIL.COM) wrote:
:    Writing Interactive Compilers and Interpreters
:    by P.J. Brown

I'll second this on being a great book.  It actually promotes sound
software engineering principles as much as it deals with compiler witing.
It's one of the favourite books in my library.

I was fortunate enough to be taught by Pete Prown when I was at Kent.
His courses were always popular, and a very enjoyable - and usually
entertaining - experience.

Martin Harriss
uunet!bdsgate!martin
[It turns out only the hardcover edition is out of print; the paperback is
still available from Wiley for $33. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
Newsgroups: comp.compilers
Subject: Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code
Keywords: optimize, performance, debug
Date: 12 Jan 93 00:57:55 GMT
Article-I.D.: comp.93-01-068
Reply-To: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
Organization: The Johns Hopkins University CS Department

nickh@CS.CMU.EDU (Nick Haines) writes:
> 4. Use of a language with a good type system eliminates the
> edit-compile-bomb-edit cycle, ... Typechecking is (in general) much
> faster than compilation because it includes no optimisation or code
> transformations.

In article <93-01-065@comp.compilers> jlg@cochiti.lanl.gov (J. Giles) writes:
>Then your programs are considerably different from what I'm familiar with.
>Most errors are not syntactic or static semantic errors (like type
>errors).  The vast majority of debugging time is spent isolating and
>correcting problems which are not - and cannot be - found by the
>typechecks no matter how strict your type system is. 

	Hmmm; well, if this is your experience then it is very different
than mine!  I think that my most common coding errors are (in order of
decreasing frequency):

	1) Typographical errors, such as misspellings of keywords and
	   identifiers.
	2) Failing to pass parameters to a function in the correct order,
	   or neglecting to pass all of the necessary parameters.
	3) Using "=" for "==", especially after I've been coding in
	   something other than C for a while!  :-)
	4) Incorrectly dereferencing some pointer to a complicated data
	   structure, or incompletely following a chain of pointers.
	5) Attempting to add new functionality to a piece of code after
	   1:00 AM.  :-)
	6) Bugs in the documentation of system calls and library functions.
	7) Being a general bonehead!

	Obviously, a typechecker will catch most of the errors of types
1,2,3,and sometimes 4, which probably accounts for 85% or more of the
_errors_ in my code.  Of course, since these are so easy to fix, this
probably only amounts to 15% of by debugging _time_.  Of course, that is
to the typechecker's credit, not it's detriment.  After all, if one had
the Acme Super-Duper Bug Remover, that removed all of a programs bugs in
minutes, you'd say that debugging programs is easy and we should waste our
time talking about it.  ;-)
--
Jack Eifrig (eifrig@cs.jhu.edu)       The Johns Hopkins University, C.S. Dept.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: Trevor Jenkins <tfj@apusapus.demon.co.uk>
Subject: Another Compiler book to add to the FAQ 
Reply-To: Trevor Jenkins <tfj@apusapus.demon.co.uk>
Organization: Compilers Central
Date: Fri, 8 Jan 1993 20:45:21 GMT
Keywords: books, interpreter, comment

[re Brown, P. J., Writing interactive compilers and interpreters]

This is one of the few books that addresses real implementation issues.

P J Brown has a good writing style, one of the best bits of the book is
the "Deadly Sins". A list of aphorisms (much like those in "Elements of
Programming Style" *) dedicated to the compiler (interpreter) writer.

There is one beautiful quote "There is a powerful psychological aid which
can help both you and the users [of your compiler]. It is suggested by
Rain (+) and consists of offering a free beer to the first user to find
each bug in you compiler. ... If certain computer manufacturer made the
same offer they would need to take over a brewery to satisfy the user
demand." ($)

I am certain (0.45) that there was a paperback edition in print not long
ago. Next time I'm in my local bookstore I'll have a look---assuming that
I find it then I'll auction it for a copy of "The Design of an Optimizing
Compiler" by Wulf et al.

Regards, Trevor.

*) Like Kernighan and Plauger Brown also recommend reading Strunk and
White's "Elements of style" before writing the documentation.

+) Rain, M "Two unusual methods for debugging system software"
   Software Pratice and Experience, vol 4 #1 61-63.
   
$) Microsoft I claim my free beer for the bug I found today in C/C++ v7.00.
   Try compiling the following two files which are abstracted from some
   real code:

   File a.h                        |   File b.h
   
   #include "b.h"                  |   #include "a.h"
   // end of file                  |   // end of file

---------------------------------------------------------------------------
Trevor Jenkins
134 Frankland Rd, Croxley Green, Rickmansworth, WD3 3AU, England
email: tfj@apusapus.demon.co.uk                               radio: G6AJG  
phone: +44 (0)923 776436
[As noted before, the book still seems to be available as an expensive
paperback. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: jlg@cochiti.lanl.gov (J. Giles)
Subject: Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code
Reply-To: jlg@cochiti.lanl.gov (J. Giles)
Organization: Los Alamos National Laboratory
Date: Mon, 11 Jan 1993 20:49:36 GMT
Keywords: optimize, performance, debug

nickh@CS.CMU.EDU (Nick Haines) writes:
> 4. Use of a language with a good type system eliminates the
> edit-compile-bomb-edit cycle, replacing it with an
> edit-typecheck-edit-typecheck cycle. Typechecking is (in general) much
> faster than compilation because it includes no optimisation or code
> transformations. An SML program which successfully typechecks will not
> bomb at runtime.

Then your programs are considerably different from what I'm familiar with.
Most errors are not syntactic or static semantic errors (like type
errors).  The vast majority of debugging time is spent isolating and
correcting problems which are not - and cannot be - found by the
typechecks no matter how strict your type system is.  To put it another
way: people make mistakes and those mistakes which the compiler (or some
analyzer) can find automatically are the least difficult to find and
correct.

> 6. You suggest that because compiler writers often work for compiler
> companies rather than hardware companies, they either (a) don't know how
> to tweak the hardware in the best way or (b) can't be bothered.  [...]

It seems to me that the main problem with compiler writers is not that
they don't work for the hardware vendor (even those that don't often
specialize in a single architecture).  The main problem these days is that
compiler writers don't actually *use* the language the compiler is written
to compile.  Such compiler jockeys don't understand the issues which are
important to the users.
-- 
J. Giles
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: Wolfgang Diestelkamp <wd@cs.tu-berlin.de>
Subject: more PD for scheduling
Reply-To: Wolfgang Diestelkamp <wd@cs.tu-berlin.de>
Organization: Compilers Central
Date: Tue, 12 Jan 1993 13:11:32 GMT
Keywords: question, optimize

Concerning my request for a PD scheduling environment, I found a pointer
to a scheduler that was written for GCC.  I have in my hands a paper
written by Micheal D. Tiemann, describing his implementation of a
scheduler for GCC, but neither an email address nor any references to ftp
sites or the like.  Could anyone help me out ?

Wolfgang Diestelkamp
wd@cs.tu-berlin.de
wolfgang@first.gmd.de
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: osycs@giac1.oscs.montana.edu (Craig Spannring)
Newsgroups: comp.compilers
Subject: Pascal validation suite wanted
Keywords: Pascal, testing, comment
Date: 9 Jan 93 07:09:04 GMT
Article-I.D.: comp.93-01-056
Reply-To: osycs@giac1.oscs.montana.edu (Craig Spannring)
Organization: Geographic Info. & Analysis Center Montana State University

Is there an ftp site out there where I could get a Pascal compiler
validation suite for ISO standard Pascal level 1?  I would prefer the
suite described in 'Pascal Compiler Validation' by Wichmann & Ciechanowicz,
1983.
-- 
Craig Spannring --- (406) 994-6128
osycs@giac1.oscs.montana.edu
Geographic Information & Analysis Center
[Are there any actual ISO Pascal compilers around? -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: vern@daffy.ee.lbl.gov (Vern Paxson)
Newsgroups: comp.compilers
Subject: Re: Input buffer overflow in lex...
Keywords: lex
Date: 5 Jan 93 18:30:07 GMT
Article-I.D.: comp.93-01-013
Reply-To: vern@daffy.ee.lbl.gov (Vern Paxson)
Organization: Lawrence Berkeley Laboratory, Berkeley CA

John R. Levine <johnl@iecc.cambridge.ma.us> writes:
> Well, the short answer is that you lose.  No version of lex checks for
> token buffer overflow, although it is less destructive in flex than it is
> in lex.  This can be called a lex design error, though it's hard to
> check for overflow without making the lexer a lot slower.

Let me clarify a bit.  flex does detect token buffer overflow and
generates a fatal run-time error when it occurs.  It can do so cheaply
because such overflow can only occur when new characters are being read
into the input buffer.  That's a rare operation in a flex scanner because
input is block-oriented.

> The other possibility is to use start states to build the string
> yourself:

Hear hear!  This is in general a much better approach, as it also provides
a natural way to deal with escape sequences and continued strings.

		Vern

	Vern Paxson				vern@ee.lbl.gov
	Systems Engineering		        ucbvax!ee.lbl.gov!vern
	Lawrence Berkeley Laboratory		(510) 486-7504
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: Mirek Benes <benes@dcse.fee.vutbr.cs>
Subject: Practicality of functional and logic languages?
Reply-To: Mirek Benes <benes@dcse.fee.vutbr.cs>
Organization: Compilers Central
Date: Mon, 11 Jan 1993 06:33:16 GMT
Keywords: functional, design

I would like to know some opinions concerning functional and logic
programming languages (Haskell, Miranda, ML / Prolog) and their practical
usability for programming: 

* Are they (1) toys for playful programmers, (2) something usable only 
  at universities for never-ending research, or (3) important means for 
  development of usable software products? 
* Are there any (comercially?) successful applications written in functional 
  or logic languages? 
* How effective these applications are comparing with applications 
  written in classic procedural languages like Pascal?

I want to start courses of these programming styles at the university, 
so any opinions on the subject will clear up my situation.

     Miroslav Benes
-- 
Technical University of Brno           E-mail: benes@dcse.fee.vutbr.cs
Faculty of Electrical Engineering      Phone: +42-5-746111 / 238
Department of Computer Science & Engineering
Bozetechova 2, CS-612 66 Brno          FAX:   +42-5-750252
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers,misc.jobs.offered
From: finger@convex.com (Jay Finger)
Newsgroups: comp.compilers
Subject: Re: Input buffer overflow in lex...
Keywords: lex, comment
Date: 8 Jan 93 00:12:02 GMT
Article-I.D.: comp.93-01-040
Reply-To: finger@convex.com (Jay Finger)
Organization: CONVEX Computer Corporation, Richardson, Tx., USA

richw@sol.camb.inmet.com (Richard Wagner) writes:
>In the version of "lex" I use, the generated lexer gets its input via an
>"input" macro.  One solution, which may be viewed as a "kludge" or "hack",
>is to [redefine the input() macro]

I don't remember where I read this, but some piece of of AT&T
documentation I once read documented the input macro and suggested that it
be redefined to fit your own application if you thought that was
appropriate.  I have done this many times in the past, but all of the code
I have with me now uses flex (which uses a different input mechanism
completely).

So, while it me be a kludge, it's at least an "official kludge". :-)

jay
-- 
Jay Finger - finger@convex.com        | Convex Computer Corp
CONVEX System Integration and Support | 3000 Waterview Parkway
Product Specialist                    | Richardson, TX 75080
[In the O'Reilly "lex & yacc" there are several examples of redefining the
lex input macro, since there isn't any other way to change the input source.
Flex lets you redefine YY_INPUT which reads a chunk of input, which is a lot
easier since you don't have to worry about pushback as you do with input().
-John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: drw@zermelo.mit.edu (Dale R. Worley)
Subject: Code quality
Reply-To: drw@zermelo.mit.edu (Dale R. Worley)
Organization: MIT Dept. of Tetrapilotomy, Cambridge, MA, USA
Date: Wed, 6 Jan 1993 04:03:14 GMT
Keywords: optimize, question, comment

How important is generated code quality these days?  There are a lot of
good optimization techniques that seem to be adequate for ordinary
programming.  But they still are at least 10% or 20% worse than the ideal.
Is there much of a market for another 10% in speed of generated code?

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
[A few days ago we saw a report about the Tartan Ada compiler which is
supposed to produce better DSP code than humans do. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: polstra!jdp@uunet.UU.NET (John Polstra)
Subject: Re: Code quality
Reply-To: polstra!jdp@uunet.UU.NET (John Polstra)
Organization: Polstra & Co., Inc., Seattle, WA
Date: Tue, 12 Jan 1993 17:29:53 GMT
Keywords: optimize

drw@zermelo.mit.edu (Dale R. Worley) writes:
> Is there much of a market for another 10% in speed of generated code?

For a number of years I have been doing consulting work for the compiler
department of a large company that manufactures office-scale Unix systems
with bundled compilers.  Run time performance of the compiled code is
*all* they care about.  Their marketing people say that the price they can
get for a system directly depends on the SPEC rating the system can
attain.  They literally have a formula that they use to calculate the
system price from the SPEC rating.  Furthermore, for every additional 1%
of object code speed improvement that we might squeeze out of the
compiler, the marketing people can estimate how many additional millions
of dollars of revenue the product will produce for the company.

On the other hand, they couldn't care less about speed of compilation.
This is a complete reversal of the attitude that prevailed there a few
years ago.
-- 
John Polstra                              polstra!jdp@uunet.uu.net
John D. Polstra & Co., Inc.                  ...!uunet!polstra!jdp
Seattle, Washington USA   Phone (206) 932-6482, FAX (206) 935-1262
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: syiek@tartan.com
Subject: Other Languages
Reply-To: syiek@tartan.com
Organization: Compilers Central
Date: Tue, 5 Jan 1993 01:22:02 GMT
Keywords: optimize

>[Does Tartan have DSP compilers for other languages or just Ada?  I can
>imagine that there'd be a market for Fortran, considering all the numeric
>Fortran code there is, or maybe C++ for people who want a cool language.
>-John]

In addition to Ada, the optimization and code generation portions of our
technology (compiler back-ends) have survived connections to front-ends
for C, Modula-2, and two other languages.  However, our current offerings
do not include these languages.  I cannot say anything at this time about
plans (or lack of them) to expand our product line in this direction.
Announcements will be made in the fullness of time.

-Dave
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: przemek@viewlogic.com (Przemek Skoskiewicz)
Subject: Input buffer overflow in lex
Reply-To: przemek@viewlogic.com (Przemek Skoskiewicz)
Organization: Compilers Central
Date: Mon, 4 Jan 1993 23:53:24 GMT
Keywords: lex, question, comment

I've scanned the INDEX and the back issues, but I haven't found any
mention of this bug.

I have the following lex rule to recognize strings enclosed in double
quotes for my grammar.  I'm using SunOS 4.1.3's lex/yacc package.

The problem is that the generated lex code doesn't even look at the YYLMAX
variable, which defines the size of the yytext input buffer.  As long as
an input string to my grammar is less than the maximum size of the yytext
buffer, everything is fine.  For bigger strings, lex overwrites internal
memory and I get a core dump.  I used Purify to figure out which variable
was getting corrupted and when.

    \"(\\.|[^\\"])*\"                       {some_action_here ();}

The input string is "aaaa..." with 2000 `a' in it.

Before I start hacking, has anybody ran against this problem and has a
fix?  It's rather interesting that there is not a single `if' statement in
the yacc code that would check if the input buffer index is not greater
than YYLMAX.

Viewlogic Systems, Inc.                         Przemek Skoskiewicz
293 Boston Post Road West
Marlborough, MA 01752-4615, USA
email: przemek@viewlogic.com
[See the next message. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: grover@brahmand.Eng.Sun.COM (Vinod Grover)
Subject: Re: Code quality
Reply-To: grover@brahmand.Eng.Sun.COM (Vinod Grover)
Organization: Sun
Date: Thu, 7 Jan 1993 16:16:16 GMT
Keywords: optimize, performance

drw@zermelo.mit.edu (Dale R. Worley) writes:
>How important is generated code quality these days?  ...
>Is there much of a market for another 10% in speed of generated code?

Code quality isnt always speed. In embedded systems, code size is equally
and sometimes even more important. In these systems requirements are often
formulated in terms of the fraction of memory an application is allowed to
use. 10% can make a big difference.

Vinod Grover
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: Paul Robinson <TDARCOS@MCIMAIL.COM>
Subject:  Another Compiler book to add to the FAQ
Reply-To: Paul Robinson <TDARCOS@MCIMAIL.COM>
Organization: Compilers Central
Date: Fri, 8 Jan 1993 03:42:49 GMT
Keywords: books, comment

I would like to add a book to the list of compiler related books.  Someone
can probably find the ISBN number, as the library I was reading it at is
3,000 miles away in California.  The book is called

   Writing Interactive Compilers and Interpreters

   by P.J. Brown
---
Paul Robinson -- TDARCOS@MCIMAIL.COM
[This is a great book, but it was published by Wiley in 1979 and is long
out of print.  The ISBN is 0-471-27609-X.  If anyone can find a source for
it, I'd like a copy myself. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers