SUO: Ballot Response on IFF
I vote YES to the IFF ballot with the comments attached below.
Frank Farance
-------------------------------------------------------------
1. The IFF document is rather large and, although there is nothing inherently wrong with a 110+ page document, I had a hard time understanding the document as a "standards document", i.e., a specification that makes requirements that describe conforming implementations. In other words, it wasn't clear what assertions were being made (i.e., "shall" wording that would describe a specification). Also, the size of the document, combined with the lack of the IEEE style (e.g., Clause 1: Scope/Purpose; Clause 2: Normative References; Clause 3: Defintions; Clause 4: Conformance; Clause 5: Conceptual/Theoretical Model; etc.).
2. The document needs to develop a notion of "conformance", i.e., how can I tell whether or not an implementation conforms to this specification.
3. The "programming language" analogy was somewhat helpful, but I feel it could have been further developed with a couple significant illustrations. For example, in "real" programming language paradigm, when it is presented (say, for some particular programming language), the illustations look something like the following:
// "high level" programming language constructs
a = 17; // "a" is a scalar
c = b*a; // "b" and "c" are vectors (1-dimensional array)
// "high level" code is transformed into assembler
movl $17,a
movl $0,i
.L3:
movl i,%eax
cmpl n,%eax
jl .L6
jmp .L4
.L6:
movl i,%eax
movl %eax,%edx
leal 0(,%edx,4),%eax
movl $c,%edx
movl i,%ecx
movl %ecx,%ebx
leal 0(,%ebx,4),%ecx
movl $b,%ebx
movl (%ecx,%ebx),%ecx
imull a,%ecx
movl %ecx,(%eax,%edx)
// ... and so on ...
// assembler is transformed into opcodes/machine language:
0000000 457f 464c 0101 0001 0000 0000 0000 0000
0000020 0001 0003 0001 0000 0000 0000 0000 0000
0000040 026c 0000 0000 0000 0034 0000 0000 0028
0000060 0006 0001 2e00 7473 7472 6261 2e00 6574
0000100 7478 2e00 6f63 6d6d 6e65 0074 732e 6d79
0000120 6174 0062 756a 6b6e 632e 0000 6367 3263
0000140 635f 6d6f 6970 656c 2e64 0000 7566 636e
// and so on ...
So with this kind of illustration, it is easy to see (assuming you know the programming language, assembler, and opcodes) what the transformation is and why this "programming language architecture" makes sense.
I agree that this kind of paradigm described in IFF can be useful, but I believe it needs to be fleshed out further with better illustrations.
4. It is my impression that the IFF document could serve as a theoretical framework ... it might be possible to merge these theoretical aspects (e.g., a Clause for "Conceptual Model" or "Theoretical Model") with the current SUMO work. I encourage this kind of merge.
5. I don't believe the current draft of IFF is appropriate for a sponsor ballot, but I believe IFF (like SUMO) is a good starting point and IFF should be further developed.
6. There are parts of the document that I still don't completely comprehend, so I may have additional comments on future drafts of IFF.
-------------------------------------------------------------
-----------------------------------------------------------------------
Frank Farance, Farance Inc. T: +1 212 486 4700 F: +1 212 759 1605
mailto:frank@farance.com http://farance.com
Standards, products, services for the Global Information Infrastructure