[J3] work on F202X at #217?

[Malcolm Cohen]

Hi Tom,

 

> understand the distinctions between 2,3,and 4

 

Indeed, many times the distinction between requirements, specifications, and syntax, can get rather blurred.

 

But in general:

 

Requirements: from the general user point of view of what kind of thing he wants to do (perhaps “I want to be able to multiply matrices”).  But formal, whereas “use cases” are informal and example-oriented (nothing wrong with that of course!).  So this is “What are you trying to achieve?”

 

Specifications: from the language point of view in abstract (perhaps “there should be an intrinsic procedure that does matrix multiplication, and it should be capable to multiplying a matrix by a vector too”).  So this is “What approach to take to achieve it?”

 

Syntax: the language point of view in concrete (perhaps “it’s a function called MATMUL with arguments blah and …”).  So this is “How to actually achieve it.”

 

Actually MATMUL is not a big and complicated enough feature to really show the difference, but perhaps it’s just big enough to give the idea.

 

Vipul Parekh asks:

>What would an "ideal paper"
>submission with *use cases" and "formal requirements" look like.

 

Well, you don’t have to have the use cases in with the requirements – for anything of any size, they really should be separate papers.  Perhaps usually the requirements can get distilled out of the use cases, but they really are quite different.

 

IIRC we did formal requirements for Parameterized Derived Types before doing the formal specifications, and again iirc it took a quite a bit of subgroup’s time at one meeting just to do the formal requirements (I think we did the formal specs at the next meeting).  Unfortunately the electronic records from that time are pretty spotty (the J3 website has even less than what I managed to keep!) so that’s not terribly useful as an example.  But it was valuable, even though there had been lots of proposals and work done on it earlier.

 

Anyway, for anything of any complexity (hello generic programming!) we need to get agreement on the Requirements, viz what are we trying to achieve, before we start on the specs and syntax, otherwise people are going to be trying to achieve different things with their contributions!  Which is at best a recipe for confusion.

 

Hopefully that helps; I can’t convey entire courses worth of design methodology via email… we’ll just have to do our best.

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20180727/e33d181e/attachment.html>