In article <>, solidius4747@gmail.com wrote:

V=C3=A0o 10:13:11 UTC+7 Th=E1=BB=A9 n=C4=83m, ng=C3=A0y 24 th=C3=A1ng t=C6= =B0 n=C4=83m 2014, Paul Rubin =C4=91=C3=A3 vi=E1=BA=BFt:

solidius4747@gmail.com writes:

I has always been thinking this, but I need a confirmation: The purpose of = functional programming is to make written program becomes a mathematical pr= oof. Once a program is correctly written, it is "proved" and is expected to=
work the same in any environment. This is why in FP, immutable is needed, = otherwise there's no guarantee for the correctness of the "proof", because = state changes can introduce unexpected behaviors.

Am I correct on the basis of Functional Programming?

Users of Haskell wouldn't know how to or want to
'formally prove correctness'.

If you read their hand-waiving carefully, you can interpret
it to mean: "because it feels nice".

A massive economy of effort [in maintenance, which is
important] is available from 'piping'.
[functional means 'give input & accept output' = piping]

Eg. if you've got a multi-stage process like:--
output textfile |
translate "US" to "you ess" |
delete <crap> | delete <crap2> |
input to TestToSpeech |
translate *.wav to *.mp3 |
store to playing device

And then there's a new fad/virus of replacing apostrophe with 3 bytes,
so your system says "sea aye en tea" instead of "can't",
without being confused by the details of the multistages,
you can just 'slot in a function' [say just before "input to TestToSpeech"] which translates the 3-bytes to the single-byte ASCII(singleQuote).

Modularity: the greatest productivity tool; means you only need be
concerned with a small part of the whole system ............

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

no.top.post@gmail.com writes:

You are replying to a post from nearly two years ago. That's not
usually very productive but you never know...

In article <>, solidius4747@gmail.com wrote:

V=C3=A0o 10:13:11 UTC+7 Th=E1=BB=A9 n=C4=83m, ng=C3=A0y 24 th=C3=A1ng t=C6= >> =B0 n=C4=83m 2014, Paul Rubin =C4=91=C3=A3 vi=E1=BA=BFt:

solidius4747@gmail.com writes:

I has always been thinking this, but I need a confirmation: The purpose of = >> functional programming is to make written program becomes a mathematical pr= >> oof. Once a program is correctly written, it is "proved" and is expected to= >> work the same in any environment. This is why in FP, immutable is needed, = >> otherwise there's no guarantee for the correctness of the "proof", because = >> state changes can introduce unexpected behaviors.

It's that the sate make it harder. Nothing about a well-written program
should be "unexpected" but even so the proofs are more complex when
state is being changed at almost every stage.

Am I correct on the basis of Functional Programming?

Users of Haskell wouldn't know how to or want to
'formally prove correctness'.

All of them?

If you read their hand-waiving carefully, you can interpret
it to mean: "because it feels nice".

A massive economy of effort [in maintenance, which is
important] is available from 'piping'.
[functional means 'give input & accept output' = piping]

Eg. if you've got a multi-stage process like:--
output textfile |
translate "US" to "you ess" |
delete <crap> | delete <crap2> |
input to TestToSpeech |
translate *.wav to *.mp3 |
store to playing device

Right. That's why a lot of Haskell programs are written like that.
"Piping" is a natural pattern in lazy function languages.

<snip>
--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)