On 1/23/19 12:32 AM, Hendrik Boom wrote: > On Tue, Jan 22, 2019 at 01:52:15AM -0500, George Neuner wrote: > >> I am arguing that, in computing, functions and procedures have no >> significant difference, and that distinguishing them erroneously conflates >> computing with mathematics and thus confuses people. > The distinction I've heard from people that care abut these things and that > seems to make sense are fo divide these subrutines into > > * procedures > * do things, have side effects > * Value-returning procedures > * procedures that happen to return values > * functions > * that return values and have no side effects (or side dependencies?) > > But it hasn't been very practical to make these distinctions in computer > programs, because there is no effective way to distinguish such > functions from value-returning proedures. > > The restriction that functions can use only other functions doesn't > really work because > * Too many things that behave like functions use side-effects > internally while returning values that depend only on their arguments. > * Applied strictly, it rules out memo pads. > > The distinction, if it could be practically enforced, would give > optimisers significant opportunity for program tranformation. > > -- hendrik > I think this is a vocabulary and definitions question. It is very useful to be able to talk about these things and distinguish between them. For example, one could demand a side effect free thing to be able to easily write unit tests later on for that thing. Many parts of a program can consist of side effect free things, before at some point there will be side effects. Might be the only side effects are putting something out on command line and the whole rest is always only depending on arguments and never accessing anything global or outside of the scope. Also side effect free parts can be distinguished in natural language, by the way we talk about them and tested separately and more easily. Someone new to the field will hopefully ask what the differences are and will learn then and then be able to talk precisely about it as well.
This is a reason why I personally think making the distinction is useful, even if you cannot have the side effect free stuff all the way through every part of a useful usable program. Communication is an important part, not only writing the code. The definition you gave of the categories of subroutines is what I heard / read / saw as well. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
