Clarify 2.0.4

[lestrrat]

The doc reads:

A P6SGI application TYPICALLY returns a Promise. (emphasis mine)

Since it says TYPICALLY, and not MUST, I could interpret it as "You can return anything you want, but you should support Promises", but I'm not sure if I'm correct. The following examples only descrive Promises/Supply use cases, so I'm not sure.

Can we clarify this?

Also, if you meant to only allow Promise/Supply, I strongly urge to change the spec to allow the simplest form, which is

sub app(%env) {
    200, [ Content-Type => 'text/plain' ],  'Hello World'
}

Because that's probably the only form that most simple applications need.

[zostay]

It is clarified in 2.2.4, insofar as the application is concerned. It could be clearer what the server's actual expectations should be.

I avoid making any statements of requirement for applications in section 2.0 and, similarly, avoid making any statements of requirement for servers in section 2.1 and 2.2.

What is meant is that the application may return a Promise or something that coerces into a Promise, such as a Supply. I consider that to be a controversial feature of the spec, though. Since type coercions can only be employed during variable assignment (e.g., lexical declaration or parameter passing), allowing an application to return something like a Supply is surprisingly ugly to implement, particularly in middleware. As such, we may be better off just requiring a Promise.

I'm hoping to make that decision based on my experience in building the reference implementation, Smack, which I need to get back into now that I have my new laptop.

[zostay]

I believe recent changes I've made to the 2.x.4 sections over the last few days should clarify this issue a bit. Please let me know if you disagree.