🚀 go-pugleaf

Submitted-by: ast@cs.vu.nl (Andy Tanenbaum)

In article <132258@uunet.UU.NET> andrew@alice.att.com (Andrew Hume) writes:
>I thought 1003.2 simply described stuff so you can use it, not implement it.

It was certainly my understanding that a formal standard like an ISO standard
must contain enough information that you could give it to a Martian who had
never even heard of, say, UNIX, let alone used it, but was otherwise well
versed in computer technology, and he/she/it should be able to write a
conforming implementation.  Stronger yet, if something is not mentioned
in the standard, even if it perhaps should have been, implementers should
be free to include it or not include it at their own discretion.

Andy Tanenbaum (ast@cs.vu.nl)

Volume-Number: Volume 23, Number 62

Submitted-by: arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins)

In article <132258@uunet.UU.NET> andrew@alice.att.com (Andrew Hume) writes:
>	Can someone help clear up my misconceptions?
>I recently read someone complain about difficulties implementing
>bc from the spec in 1003.2 and some quick reponse from the author
>of that spec. What puzzled me is the underlying assumption that
>you are supposed to be able to implement from the 1003.2 description.
>Is this supposed to be true? (it obviously isn't for make, for example.)
>I thought 1003.2 simply described stuff so you can use it, not implement it.

I'm not sure what the "official" goal of the standard is wrt being able
to implement from it, but at least unofficially, this is something the
working  and balloting groups are aiming at.  Lot of peoples, notably UCB
and GNU, are using the standard as their spec for their implementations.

If one wishes to create a system that is both posix conforming and
at&t-source-code-free, then a spec that can be implemented from is a
necessity.

Of course, one could also argue that if the spec is good enough to implement
from, then it is certainly good enough to describe how to use the utility.
In some cases, like bc, awk, yacc, and lex, the spec for use is complicated
enough anyway that it becomes a spec good enough for implementing by.
(How do I know that	awk 'BEGIN { print "hi" } ; END { print "bye" }'
is legal while		awk 'BEGIN { print "hi" }   END { print "bye" }'
isn't?  Presenting a grammar for the language is almost a necessity...)
-- 
Arnold Robbins				 AudioFAX, Inc. | Threads are the
2000 Powers Ferry Road, Suite 200 / Marietta, GA. 30067 | lack of an idea.
INTERNET: arnold@audiofax.com  Phone:   +1 404 618 4281 |     -- Rob Pike
UUCP:	  emory!audfax!arnold  Fax-box: +1 404 618 4581 |

Volume-Number: Volume 23, Number 63

Submitted-by: phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN)

>Submitted-by: ast@cs.vu.nl (Andy Tanenbaum)

>In article <132258@uunet.UU.NET> andrew@alice.att.com (Andrew Hume) writes:
>>I thought 1003.2 simply described stuff so you can use it, not implement it.

>It was certainly my understanding that a formal standard like an ISO standard
>must contain enough information that you could give it to a Martian who had
>never even heard of, say, UNIX, let alone used it, but was otherwise well
>versed in computer technology, and he/she/it should be able to write a
>conforming implementation.  Stronger yet, if something is not mentioned
>in the standard, even if it perhaps should have been, implementers should
>be free to include it or not include it at their own discretion.

If there is a standard that simply describes how to use something, then
you should be able to implement something conforming to that document,
as long as what you end up with is usable in EXACTLY the same way.
It may not give you any good ideas on how to go about it; that would
be up to you.  If you write it all as a simulated machine and OS in BASIC,
and it works exactly as the user document describes, then it conforms
(even if it is worthlessly slow, unless the document specifies how fast
something has to work, and I doubt that).
-- 
 /***************************************************************************\
/ Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/

Volume-Number: Volume 23, Number 64

Submitted-by: jfh@rpp386.cactus.org (John F Haugh II)

In article <1991May11.184228.15157@uunet.uu.net> ast@cs.vu.nl (Andy Tanenbaum) writes:
>It was certainly my understanding that a formal standard like an ISO standard
>must contain enough information that you could give it to a Martian who had
>never even heard of, say, UNIX, let alone used it, but was otherwise well
>versed in computer technology, and he/she/it should be able to write a
>conforming implementation.  Stronger yet, if something is not mentioned
>in the standard, even if it perhaps should have been, implementers should
>be free to include it or not include it at their own discretion.

In the strictest sense I am certain you are right.  However, that doesn't
mean anyone is going to buy whatever you produce.  A POSIX-compliant CP/M
is still just CP/M ...

I think the POSIX standards are lacking in detail.  A number of vendors
that I am familiar with are trying to get their non-UNIX-compatible O/S
made POSIX compliant.  Some of them may succeed, but I don't think they
will have the commercial success similiar to what a UNIX-compatible and
POSIX-compliant O/S will.
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh@rpp386.cactus.org
"If liberals interpreted the 2nd Amendment the same way they interpret the
 rest of the Constitution, gun ownership would be mandatory."


Volume-Number: Volume 23, Number 67

Submitted-by: phil@henson.cc.wwu.edu (Phil Nelson)

andrew@alice.att.com (Andrew Hume) writes:

>	Can someone help clear up my misconceptions?

I'll try.

>I recently read someone complain about difficulties implementing
>bc from the spec in 1003.2 and some quick response from the author

First, it was not complaining about difficulties in implementing bc
from the spec.  It was very easy to implement from the spec.  The
problems were that the spec had errors.  That is why the author
came back with a quick response.

>of that spec. What puzzled me is the underlying assumption that
>you are supposed to be able to implement from the 1003.2 description.
>Is this supposed to be true? (it obviously isn't for make, for example.)
>I thought 1003.2 simply described stuff so you can use it, not implement it.

At least for the bc spec, a yacc grammar is given and stated to be the
"correct" grammar for bc.  If that doesn't imply direct implementation 
details, I'm not sure what does.  In fact, it describes in very great
detail how a bc processor is supposed to work.  (i.e. Internal representation
must be in decimal.)  In my reading of the bc spec, it sounds like
it is directed at an implementor and not a user.  A user could get all
the needed information out of the spec, but it is not a user manual.

It does leave a lot of room for different ways of doing the implementation,
but I think that if one describes in detail how a program should work,
a programmer should be able to take that spec and implement a program
that works as stated in the spec.

I would hope that the rest of the POSIX documents can be used in the same
way as the bc spec.

--Phil Nelson


Volume-Number: Volume 23, Number 70