🚀 go-pugleaf

Submitted-by: stephe@mks.com (Stephen Walli)

In <1hbkbtINNmh8@ftp.UU.NET> andrew@alice.att.com (Andrew Hume) writes:

>	i wanted to add some commentary to stephe's treatise (epic? opus?
>kidney stone?). 

Angst.  And thanks for taking the time to read it. 

>	first of all, i think LIS are a good idea. as some of the readers
>of this group know, i am the technical editor for an ECMA standard on
>file system formats (its now DIS 13346!!). i ``had'' to change the draft
>to follow essentially a thick/thin binding format. what this meant was that
>there were prose sections that defined the semantics of the standard;
> ....
>it really
>helps root out spurious details and you get a much better logical
>consistency in the overall design. But, there are a few field names in
>there because to get rid of them would have signficantly hurt the readability
>of the standard; i was not willing to do that just for pedagogy's sake.

I agree very much with your statement about the ability to better specify 
the standard, by stressing it and re-casting it. A couple of questions,
because it sounds like you've been able to do something useful with your 
LIS.

1. I haven't seen your spec (and I know its electronically available :-)  
   but how big is it wrt POSIX.1?  I think size and scope has a lot to 
   do with some of the problems in POSIX. 

2. I found the two book/two context problem really hurts usability.
   ( I don't believe this is the simple publishing problem some people 
    think it is.)  Are their similar concerns with your spec? 

3. How many language bindings are there to your LIS? And what languages 
   are they? 

4. Have you seen the current POSIX.1/LIS and POSIX.16 C-binding? 
   If so, what did you think?

>	to a large extent, this has happened to the posix committees.
>someone has a good idea: ``test methods''! 
>....
>they will delay every useful
>posix standard from 1-3 years for NO technical gain, they combine
>in unpredictable ways with another experimental idea (thick/thin bindings),
>and will probably drive 30-70% of the skilled volunteers out of the
>standards process because of the huge increase of arbitrary BS such
>folks would have to wade through just to stand still?' (actually, even if
>put in such terms, it might have got through anyway because the
>people on such over-arch committees TEND to be more concerned with
>``purity of essence'' than with ``timely, useful standards''.)

To give a real example: POSIX.4 (Real-time Extensions to POSIX.1) is almost
done. It will go in front of the IEEE Standards Board in June. There are no
test methods. To construct test methods, they should do so in an LIS form, 
plus C binding. But then the standard is not yet in LIS form. Plain old 
fashioned C. If I found out, as a poor individual programmer in the 
industry, that this useful specification was being withheld by the IEEE 
standards board because it didn't have this other thing (of NO value to 
me as programmer) called test methods, I would yell VERY LOUDLY at ANSI, 
which certifies the IEEE to produce standards. 

As always, my two cents. 

cheers,
stephe 

------------------------------------------------------------------------------
Stephen R. Walli,       stephe@mks.com | Just say ``NO'' to anticipatory 
Mortice Kern Systems Inc.              | standards. 
phone: +1 (519) 884-2251               |


Volume-Number: Volume 29, Number 93