Home > Archive > Functional > June 2007 > C. de Dinechin's Backus blog ?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
C. de Dinechin's Backus blog ?
|
|
| news@absamail.co.za 2007-06-03, 8:04 am |
| Since my prefered ETH-oberon browser doesn't handle:
http://grenouille-bouillie.blogspot...03/john-backus\
-passed-away-fortran-lives.html
I'm posting here. Besides this is of general interest and not only
for an individual's blog.
In analysing Backus' classical '97 paper, Christophe de Dinechin writes:
> However, I am not really convinced by the kind of notation that Backus
> advocated. Let's consider the inner product example he gave. The "von
> Neumann" programming style he showed was:
>
> c := 0
> for i := 1 step 1 until n do
> c := c + a[i] * b[i]
>
> The suggested functional replacement would look something like:
>
> def InnerProduct =
> (Insert +) o (ApplyToAll *) o Transpose
>
> In that second code, o denotes functional composition (this is a
> notation often used in mathematics). The notation Transpose
> corresponds to the operation of switching lines and columns. The
> notation ApplyToAll * indicates that you apply the multiplication to
> each pair of numbers. The notation Insert + indicates that you insert
> an addition between the resulting adjacent elements.
> As terse and parallelizable as this notation might be, it is not at
> all the way I think about the [20]mathematical inner product. For one,
> the Transpose that Backus refers to is not the mathematical
> transposition that appears in one of the possible formulations, where
> you use a matrix multiplication. The mathematical definition would
> look more like:
>
> def [X|Y] = tX M Y
-- snip
Are you saying the maths is wrong ? That would be remarkable, for a
classical article which has survived for decades.
> More importantly in Backus' reasoning, nothing in the program above
> forces the program to go through the von Neumann bottleneck. It is
> possible (and desirable) that the representation for matrix and vector
> are efficient, sparse, and that the matrix multiplication is
> parallelized like crazy or takes advantage of vector units if they
> exist.
> In conclusion, imperative programming languages now can benefit from
> the high-level of abstraction that Backus thought was reserved to the
> functional programming style.
That's the type of conclusion which concerns me. Is it 'general', and
can you demonstate it by a non-math-intensive example ?
I was very impressed by this often mentioned article, which I fetched
from acm as 'photo-copied' pdf; and will take it to a shop tomorrow
to get printed - I don't have OCR facilities, nor ideas to handle all the
maths symbols.
I'd hate to spend resources analysing the article if you KNOW that it's
irrelevant today.
Is there anybody else who can/does discuss Backus' main contentions ?
Why didn't he take it further in his life time ?
I know that Wirth's contentions from decades ago are valid, because
I'm living them daily.
== Chris Glur.
PS. where would I get a file of the article which I can easier morph
[with most of the text as ascii] to my ETH-oberon system.
ETH-oberon can also do 'math-chars'; and while I'm morphing it,
I'll study the contents.
| |
| Ben Bacarisse 2007-06-03, 7:04 pm |
| news@absamail.co.za writes:
> Since my prefered ETH-oberon browser doesn't handle:
> http://grenouille-bouillie.blogspot...03/john-backus\
> -passed-away-fortran-lives.html
> I'm posting here. Besides this is of general interest and not only
> for an individual's blog.
>
> In analysing Backus' classical '97 paper, Christophe de Dinechin
> writes:
I don't know where the date error comes from but I does Backus a great
disservice! The (now) classic paper was published in 1977.
> -- snip
>
> Are you saying the maths is wrong ? That would be remarkable, for a
> classical article which has survived for decades.
Quite. Transpose is defined by Backus to in exactly the same way any
mathematician would. Every functional language since has had such a
function in its standard library (in the SASL/KRC/Miranda/Haskell
family it is called zip).
>
> That's the type of conclusion which concerns me. Is it 'general', and
> can you demonstate it by a non-math-intensive example ?
Modern compilers can, indeed, "vectorise" some loops. Backus, writing
in '77, wanted to use a persuasive engineering argument to promote a
functional style so he talked about the von Neumann "bottle neck" but
the title of the paper refers to liberating programming from the von
Neumann *style*. Backus understood that the best argument for a
functional style is that the programs are simpler and easier to write
and reason about.
> I was very impressed by this often mentioned article, which I fetched
> from acm as 'photo-copied' pdf; and will take it to a shop tomorrow
> to get printed - I don't have OCR facilities, nor ideas to handle all the
> maths symbols.
> I'd hate to spend resources analysing the article if you KNOW that it's
> irrelevant today.
>
> Is there anybody else who can/does discuss Backus' main contentions ?
> Why didn't he take it further in his life time ?
He did. He developed FP and the FL. There were languages like APL
and Lisp that already had most of building-blocks required, but newer
languages like SASL[1] (in some sense the great granduncle of Haskell)
with curried functions and lazy evaluation made the style more
natural.
Backus's style lives on in modern languages like Haskell when one
writes functions in a "point free" style.
[1] St Andrews Static Language. First described in 1976 -- the late
'70s was a good time for programming language development.
--
Ben.
| |
|
|
|
|
|