Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ptsfa!pacbell!att-ih!ihnp4!inuxc!iuvax!pur-ee!j.cc.purdue.edu!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.c
Subject: Re: Portable "asm" (Was: The D Programming Language)
Message-ID: <697@l.cc.purdue.edu>
Date: 3 Mar 88 13:52:34 GMT
References: <11702@brl-adm.ARPA> <243@eagle_snax.UUCP> <2245@geac.UUCP> <7401@brl-smoke.ARPA>
Organization: Purdue University Statistics Department
Lines: 32
Summary: Make it simpler, shorter, more flexible

In article <7401@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes:
> In article <2738@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes:
> >Clearly, assembler statements should have been defined as:
> >#asm <statement>
> >instead of
> >asm("statement");
> 
> A properly-designed system programming language should not have such
> a feature at all.  (It is not guaranteed in C, either.)  

I agree with Frank on this, but I would even go farther--I would have the
asm on until turned off.  Those who believe that the language gurus can
_possibly_ anticipate how someone who understands the machine will want
to do things are either totalitarian, ignorant, or stupid.  Quite frequently
I come up with the observation that this feature can be used for something
which I, at least, did not know before.  In too many cases, I have seen that
the feature is a misfeature, that with essentially no cost much more could be
attained; this is not just true in programming.

I maintain that anyone who understands whatever computer is being programmed
for will, without effort, see situations in which the HLL concepts (any HLL)
are not the right way to do things.  This should be encouraged; progress in
programming should no be based on "thou shalt not do this because
	
	It can be done thusly (but not necessarily efficiently).

	It can get you into trouble.

	Why would anyone want to do this?"
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (ARPA or UUCP) or hrubin@purccvm.bitnet