lembark (6) [Avatar] Offline
#1
The book seems to argue that use of state-full calls is never appropriate for FP, that functions must take and return values or they are not mathematically sound.

Catch: The reality I work in makes frequent use of pseudo-random number generators, calls to acquire system time, and database interfaces that return the next record in a sequence. None of these has a particularly useful input, nor would I expect them to return the same values each time they are called.

I can see the point of having data-munging functions take and return values; I cannot see the advantage of a functions making random selections from a list returning the same values with each call.

By this point is the book I'd have expected something more than "trust the maths" to address how these issues would be handed in FP, or at least how Scala deals with them.
Dylan (1) [Avatar] Offline
#2
I believe that the FP answer to these kinds of patterns is that such "hidden" arguments (such as a cursor position in a file stream or database response) should be made explicit. In this pattern, you'd pass the current cursor position into next, and get a tuple of the output, and a new cursor position out.

On top of this style of API, you can build powerful abstractions like mapping a function over all of the next()'s, which is both easy to read, and easier to analyze than the imperative alternatives.

I understand that Microsoft's LINQ database API (designed by Erik Meijer - prominent in the FP community) follows this pattern, and has been well-received by the folks who have adopted it.
lembark (6) [Avatar] Offline
#3
The problem with keeping a record number argument is that either the database handle has to be returned as a separate value each time to bookkeep the argument or a separate record-number argument has to be passed to any entry point that might have a call below it at any level with the current next record count. This means basically having to pass the record number to anyplace that might have the database handle available. This is doable, but seems messy. If linq's API makes this workable, fine: I'd like to see an example.

Which still leaves the question of what arguments are useful for rand() and time(), which seem inherently stateful (e.g., passing the last random number around to pass into any call anywere in any level of the code that might call random seems like a waste).

The point is that FP may have to interface with stateful systems to do its work: time, random, database, filesystem. The question is how to make that interface reasoanble, without loosing the advantages of FP.