Proposed new syntax

[Rustom Mody]

On Monday, August 14, 2017 at 10:35:22 PM UTC+5:30, Terry Reedy wrote:
> On 8/14/2017 5:59 AM, Ben Finney wrote:
> 
> > At what point will you accept the feedback: That the comprehension
> > syntax *does not* necessarily connote a procedural loop, but instead can
> > quite reasonably be interpreted as its designer intended, a single
> > conceptual operation.
> 
> In a world where functions have 'side-effects', which is to say, 
> implicit inputs and outputs, procedural order is necessary for 
> predictable outcomes.  The 'single conception operation' is ambiguious.
> 
> Suppose stdin contains "a\nb\nc\nd\ne\nf\ng\n".
> What is the meaning of
> [input(f"response{i}") for i in range(6)]?
> In Python, the predictable result is
> ['a', 'b', 'c', 'd', 'e', 'f']
> It would not be with some of Rustom Mody's 'equivalents'.
> Or let L = <list above>.
> This implementation of list reversal: [L.pop() for i in range(len(L))]

In languages, especially those with a clearly separated lang-spec from 
specific implementation-spec (eg C99), there is a sharp distinction made between
- undefined behaviour
- unspecified behaviour
- erroneous behaviour


Roughly: 
- Erroneous means compiler/runtime should flag an error
- Undefined means implementation can format your hard disk and clear your bank 
  account
  https://stackoverflow.com/questions/18420753/unspecified-undefined-and-implementation-defined-behavior-wiki-for-c
- Unspecified means not error but not spelled out

My point of suggesting those alternative implementations is precisely 
to make your examples above fall squarely into unspecified category

Note that this would square with the informal practice seen in places like
this ML/NG where a noob asks a question using a comprehension such as the
ones you've used and someone more experienced pipes up "Dont do that"


> Do not functional languages define comprehensions in terms of recursion,
> equivalent to for loops? 

At the risk of some over-simplification, the idea of functional languages is
to move above behavior from unspecified to erroneous category.
IMHO this is not in line with python's genus as an imperative dynamically typed
language

[In haskell, putchar, getchar etc exist and have monadic type.
Which is a funny way of saying that the type system takes cognisance of and 
rigorously enforces the side-effecting nature of such functions.
Which also means there are no side-effects; only effects, clearly flagged
with the monadic type]