andrew@alice.att.com (Andrew Hume) (05/09/91)
Submitted-by: andrew@alice.att.com (Andrew Hume) 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. andrew hume andrew@research.att.com Volume-Number: Volume 23, Number 61
ast@cs.vu.nl (Andy Tanenbaum) (05/10/91)
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
arnold%audiofax.com@mathcs.emory.edu (Arnold Robbins) (05/10/91)
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
phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN) (05/12/91)
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
jfh@rpp386.cactus.org (John F Haugh II) (05/13/91)
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
phil@henson.cc.wwu.edu (Phil Nelson) (05/15/91)
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