Re: P1788 1.8 "Language considerations"

[Ian McIntosh <ianm@xxxxxxxxxx>]

I think we should leave Von Neumann out of the standard wording.

Von Neumann's idea was about computer hardware architecture, not programming languages. His fundamental contribution was the idea that instead of having instructions stored in one memory and data stored in another, you could have both in a single memory. Aside from simplicity, that allows some programs to operate on other programs, or programs to operate on themselves. See
http://last3.in/2010-11/CSE101/lectures/10-von-neumann-notes.html

Over time people have used his name for other ideas and more recently for programming language design. If you really did apply his idea to programming languages, I think you'd have languages with features allowing programs to modify themselves and each other. Some can do that, but most can't. In any case it's not what we're talking about.

The better distinction is between functional languages and procedural languages.

- Ian McIntosh IBM Canada Lab Compiler Back End Support and Development


John Pryce ---12/05/2012 08:45:49 AM---Nick, Vincent, P1788 On 5 Dec 2012, at 09:28, Vincent Lefevre wrote:

From:	John Pryce <j.d.pryce@xxxxxxxxxx>
To:	Ian McIntosh/Toronto/IBM@IBMCA
Date:	12/05/2012 08:45 AM
Subject:	Re: P1788 1.8 "Language considerations"

---

Nick, Vincent, P1788

On 5 Dec 2012, at 09:28, Vincent Lefevre wrote:
> I have two comments concerning §1.8:
> 
> 1. Its first paragraph is:
> 
>  All relevant languages are based on the concepts of data and
>  transformations. In Von Neumann languages, data are held in
>  variables, which are transformed by assignment. In functional
>  languages, input data are supplied as arguments; the transformed
>  form is returned as results. Dataflow languages vary considerably,
>  but use some form of the data and transformation approach.
> 
> Actually this is not quite true or not well formulated, IMHO. In
> Von Neumann languages, one also has control. In functional languages,
> one can also return functions, which are not just a transformation
> of the inputs, but also depend on the context (notion of closure).
> I think that what really matters is that all languages can incorporate
> the dataflow model, even though they can do more. The first sentence
> could be changed to something like:
> 
>  All relevant languages use, among others, the concepts of data and
>  transformations.

That change looks good to me. 

> 2. The second paragraph seems to be about the approximation of real
> arithmetic. But in P1788, intervals can be used for other things,
> such as range computation.

That seems a fair point. In view of range computation's importance in global optimisation, Nate Hayes' branch & bound algorithms, etc., it should not be excluded; the current wording does rather exclude it.

And I had a related reservation about the sentence after item (4): "Specifically, if the data before and after ... posterior set." This is a description of the behaviour of interval *arithmetic operations* -- interval extensions of real point functions. 

I would welcome a rephrasing to recognise that the standard specifies other interval operations, such as intersection & convexHull, as well as ones that transform interval(s) to a non-interval: midpoint, comparison operations, etc.

I don't think we need much, if any, new material; rather a rewording that manages to be more inclusive.

John Pryce