HDTenEightyP/NetNews huggingface dataset:
From: raveling@Unify.com (Paul Raveling)
Subject: Re: language design tradeoffs
Reply-To: raveling@Unify.com (Paul Raveling)
Organization: Unify Corporation (Sacramento)
Date: Fri, 11 Sep 1992 20:00:21 GMT
Keywords: design, parse, comment

torbenm@diku.dk (Torben AEgidius Mogensen) writes:
> 
> Several languages (e.g. Miranda) use EOL as separator. It gives an
> uncluttered syntax, but requires special structure if command or
> expressions can't fit on a line.

Once long ago this was considered easier than using a terminator such as
';' -- a prime example was FORTRAN.  How many remember the thrill of
having their IBM FORTRAN II compiler patched to recognize record-mark (a
0-2-8 punch) as a statement terminator, making it possible to punch TWO
statements per card?

For a more modern and widespread example, there's the C preprocessor,
where macros are parsed as one line, though they're often written as
multiple lines ending with '\'.

Actually I like the idea of using EOL rather than ;.  It eliminates a
cause of several common errors in compilation that need not happen, and it
need not have particularly adverse side effects.

Here's one example of a human factors trap in C that wouldn't be there
without ';'.  The key is C's syntax definition for <statement> -- either
one simple statement terminated by ';' or a sequence of simple statements
surrounded by {}'s.

	#define	SOME_MACRO(A,B) \
		xxx;		/* one simple C statement */

	   is syntactically interchangeable with:

	#define	SOME_MACRO(A,B) \
		{ xxx; yyy; }	/* one compound C statement */


	Now take this invocation:

	if ( a == b )
	    SOME_MACRO(a,b)
	else
	    ...

But if your brain kicked in with the notion that SOME_MACRO(a,b)
invocation looks like it should be a statement, and you automatically
coded it as

 	if ( a == b )
	    SOME_MACRO(a,b);
	else
	    ...

then the extra ';' terminates the entire 'if' statement and the following
'else' produces a syntax error.  Or if you had left yourself open to the
dangling else problem in nested if's, it's possible to get no syntax error
but instead to get a surprising flow of control.

There's a second-level trap here too, based on using knowledge of
semicolons in software tools.  I once saw someone encounter the trap above
when his automatic-indenting software demanded that the macro invocation
look like a statement, ending with a ';'.  To accommodate this autoindent
software he took existing code that had been correct and appended a ';' to
each macro invocation.  At least it caused no harm on MOST of the macro
invocations...

But the whole thing isn't a problem if an unescaped EOL is a statement
terminator.
------------------
Paul Raveling
Raveling@Unify.com
[For people who don't know, there are straightforward albeit ugly ways around
the if, macro, and semicolon problem, e.g.:
#define foo(args) if(1) { /* macro body */ } else
-John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1531 comp.theory:1906
From: ivanov@osf.org (Eric Ivanov)
Newsgroups: comp.compilers,comp.theory
Subject: Re: COMPILERS FROM DENOTATIONAL SEMANTICS
Keywords: denotational semantics
Date: 8 Sep 92 09:29:24 GMT
Reply-To: ivanov@osf.org (Eric Ivanov)
Organization: Open Software Foundation, Research Institute - Grenoble - France

CRI (Denmark) sells a toolset based on the RAISE Specification Language
(RSL) which may be of interest to you. I am not a CRI salesman so you'd
better address to them directly for more information.

The RSL toolset may not be able to generate an interpreter from the
denotational semantics but it enables the programmer to specify the
language's semantics (algebraically and/or denotationally). It has other
interesting features (non-determinism enabled, concurrency).  Yielding an
interpreter is IMO just a case of adding a generic piece of RSL code to
the denotational specs.

Pointers:
Steen Jurs, Manager, CASE Development Department, CRI
tel.: +45 45 82 21 00
fax:  +45 45 82 17 11
Email: sbj@csd.cri.dk

Let us know if you are successful in using RSL for your purpose.
--
   |          Eric Ivanov          |   | messages:  ivanov@gr.osf.org  |
   |   Institut de Recherche OSF   |   |       ou:  ivanov@ri.osf.fr   |
   |     2 avenue de Vignate       |   |telephone:  (+33) 76.63.48.96  |
   |    38610 GIERES   FRANCE      |   |      fax:  (+33) 76.51.05.32  |
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: aet@mullian.ee.mu.OZ.AU (bert thompson)
Newsgroups: comp.compilers,comp.theory
Subject: COMPILERS FROM DENOTATIONAL SEMANTICS
Keywords: denotational semantics, question
Date: 7 Sep 92 03:31:15 GMT
Reply-To: aet@mullian.ee.mu.OZ.AU (bert thompson)
Organization: Computer Science, University of Melbourne, Australia

Could someone please tell me if there are any tools out there that will
accept the denotational semantics of a computer language and then produce
from it an interpreter or a compiler in a high-level language.

Cheers!

	bert.

--
bert thompson	aet@munagin.ee.mu.oz.au.
SITEE		school of information technology and electrical engineering
		university of melbourne
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: jarmo@ksvltd.FI (Jarmo Raiha)
Newsgroups: comp.compilers
Subject: Backtracking yacc
Keywords: yacc, parse, question, comment
Date: 10 Sep 92 23:01:10 GMT
Reply-To: Jarmo Raiha <jarmo@ksvltd.FI>
Organization: Compilers Central

Has anybody seen such a thing as backtracking yacc?  What I had in mind
was a LALR parser that resolves ambiquity by backtracking to the point
where it had multiple routes to go.  It would parse the input until it
encounters a dead end, and after that it would try an alternative path.

I know this would not solve much.  Resolving the the conflicts 'the wrong
way' can still result to an errorless parsing, but I would like to know if
there have been any study about this approach.  Is this a completely dead
idea ?

Jarmo Raiha
[That might help for conflicts in an unambiguous grammar that needs more than
one token lookahead, but not for the more common case that a conflict is due
to a truly ambiguous grammar.  Besides, isn't there a theorem that says that
any LR(k) grammar can be rewritten as LR(1)? -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: jar@cheops.HQ.Ileaf.COM (Jim Roskind x5570)
Newsgroups: comp.compilers
Subject: Re: Parsing wars
Keywords: parse, LR(1)
Date: 5 Sep 92 16:54:36 GMT
Reply-To: jar@cheops.HQ.Ileaf.COM (Jim Roskind x5570)
Organization: Compilers Central

dww@inf.fu-berlin.de writes:
> The parsing is called shift-reduce parsing, and I thought I had understood
> that. What happens on a reduction though is, instead of pushing the
> nonterminal of the lhs of the reduced production onto a symbol stack and
> digging through the goto table for the appropriate state to push onto the
> state stack, the nonterminal is *prepended* to the input sequence of
> tokens and parsing resumes as normal. The other actions, shift, accept and
> error are as expected, an action shiftreduce combines the normal shift and
> the strange reduce.

The conseqeunces of this extension are quite significant, and the
resulting parser engine provides a much larger class of parsers than LR
parsers.  Clearly all LR parsers are a subset of the above parsers, as
doing the above "strange reduce" followed by a "shift" is identical to
doing a classical LR engine "reduce."

To see the weirdness of this extension, it can be noted that you can build
an N pass parser using the above mechanisms.  Certainly parsing is not
restricted to Left to right, Right most derivation.  To see how to make an
N pass (trivial) parser using the above engine, you simply have to note
that a series of "strange reduces" (re: which put stuff back into the
input queue) can be used at any point to "back up" into the current stack.
To be fair about this, you have to provide trivial reductions that have a
right hand side of length 1, and provided new non-terminal names for the
"popped" entries on the stack.

Mind you, I have no real idea as to how to specify such parsers, or how to
build the transition tables that I indicate can be built.  For a given
grammar, the big loss is that there is no longer a cannonical parsing
order, such as is specified with LR parsers.  If you restrict the
transition table so that you must have a "shift" after every "strange
reduce,", then you have exactly an LR parsing engine.

Oh well, it is interesting, but I'm not sure what the use is.  It would be
more interesting if a clear class of parsers could be specified, and these
parsers required the "strange reduce" to be implemented.  

Jim Roskind-   Author of a YACCable C++ grammar
Independent Consultant
(407)729-4348 or (617)290-4990 x5570
jar@hq.ileaf.com or ...!uunet!leafusa!jar
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1555 comp.theory:1927
From: ashok@trddc.ernet.in (Ashok Sreenivas)
Newsgroups: comp.compilers
Subject: Abstract Interpretation Query
Keywords: functional, logic, question
Date: 4 Sep 92 16:57:00 GMT
Reply-To: Ashok Sreenivas <ashok@trddc.ernet.in>
Organization: University of Tennessee, Knoxville - CS Department

I am working on trying to formalise program analyses and
transformations.  In this connection, I have come across a technique
called Abstract Interpretation.  So far, I've only seen a lot of
theory regarding it, and some applications to functional and logic
languages.  

What I want to know is: has anybody applied it to everyday imperative
languages in real life (i.e. to languages like Pascal, C, and
analyses like type analysis, data flow analysis etc.)?  

If so, what were your experiences with Abstract Interpretation?  
--------------------------------------------------------------------------

I'm posting this for a friend who doesn't have access to news.
Preferably, email responses to Ashok Sreenivas at the following email
address: ashok@trddc.ernet.in If this is not possible, please send me
email (mehta@cs.utk.edu) and/or post on comp.compilers.

Thanks,

Dinesh P. Mehta
Computer Science Dept
University of Tennessee Space Institute



-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: sasghm@unx.sas.com (Gary Merrill)
Newsgroups: comp.compilers
Subject: Re: Backtracking Yacc Paper Availability
Keywords: yacc, parse, FTP
Date: 14 Sep 92 18:17:23 GMT
Reply-To: Gary Merrill <sasghm@unx.sas.com>
Organization: Compilers Central
Return-Path: <sasghm@theseus.unx.sas.com>

I have had a number of requests for my paper concerning using YACC in a
backtracking parser.  I plan to update the paper (to include some more
recent changes) over the next couple of days and make it available by
anonymous ftp.  I appreciate everyone's interest in this.  Please do *not*
request a copy of the paper at this time unless you do *not* have ftp
access.  (For those who don't, I'll e-mail copies of the paper.)

---
Gary H. Merrill  [Principal Systems Developer, C Compiler Development]
SAS Institute Inc. / SAS Campus Dr. / Cary, NC  27513 / (919) 677-8000
sasghm@theseus.unx.sas.com ... !mcnc!sas!sasghm
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1533 comp.human-factors:2171
From: torbenm@diku.dk (Torben AEgidius Mogensen)
Newsgroups: comp.compilers,comp.human-factors
Subject: Re: language design tradeoffs
Keywords: design, parse
Date: 8 Sep 92 11:07:58 GMT
Reply-To: torbenm@diku.dk (Torben AEgidius Mogensen)
Organization: Department of Computer Science, U of Copenhagen

kotula@cs.umn.edu asks about languages with EOL as command separator
contra using a visible character (like ;).

Several languages (e.g. Miranda) use EOL as separator. It gives an
uncluttered syntax, but requires special structure if command or
expressions can't fit on a line. Some languages (Haskell and some versions
of BASIC) allow both EOL and e.g. ; as separators, thus allowing mixed
notation.

It is even possible to make grouping dependent on indentation: if the next
line is indented more than the present, it is considered an extension of
the present line. This approach is used in Haskell and something similar
applies in Miranda (though the indentation is dependent on the position of
keywords on the previous line).

An example of this (in no particular language) is the following
command/expression

	f
	  g
 	     x
	     y
	  z

which is equivalent to

	f(g(x,y),z)

As for specifying a grammar for this, I believe it is better to handle the
problem during the lexical analysis, making each new line generate one or
more separators: "," if the indentation is the same, "(" if it is greater,
and one or more ")" if it is smaller.

	Torben Mogensen (torbenm@diku.dk)
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: kirchner@uklira.informatik.uni-kl.de (Reinhard Kirchner)
Subject: Re: User-Defined Operators (was: Scientists as Programmers (was: Small Language Wanted))
Organization: University of Kaiserslautern, Germany
Distribution: na
Date: Mon, 14 Sep 1992 09:02:13 GMT

>>compiler-generation time.  
> 
> That last statement is _wrong_.  It is _easy_ to add user-defined operators to
> a language.  The attributes sufficient to make it easy are:
> 
>    operators must be lexically distinct
>       just like identifiers are not predefined, but are lexically distinct,
>       so too can operators be lexically distinct
>    the operator precedence relationships must be static
>       this is true in languages like C where all the operators are fixed,
>       and therefore all the precedences are fixed
>    the operator precedence must be lexically determined
>       this is easy if you incorporate symbol table information into the
>       lexer so that on finding an operator, it looks up the precedence
> 
If one wants to see and USE a language with user definable operators:

Take Pascal-XSC. It is available on all unix machines since it compiles to
standard C. It allows users to define operators monadic and dyadic, and it comes
with many of them for interval, vector, matrix, complex etc. computations.

R. Kirchner
Univ. of Kaiserslautern, Germany
kirchner@informatik.uni-kl.de

Xref: sparky comp.edu:1633 comp.lang.misc:3040
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.edu,comp.lang.misc
Subject: Re: Programmers
Date: 12 Sep 1992 02:35:40 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Sep11.165639.24682@yrloc.ipsa.reuter.COM> rbe@yrloc.ipsa.reuter.COM (Robert Bernecky) writes:
>a. Ability to spell.
>b. Ability to write simple, complete sentences in any language.
>c. Ability to communicate what they claim to know.

These skills are useful for everyone, not just computer professionals, and
lack of these skills is rampant in most engineering discliplines.  Since
this discussion is taking place in comp.* groups, let's try to focus on the
problems specific to computers.  I don't think we have any hope here of
solving all the problems of the education system, but we might be able to
make some inroads into the issues unique to computer science.

However, I will point out that some engineering schools are trying to
address these problems (or at least b and c -- I doubt anyone would be
flunked out if their only writing deficiency were spelling).  In the last
decade MIT has instituted a writing competency requirement for graduation.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: U58664@uicvm.uic.edu (Francine Cannarozzi)
Newsgroups: comp.edu
Subject: Bibliography Software
Date: 11 Sep 92 21:18:02 GMT
Organization: University of Illinois at Chicago

I am interested in locating software (for use on a DOS-based PC)
that creates, catalogues, manages, and prints in proper format,
bibliographic information.  Does anyone know of such software
or is using a similar program now?
Newsgroups: comp.edu,comp.lang.misc
From: edp@math.zko.dec.com (Eric Postpischil)
Newsgroups: comp.edu
Subject: Re: Re: Scientists as Programmers (was Re: Small Language Wanted)
Date: 9 Sep 92 13:21:17 GMT
Reply-To: edp@math.zko.dec.com (Eric Postpischil)
Distribution: na
Organization: Digital Equipment Corporation

In article <135691@lll-winken.LLNL.GOV>, blair@lll-crg.llnl.gov (Gary
Blair) writes:

>Wrong.  If your compiler uses ANY kind of table-driven parsing scheme, it is
>next to impossible to allow programmer-defined operators.  The parser must
>know what an operator looks like, and what precedence it has  with respect
>to all other operators.  This is usually predetermined, at
>compiler-generation time.

Nah, it is trivial.  The lexical analyzer just recognizes the operator
and returns a token to the parser.  Handling precedence is a bit
trickier, but if you are willing to accept a fixed number of precedence
levels determined at compiler-generation time, it is trivial too. 
Simply, when an operator is declared, the parser stores the name of the
operator (the string of symbols that denote it) into a data structure,
along with information about its precedence and meaning.  When the
lexical analyzer sees that string in the future, it returns a token
appropriate to the precedence of the operator.  That token is used in
the parsing; it is part of the parse tables.  When the parser sees that
token, it takes a value from the token that points to the information
about the operator and calls appropriate routines to implement the
meaning.

The principal requirement here be that legal strings for operators and
other symbols be defined properly, so that whatever selection of
declarations the user makes is unambiguous and can be recognized by the
lexical analyzer.  E.g., variables and types and similar things might be
all alphanumeric, and operators might be all contiguous strings of
symbols such as <, !, et cetera.  But you could easily have named
operators using the scheme I have described above, such as "a modulo_add
b" to mean (a+b)%m.


                                -- edp (Eric Postpischil)
                                "Always mount a scratch monkey."
                                edp@alien.enet.dec.com
Newsgroups: comp.edu
From: schuette@quip.eecs.umich.edu (R. Wade Schuette)
Subject: Re: Bibliography Software
Organization: University of Michigan EECS Dept., Ann Arbor
Date: Sat, 12 Sep 1992 02:18:42 GMT

In article <92255.161802U58664@uicvm.uic.edu> Francine Cannarozzi <U58664@uicvm.uic.edu> writes:
>I am interested in locating software (for use on a DOS-based PC)
>that creates, catalogues, manages, and prints in proper format,
>bibliographic information.  Does anyone know of such software
>or is using a similar program now?

Yep. "Pro-Cite" by Personal Bibliographic Software, Inc. 
PO Box 4250
Ann Arbor, MI 48106
(313) 996-1580 

Pro-Cite has versions for both PC's and Macs. Does all you ask, 
can reoranize your cites into ANY standard format (Chicago, APA, whatever
they are) at touch of a button, sorts, slices, dices, with 3-rd party
support imports directly from MEdline, BRS, Dialog, etc.  Everyone I 
know using it likes it a lot. 

Wade

-- 
======================================================================
R. Wade Schuette        | "Have you ever noticed that if you think
+1 (313) 996-7479       | about a problem at 2am, and then again at 
schuette@eecs.umich.edu | noon, you get two different answers?" snoopy
From: ohnacker1@urz.unibas.ch
Newsgroups: comp.edu
Subject: help with Hypercard needed
Date: 14 Sep 92 17:08:26 GMT
Organization: University of Basel, Switzerland

Hi

not being sure whether this is the right newsgroup I'll try my luck: 
I am an assistant at the University of Basel who's job for the next two 
semesters is (among other things) to care about the practical studies connected
to the lecture: "Introduction to computer science". My professor has the
intention, not to start with a 'concrete programming language' (as it was done
with Pascal for several years) and pinning the students down to a concrete
syntax, but first of all to demonstrate different aspects of computer science
and the paradigms like condition, loop, recursion, function etc. in a more
motivating way -- for most of the students are not future computer scientists
but biologists, chemists, physicists -- and only then (after about 5 or 6
weeks) start with teaching concrete programming. 

In the practical studies this motivating part shall be done with Hypercard
(eventually using a little bit of Hypertalk) and because I'm not (already ...)
a Hypercard specialist, I'd be very glad if someone with more experience could
give me any suggestions about Hypercard and motivating people. 
If there already exist some stacks treating the concepts of computer science
I'd be very interested too of course!

Thanks in advance

Peter Ohnacker

------------------------------------------------------------------------------
Peter Ohnacker
Institut fuer Informatik                     email: ohnacker1@urz.unibas.ch
Universitaet Basel                             or   ohnacker@ifi.unibas.ch
Mittlere Str. 142
CH 4056 Basel
Xref: sparky comp.edu:1588 comp.lang.fortran:3484
From: hobbs@gemmax.enet.dec.com (Steve Hobbs)
Newsgroups: comp.edu,comp.lang.fortran
Subject: Re: Case Sensitivity (was Re: Small Language Wanted)
Date: 9 Sep 92 12:43:22 GMT
Reply-To: hobbs@gemmax.enet.dec.com (Steve Hobbs)
Followup-To: comp.edu
Organization: Digital Equipment Corporation

In article <1992Sep8.175330.14163@newshost.lanl.gov>, jlg@cochiti.lanl.gov (Jim Giles) writes:

>In the meantime, case *INsensitivity* allows the use of case for
>emphasis and for documentation.  This is also a minor convenience.
>Which dominates and in what contexts is a subject for research.
>But, I feel that case sensitivity is best when it has specific
>meaning to the language (like: all identifiers which begin with 
>uppercase are function or constructor names - and the compiler
>enforces that).

Reminds me of the original FORTRAN I definition where only variables
beginning for I,J,K,L,M,N were "fixed point" while all others had to
be "floating point" with no exceptions.  Later, in FORTRAN II they added
functions.  Arithmetic statement functions, the "closed" (library intrinsic),
and the "open" (built-in intrinsic) functions had to end with the letter "F"
and were fixed-point only if they began with the letter "X".  (What
consistency, MOD was an integer variable while MODF was a floating function).

In FORTRAN IV they allowed the programmer more freedom with choosing his
identifier names.