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

  • Re: Functional Programming (was Re: iso646.h)

    From Lawrence D'Oliveiro@21:1/5 to David Brown on Sat Jan 27 20:49:24 2024
    On Sat, 27 Jan 2024 16:44:28 +0100, David Brown wrote:

    On 27/01/2024 02:10, James Kuyper wrote:

    On 1/26/24 12:31, Janis Papanagnou wrote:

    All side effects can be a problem (and should be avoided unless
    "necessary").

    Virtually everything useful that a computer program does qualifies as a
    side effect. Side effects cannot be avoided, they can only be
    controlled.

    Try telling that to Haskell programmers :-)

    The dirty little secret of pure-functional programming is that I/O cannot
    be treated in a purely functional fashion.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to Malcolm McLean on Sun Jan 28 01:18:21 2024
    On Sun, 28 Jan 2024 00:22:15 +0000, Malcolm McLean wrote:

    On 27/01/2024 20:49, Lawrence D'Oliveiro wrote:

    The dirty little secret of pure-functional programming is that I/O
    cannot be treated in a purely functional fashion.

    So the model is input - calculation - output.

    So “functional” is really “procedural-functional-procedural”.

    And what happens with interactive code? You need a loop around that sequence--another procedural construct. And maybe a conditional exit--yet another procedural construct.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Lawrence D'Oliveiro on Sun Jan 28 12:35:00 2024
    On 27/01/2024 21:49, Lawrence D'Oliveiro wrote:
    On Sat, 27 Jan 2024 16:44:28 +0100, David Brown wrote:

    On 27/01/2024 02:10, James Kuyper wrote:

    On 1/26/24 12:31, Janis Papanagnou wrote:

    All side effects can be a problem (and should be avoided unless
    "necessary").

    Virtually everything useful that a computer program does qualifies as a
    side effect. Side effects cannot be avoided, they can only be
    controlled.

    Try telling that to Haskell programmers :-)

    The dirty little secret of pure-functional programming is that I/O cannot
    be treated in a purely functional fashion.

    It can - you just have to have the IO world as an input and an output to
    your function.

    I must admit that I have never done any IO in a functional programming language. All my usage has been with "pure" functions, and it is also
    quite out of date.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to David Brown on Sun Jan 28 20:40:04 2024
    On Sun, 28 Jan 2024 12:35:00 +0100, David Brown wrote:

    On 27/01/2024 21:49, Lawrence D'Oliveiro wrote:

    The dirty little secret of pure-functional programming is that I/O
    cannot be treated in a purely functional fashion.

    It can - you just have to have the IO world as an input and an output to
    your function.

    You mean, carry around multiple copies of the entire Universe in
    individual variables?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Lawrence D'Oliveiro on Mon Jan 29 09:52:45 2024
    On 28/01/2024 21:40, Lawrence D'Oliveiro wrote:
    On Sun, 28 Jan 2024 12:35:00 +0100, David Brown wrote:

    On 27/01/2024 21:49, Lawrence D'Oliveiro wrote:

    The dirty little secret of pure-functional programming is that I/O
    cannot be treated in a purely functional fashion.

    It can - you just have to have the IO world as an input and an output to
    your function.

    You mean, carry around multiple copies of the entire Universe in
    individual variables?

    No, you only need one copy at a time :-) And you only actually need a
    bit of the universe, covering your input and output streams.

    Another option is that your code does not actually do any IO, but
    returns a function that can be applied to the world to give the results
    you want.

    Real functional programming languages have smarter ways of doing this in
    an efficient way. The functions may be pure as you see them in code,
    but the generated results do IO just like any other generated code in
    other languages. This gives you the advantages of purity at the source
    level - it's far easier to have mathematical proofs of the code's
    correctness, multi-threading or asynchronous coding is easy because you
    have no state, therefore no shared state, therefore no race conditions.
    But the end result is efficient - perhaps not "well-written C"
    efficient, but close enough to be of practical use in the real world.
    The key challenge is that you have to understand monads!

    A much simpler idea in a similar vein is that functional programming
    languages don't have iterative loops - you use lists or recursion to
    express repetition. In C, having a recursive function that works
    through a linked list is massively inefficient compared to a for loop,
    in both run-time and stack space. In a functional programming language,
    lists and recursion make it simple and clear to express the code - and
    the compiler turns it all into an iterative loop in the generated code.


    (Facebook uses Haskell for their filters and other data handling. You
    may not think much about Facebook's algorithms, but it shows that pure functional programming works fine and efficiently for big IO
    applications. Major mobile phone systems are programmed in Erlang,
    which is a functional programming language, albeit an impure one which
    can "cheat".)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to David Brown on Fri Feb 2 05:13:55 2024
    On Mon, 29 Jan 2024 09:52:45 +0100, David Brown wrote:

    (Facebook uses Haskell for their filters and other data handling.

    I’m sure that may work OK for a filter expressed as a pure function. How
    does it work for one where the filter has internal state which is changed
    as a result of prior input, and which alters the production of subsequent output?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Lawrence D'Oliveiro on Fri Feb 2 09:21:15 2024
    On 02/02/2024 06:13, Lawrence D'Oliveiro wrote:
    On Mon, 29 Jan 2024 09:52:45 +0100, David Brown wrote:

    (Facebook uses Haskell for their filters and other data handling.

    I’m sure that may work OK for a filter expressed as a pure function. How does it work for one where the filter has internal state which is changed
    as a result of prior input, and which alters the production of subsequent output?

    I have no idea. You could ask in a Haskell group, but that is well
    beyond my knowledge and well outside this group's topicality. I can
    only tell you it is not only possible in Haskell, but practical and
    viewed by a big, rich and experienced company as the best language for
    the task. As for /how/ it works, you'll have to look elsewhere.

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