1. Forum
  2. Usenet
  3. COMP.LANG.FUNCTIONAL

  • The goal of functional programming?

    From [email protected]@21:1/5 to [email protected] on Sat Mar 5 14:35:40 2016
    In article <>, [email protected] 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:
    [email protected] 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)
  • From Ben Bacarisse@21:1/5 to All on Sat Mar 5 15:04:27 2016
    [email protected] writes:

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

    In article <>, [email protected] 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:
    [email protected] 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)