* Naming convention to identify functions with side effects @ 2008-09-29 18:17 Hibou57 (Yannick Duchêne) 2008-09-29 18:45 ` Hibou57 (Yannick Duchêne) ` (3 more replies) 0 siblings, 4 replies; 24+ messages in thread From: Hibou57 (Yannick Duchêne) @ 2008-09-29 18:17 UTC (permalink / raw) Hello every body out there, Do some one know a commonly used or at least a good, naming convention to identify functions with side effects ? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-09-29 18:17 Naming convention to identify functions with side effects Hibou57 (Yannick Duchêne) @ 2008-09-29 18:45 ` Hibou57 (Yannick Duchêne) 2008-09-29 18:55 ` Adam Beneschan ` (2 subsequent siblings) 3 siblings, 0 replies; 24+ messages in thread From: Hibou57 (Yannick Duchêne) @ 2008-09-29 18:45 UTC (permalink / raw) Probably to name it as a verb .... ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-09-29 18:17 Naming convention to identify functions with side effects Hibou57 (Yannick Duchêne) 2008-09-29 18:45 ` Hibou57 (Yannick Duchêne) @ 2008-09-29 18:55 ` Adam Beneschan 2008-09-29 19:52 ` Dmitry A. Kazakov 2008-09-29 20:57 ` Georg Bauhaus 2008-09-29 22:22 ` Dr. Adrian Wrigley 3 siblings, 1 reply; 24+ messages in thread From: Adam Beneschan @ 2008-09-29 18:55 UTC (permalink / raw) On Sep 29, 11:17 am, Hibou57 (Yannick Duchêne) <yannick_duch...@yahoo.fr> wrote: > Hello every body out there, > > Do some one know a commonly used or at least a good, naming convention > to identify functions with side effects ? I don't. But I'll take advantage of this to discuss one thing that I think is a REALLY BAD IDEA. To me, "functions with side effects" can encompass at least three different types of functions, and perhaps the answer to your question should be different for all three: (1) Functions that really are (mathematically) functions, and that will return the same value each time you call them with the same parameters, but they may also save some state information in order to help make the next execution run faster. (2) Functions whose purpose is to return a value, but that can return different values each time they're called. An example would be a random number generator function that returns a different value each time it's called, or a function whose purpose is to return the "next" word from a file, so that successive calls to the function return successive values from the file. (3) "Functions" whose purpose is to perform some task, and that also return a value but only as a secondary purpose or a result indicator. This is sometimes a little harder to do in Ada than other languages, because functions can't have OUT or IN OUT parameters, but it's still possible. A common usage I've seen is to have a function that, say, opens a file and returns a Boolean to indicate whether the operation was successful. I think you can make a case that you shouldn't write this as a function; nevertheless, it's commonly done (yes, I do it sometimes). It's this last that is connected to one of my pet peeves. Say you've decided to write a routine to load a particular web page, and you've made it a Boolean function that returns True if it's successful: function Load_Web_Page (URL : String) return Boolean; Several times, I've heard people say (in similar cases) that the name should be something like this: function Web_Page_Is_Loaded (URL : String) return Boolean; so that it's grammatically correct when you put it in an IF statement: if Web_Page_Is_Loaded ("http://www.irvine.com") then... This is WRONG, WRONG, WRONG!!! It may make your IF statement look more grammatically correct, but it OBSCURES what the program is doing. The above "grammatically correct" statement looks more like a check to see if the page is already loaded; a programmer reading this will not be able to figure out that the function call is the routine that actually does the loading. This is much better: if Load_Web_Page ("http://www.irvine.com") then... because now the reader knows that this call is actually loading the web page, even if it violates a rule of English grammar. So while I don't have a good answer to your question, I *can* tell you that if anyone says that a Boolean function should *always* have a name that is an adjective, or a past participle, or a predicate, rather than just a verb, don't listen to them. Thank you for patiently sitting through my rant. -- Adam ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-09-29 18:55 ` Adam Beneschan @ 2008-09-29 19:52 ` Dmitry A. Kazakov 2008-09-29 20:48 ` Georg Bauhaus 0 siblings, 1 reply; 24+ messages in thread From: Dmitry A. Kazakov @ 2008-09-29 19:52 UTC (permalink / raw) On Mon, 29 Sep 2008 11:55:49 -0700 (PDT), Adam Beneschan wrote: > It's this last that is connected to one of my pet peeves. Say you've > decided to write a routine to load a particular web page, and you've > made it a Boolean function that returns True if it's successful: > > function Load_Web_Page (URL : String) return Boolean; > > Several times, I've heard people say (in similar cases) that the name > should be something like this: > > function Web_Page_Is_Loaded (URL : String) return Boolean; > > so that it's grammatically correct when you put it in an IF statement: > > if Web_Page_Is_Loaded ("http://www.irvine.com") then... > > This is WRONG, WRONG, WRONG!!! It may make your IF statement look > more grammatically correct, but it OBSCURES what the program is > doing. The above "grammatically correct" statement looks more like a > check to see if the page is already loaded; a programmer reading this > will not be able to figure out that the function call is the routine > that actually does the loading. This is much better: > > if Load_Web_Page ("http://www.irvine.com") then... I don't like either. They hide the side-effect instead of publishing it. Is_Loaded is a property of a page, it is not of an URL. To me it should be: type Web_Page is ...; function Load (URL : String) return Web_Page; function Is_Loaded (Page : Web_Page) return Boolean; Should pages be cached, then the cache of pages must be exposed: type Web_Page is ...; type Web_Pages_Cache is ...; procedure Load (Cache : in out Pages_Cache; URL : String); function Is_Loaded (Cache : Pages_Cache; URL : String) return Boolean; function Get_Loaded (Cache : Pages_Cache; URL : String) return Web_Page; -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-09-29 19:52 ` Dmitry A. Kazakov @ 2008-09-29 20:48 ` Georg Bauhaus 2008-09-29 21:10 ` Adam Beneschan ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Georg Bauhaus @ 2008-09-29 20:48 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Mon, 29 Sep 2008 11:55:49 -0700 (PDT), Adam Beneschan wrote: >> Several times, I've heard people say (in similar cases) that the name >> should be something like this: >> >> function Web_Page_Is_Loaded (URL : String) return Boolean; >> >> so that it's grammatically correct when you put it in an IF statement: >> >> if Web_Page_Is_Loaded ("http://www.irvine.com") then... >> >> This is WRONG, WRONG, WRONG!!! It may make your IF statement look >> more grammatically correct, but it OBSCURES what the program is >> doing. The above "grammatically correct" statement looks more like a >> check to see if the page is already loaded; a programmer reading this >> will not be able to figure out that the function call is the routine >> that actually does the loading. This is much better: >> >> if Load_Web_Page ("http://www.irvine.com") then... > > I don't like either. Me neither. While a style of "packed programming" might be expected in SETL or APL, I can't imagine this sort of cleverness to be a preference when using a deliberately verbose language such as Ada. A more strict recommendation is perhaps worth noting, named the Command-query separation (coined by Betrand Meyer). For primitive functions of some type T (called queries, like Is_Loaded), it means the functions should not have abstract side effects. "Abstract side effects" are side effects that can change the return value of public functions of type T. (Functions are the only means to query the state of an object of type T.) Some issues become more obvious in a concurrent setting perhaps, Web_Page.Load ("http://www.irvine.com"); if Web_Page.Is_Loaded then... There needs to be a lock of some sort joining the two calls. Otherwise, the Web_Page object might have changed between the two calls, a logic error. Again, it might be tempting to pack the two calls in just one in order to hide the locking mechanism, to give the illusion of atomicity. But shouldn't normal Ada concurrency features be employed instead? If concurrency features of Ada are used instead, the naming problem is also gone: the commands (procedures) can be verbs and the queries (predicate functions) can be named "Is_Something" or "Has_Something". ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-09-29 20:48 ` Georg Bauhaus @ 2008-09-29 21:10 ` Adam Beneschan 2008-09-30 15:17 ` Georg Bauhaus 2008-10-02 12:33 ` Ole-Hjalmar Kristensen 2008-10-03 11:51 ` Brian Drummond 2 siblings, 1 reply; 24+ messages in thread From: Adam Beneschan @ 2008-09-29 21:10 UTC (permalink / raw) On Sep 29, 1:48 pm, Georg Bauhaus <see.reply...@maps.futureapps.de> wrote: > Again, it might be tempting to pack the two calls in just > one in order to hide the locking mechanism, to give the > illusion of atomicity. But shouldn't normal Ada > concurrency features be employed instead? This is a bit too esoteric for me. I think a much simpler reason for the temptation to pack the two calls into just one is that it makes it easier to stick the call into more complex Boolean expressions, e.g. (assuming URL_Name's type is access string): if URL_Name /= null and then Load_Web_Page (URL_Name.all) then ... [stuff to do if we succeed] else ... [other stuff] end if; Separating the procedure call and the query sounds like a great idea theoretically, but it does mean that things such as the above must be made more verbose (e.g. by adding a Boolean variable, as below:) if URL_Name = null then Success := False; else Web_Page.Load (URL_Name.all); Success := Web_Page.Is_Loaded; end if; if Success then ... So, right or wrong, at least one can understand the temptation to writing a Boolean function in order to make its use more concise in such cases. -- Adam ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-09-29 21:10 ` Adam Beneschan @ 2008-09-30 15:17 ` Georg Bauhaus 2008-09-30 17:40 ` Ray Blaak 0 siblings, 1 reply; 24+ messages in thread From: Georg Bauhaus @ 2008-09-30 15:17 UTC (permalink / raw) Adam Beneschan schrieb: > On Sep 29, 1:48 pm, Georg Bauhaus <see.reply...@maps.futureapps.de> > wrote: > >> Again, it might be tempting to pack the two calls in just >> one in order to hide the locking mechanism, to give the >> illusion of atomicity. But shouldn't normal Ada >> concurrency features be employed instead? > > This is a bit too esoteric for me. I think a much simpler reason for > the temptation to pack the two calls into just one is that it makes it > easier to stick the call into more complex Boolean expressions, e.g. > (assuming URL_Name's type is access string): > > if URL_Name /= null and then > Load_Web_Page (URL_Name.all) then ... > [stuff to do if we succeed] > else ... > [other stuff] > end if; This solution looks like a straight forward one at least in case of a single additional test in the conditional. However, as soon as the URL needs a little more inspection, I need more predicates. Since these are called before Load_Web_Page is called, Load_Web_Page is "pushed down" the conditional chain, hiding it and also blurring the distinct sources of error: if URL_Name /= null and then Valid_Protocol (URL_Name.all) and then Host_Allowed (URL_Name.all) and then No_Up_Directories (URL_Name.all) and then Load_Web_Page (URL_Name.all) then ... [stuff to do if all test succeed and the page was finally loaded] else ... [something has failed, maybe loading has failed, do other stuff] end if; So, first, Load_Web_Page, which presumably has the important side effect of initializing some variable, looses the focus of attention. Then, sources of error may need to be distinguished since the errors are different in character (null pointer, syntax, and I/O). Load_Web_Page (I/O), being appended to the list of predicates and the null test, becomes one of many sources of potential failure in the same conditional. Finally, the programmer wanting to reduce verbosity by making Load_Web_Page a Boolean function now causes verbosity by chaining the many predicates. This amount by far exceeds the intended reduction in verbosity and renders the original intent (of saving words) mostly fruitless. So the distinct issues become blurred in this single conditional and the Boolean function Load_Web_Page does not significantly reduce verbosity. At this point I remember advice from The Little Schemer to use little helper functions (that can be nested if needed). Thus, if Is_Acceptable (URL_Name.all) then Load_Web_Page (URL_Name.all, Data); Construct (Data, Result); else raise Syntax_Error; end if; (where URL_Name is of subtype "not null String_Ptr") Stupid obedience to command-query separation like in Is_Acceptable and Load_Web_Page might pay off in the end. Not that anyone cares. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-09-30 15:17 ` Georg Bauhaus @ 2008-09-30 17:40 ` Ray Blaak 0 siblings, 0 replies; 24+ messages in thread From: Ray Blaak @ 2008-09-30 17:40 UTC (permalink / raw) Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes: > I need more predicates. Since these are called before Load_Web_Page > is called, Load_Web_Page is "pushed down" the conditional chain, > hiding it and also blurring the distinct sources of error: > > if URL_Name /= null and then > Valid_Protocol (URL_Name.all) and then > Host_Allowed (URL_Name.all) and then > No_Up_Directories (URL_Name.all) and then > Load_Web_Page (URL_Name.all) > then ... > [stuff to do if all test succeed and the page was finally loaded] > else ... > [something has failed, maybe loading has failed, do other stuff] > end if; [...] > Finally, the programmer wanting to reduce verbosity by > making Load_Web_Page a Boolean function now causes > verbosity by chaining the many predicates. > This amount by far exceeds the intended reduction in verbosity > and renders the original intent (of saving words) mostly > fruitless. [...] > At this point I remember advice from The Little Schemer > to use little helper functions (that can be nested if > needed). Thus, > > if Is_Acceptable (URL_Name.all) then > Load_Web_Page (URL_Name.all, Data); > Construct (Data, Result); > else > raise Syntax_Error; > end if; Or, you could make Load_Web_Page only work if a page is valid: if Load_Web_Page (URL_Name.all, Data) then Construct (Data, Result); else raise Syntax_Error; end if; Or, my favourite, make Load_Web_Page be a procedure that wants only valid pages and have *it* throw any errors as needed: Load_Web_Page (URL_Name.all, Data); -- raises Syntax_Error if bad Construct (Data, Result); -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-09-29 20:48 ` Georg Bauhaus 2008-09-29 21:10 ` Adam Beneschan @ 2008-10-02 12:33 ` Ole-Hjalmar Kristensen 2008-10-03 9:18 ` Georg Bauhaus 2008-10-03 11:51 ` Brian Drummond 2 siblings, 1 reply; 24+ messages in thread From: Ole-Hjalmar Kristensen @ 2008-10-02 12:33 UTC (permalink / raw) How would you implement the lock in youre case? I prefer not to mess around with semaphores, but use protected objects instead. In that case keeping the lock across the two calls is not so trivial. >>>>> "GB" == Georg Bauhaus <see.reply.to@maps.futureapps.de> writes: <snip> GB> Some issues become more obvious in a concurrent setting GB> perhaps, GB> Web_Page.Load ("http://www.irvine.com"); GB> if Web_Page.Is_Loaded then... GB> There needs to be a lock of some sort joining the two calls. GB> Otherwise, the Web_Page object might have changed GB> between the two calls, a logic error. GB> Again, it might be tempting to pack the two calls in just GB> one in order to hide the locking mechanism, to give the GB> illusion of atomicity. But shouldn't normal Ada GB> concurrency features be employed instead? GB> If concurrency features of Ada are used instead, the GB> naming problem is also gone: GB> the commands (procedures) can be verbs and the queries GB> (predicate functions) can be named "Is_Something" or GB> "Has_Something". -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-10-02 12:33 ` Ole-Hjalmar Kristensen @ 2008-10-03 9:18 ` Georg Bauhaus 2008-10-06 7:24 ` Ole-Hjalmar Kristensen 0 siblings, 1 reply; 24+ messages in thread From: Georg Bauhaus @ 2008-10-03 9:18 UTC (permalink / raw) Ole-Hjalmar Kristensen wrote: > How would you implement the lock in youre case? I prefer not to mess > around with semaphores, but use protected objects instead. In that > case keeping the lock across the two calls is not so trivial. In a simple, maybe simplistic way I'd hide the lock. package News26 is subtype URL is String; type Web_Resource is tagged limited private; -- ... Observe the calling protocol, which is -- Load -> Is_Loaded -> Discard function Is_Loaded (Page: Web_Resource) return Boolean; procedure Load (Page: in out Web_Resource; Location: URL); procedure Discard (Page: in out Web_Resource); private protected type Resource is entry Seize; procedure Release; private Busy: Boolean := False; end Resource; type Web_Resource is tagged limited record Lock: Resource; -- ... end record; end News26; Procedure Load will then Seize the Lock. Another scheme could, I think, be using Dmitry's Page_Cache administrating the sequencing of calls by slot-wise locking or some such. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-10-03 9:18 ` Georg Bauhaus @ 2008-10-06 7:24 ` Ole-Hjalmar Kristensen 0 siblings, 0 replies; 24+ messages in thread From: Ole-Hjalmar Kristensen @ 2008-10-06 7:24 UTC (permalink / raw) Yes, this works fine as long as all callers respect the calling protocol, but I have spent countless hours tracking down bugs which come from people *not* respecting such protocols, so I do not really like such solutions unless you can guarantee that the resource will be released sooner or later. >>>>> "GB" == Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> writes: GB> Ole-Hjalmar Kristensen wrote: >> How would you implement the lock in youre case? I prefer not to mess >> around with semaphores, but use protected objects instead. In that >> case keeping the lock across the two calls is not so trivial. GB> In a simple, maybe simplistic way I'd hide the lock. GB> package News26 is GB> subtype URL is String; GB> type Web_Resource is tagged limited private; GB> -- ... Observe the calling protocol, which is GB> -- Load -> Is_Loaded -> Discard GB> function Is_Loaded (Page: Web_Resource) return Boolean; GB> procedure Load (Page: in out Web_Resource; Location: URL); GB> procedure Discard (Page: in out Web_Resource); GB> private GB> protected type Resource is GB> entry Seize; GB> procedure Release; GB> private GB> Busy: Boolean := False; GB> end Resource; GB> type Web_Resource is tagged limited GB> record GB> Lock: Resource; GB> -- ... GB> end record; GB> end News26; GB> Procedure Load will then Seize the Lock. GB> Another scheme could, I think, be using Dmitry's Page_Cache GB> administrating the sequencing of calls by slot-wise locking GB> or some such. -- C++: The power, elegance and simplicity of a hand grenade. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-09-29 20:48 ` Georg Bauhaus 2008-09-29 21:10 ` Adam Beneschan 2008-10-02 12:33 ` Ole-Hjalmar Kristensen @ 2008-10-03 11:51 ` Brian Drummond 2008-10-03 12:28 ` Dmitry A. Kazakov 2008-10-03 13:15 ` Jeffrey Creem 2 siblings, 2 replies; 24+ messages in thread From: Brian Drummond @ 2008-10-03 11:51 UTC (permalink / raw) On Mon, 29 Sep 2008 22:48:20 +0200, Georg Bauhaus <see.reply.to@maps.futureapps.de> wrote: >Dmitry A. Kazakov wrote: >> On Mon, 29 Sep 2008 11:55:49 -0700 (PDT), Adam Beneschan wrote: > >>> if Web_Page_Is_Loaded ("http://www.irvine.com") then... >>> if Load_Web_Page ("http://www.irvine.com") then... >> >> I don't like either. > >Me neither. > >Some issues become more obvious in a concurrent setting >perhaps, > > Web_Page.Load ("http://www.irvine.com"); > > if Web_Page.Is_Loaded then... > >There needs to be a lock of some sort joining the two calls. >Otherwise, the Web_Page object might have changed >between the two calls, a logic error. As someone relatively new to Ada, I have to ask, is there need for anything more sophisticated than Web_Page.Load ("http://www.irvine.com", Loaded); if Loaded then... which avoids side effects in functions, preserves the atomicity of the operation and test, but allows the test result to be used later. (The web page may indeed change, but "Loaded" refers to the version extant during the .Load call) Its intent and operation are quite clear, and it's a common paradigm in other languages. Beyond being a little untidy, is there any reason for avoiding it? - Brian ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-10-03 11:51 ` Brian Drummond @ 2008-10-03 12:28 ` Dmitry A. Kazakov 2008-10-04 12:30 ` Marco 2008-10-03 13:15 ` Jeffrey Creem 1 sibling, 1 reply; 24+ messages in thread From: Dmitry A. Kazakov @ 2008-10-03 12:28 UTC (permalink / raw) On Fri, 03 Oct 2008 12:51:33 +0100, Brian Drummond wrote: > As someone relatively new to Ada, I have to ask, is there need for > anything more sophisticated than > > Web_Page.Load ("http://www.irvine.com", Loaded); > if Loaded then... > > which avoids side effects in functions, preserves the atomicity of the > operation and test, but allows the test result to be used later. Side-effects are bad in any subprograms, be them functions or procedures. When the effect of the operation Load is solely the state of Web_Page then you should be able to spell it as: Web_Page.Load ("http://www.irvine.com"); if Web_Page.Loaded then... > (The web page may indeed change, but "Loaded" refers to the version > extant during the .Load call) What is the use of this test if it does not reflect the state of Web_Page? > Its intent and operation are quite clear, and it's a common paradigm in > other languages. > > Beyond being a little untidy, is there any reason for avoiding it? Yes. In this design the effect of Load is the tuple (Web_Page, Loaded). It is considerably more difficult for the reader to understand how the effect is distributed among the tuple members, and when and if their separate states are consistent to the state of what this tuple is supposed to model. According to OO design principles we should bundle such things into one object, Web_Page for example. Then the operation "test if true" of Boolean Loaded would become function Loaded of Web_Page. But even so the code Web_Page.Load ("http://www.irvine.com"); if Web_Page.Loaded then... looks suspicious to me. Web_Page must fulfill its contract regardless of outcome of Load. When "not loaded" is a valid state of Web_Page then there is no obvious reason why anybody would need to test for it. Say the operation Render should then be able to render a not loaded page. Like firefox does. Otherwise, if no page may be not loaded, then the constructor of Web_Page is responsible to initialize a page properly and Load, if any, should raise an exception rather than silently leaving the page in an invalid state. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-10-03 12:28 ` Dmitry A. Kazakov @ 2008-10-04 12:30 ` Marco 2008-10-04 13:05 ` (see below) 0 siblings, 1 reply; 24+ messages in thread From: Marco @ 2008-10-04 12:30 UTC (permalink / raw) On Oct 3, 5:28 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > Side-effects are bad in any subprograms, be them functions or procedures. Technically "side-effects" are being used whenever you change an internal state in a module, which is not always undesired. I think the proper expression is "unrelated side-effects are bad" which violates the Principle of Least Surprise. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-10-04 12:30 ` Marco @ 2008-10-04 13:05 ` (see below) 2008-10-04 15:14 ` Gary Scott 2008-10-11 11:32 ` Marco 0 siblings, 2 replies; 24+ messages in thread From: (see below) @ 2008-10-04 13:05 UTC (permalink / raw) On 04/10/2008 13:30, in article d49286ef-faa1-4b1b-8e23-0ed80c015dd2@p10g2000prf.googlegroups.com, "Marco" <prenom_nomus@yahoo.com> wrote: > On Oct 3, 5:28 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> Side-effects are bad in any subprograms, be them functions or procedures. > > Technically "side-effects" are being used whenever you change an > internal state in a module, which is not always undesired. These are not "side-effects", they are just effects. The whole point of using computers is to cause changes of state. > proper expression is "unrelated side-effects are bad" which violates > the Principle of Least Surprise. Quite so. -- Bill Findlay <surname><forename> chez blueyonder.co.uk ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-10-04 13:05 ` (see below) @ 2008-10-04 15:14 ` Gary Scott 2008-10-11 11:32 ` Marco 1 sibling, 0 replies; 24+ messages in thread From: Gary Scott @ 2008-10-04 15:14 UTC (permalink / raw) (see below) wrote: > On 04/10/2008 13:30, in article > d49286ef-faa1-4b1b-8e23-0ed80c015dd2@p10g2000prf.googlegroups.com, "Marco" > <prenom_nomus@yahoo.com> wrote: > > >>On Oct 3, 5:28 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> >>wrote: >> >>>Side-effects are bad in any subprograms, be them functions or procedures. >> >> Technically "side-effects" are being used whenever you change an >>internal state in a module, which is not always undesired. > > > These are not "side-effects", they are just effects. > The whole point of using computers is to cause changes of state. Some consider non-pure to include 1) changes in state of some "global" (non-local) entity (especially volatile items that can have state changed externally such as an I/O device) and 2) uses an argument return value in addition to a function return. All of those are "side-effects". The idea is that functions are only for calculating the return value based upon argument inputs. > > >>proper expression is "unrelated side-effects are bad" which violates >>the Principle of Least Surprise. > > > Quite so. -- Gary Scott mailto:garylscott@sbcglobal dot net Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html If you want to do the impossible, don't hire an expert because he knows it can't be done. -- Henry Ford ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-10-04 13:05 ` (see below) 2008-10-04 15:14 ` Gary Scott @ 2008-10-11 11:32 ` Marco 2008-10-11 14:57 ` Dmitry A. Kazakov 2008-10-11 16:05 ` (see below) 1 sibling, 2 replies; 24+ messages in thread From: Marco @ 2008-10-11 11:32 UTC (permalink / raw) On Oct 4, 6:05 am, "(see below)" <yaldni...@blueyonder.co.uk> wrote: > On 04/10/2008 13:30, in article > d49286ef-faa1-4b1b-8e23-0ed80c015...@p10g2000prf.googlegroups.com, "Marco" > > <prenom_no...@yahoo.com> wrote: > > On Oct 3, 5:28 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > > wrote: > >> Side-effects are bad in any subprograms, be them functions or procedures. > > > Technically "side-effects" are being used whenever you change an > > internal state in a module, which is not always undesired. > > These are not "side-effects", they are just effects. > The whole point of using computers is to cause changes of state. http://en.wikipedia.org/wiki/Side_effect_(computer_science) the functional programming folks would disagree with your "whole point" ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-10-11 11:32 ` Marco @ 2008-10-11 14:57 ` Dmitry A. Kazakov 2008-10-11 16:05 ` (see below) 1 sibling, 0 replies; 24+ messages in thread From: Dmitry A. Kazakov @ 2008-10-11 14:57 UTC (permalink / raw) On Sat, 11 Oct 2008 04:32:33 -0700 (PDT), Marco wrote: > On Oct 4, 6:05 am, "(see below)" <yaldni...@blueyonder.co.uk> wrote: >> The whole point of using computers is to cause changes of state. > > http://en.wikipedia.org/wiki/Side_effect_(computer_science) > > the functional programming folks would disagree with your "whole > point" Certainly they should be able to present us a computer without memory, peripheral devices, clocks... A program that changes nothing, need not to be run. You can always say that you already did. How anybody would notice any difference? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-10-11 11:32 ` Marco 2008-10-11 14:57 ` Dmitry A. Kazakov @ 2008-10-11 16:05 ` (see below) 2008-10-11 17:49 ` Georg Bauhaus 1 sibling, 1 reply; 24+ messages in thread From: (see below) @ 2008-10-11 16:05 UTC (permalink / raw) On 11/10/2008 12:32, in article d032eee0-fbaf-43f4-a18d-9cdf9aeee7d3@b38g2000prf.googlegroups.com, "Marco" <prenom_nomus@yahoo.com> wrote: > On Oct 4, 6:05 am, "(see below)" <yaldni...@blueyonder.co.uk> wrote: >> On 04/10/2008 13:30, in article >> d49286ef-faa1-4b1b-8e23-0ed80c015...@p10g2000prf.googlegroups.com, "Marco" >> >> <prenom_no...@yahoo.com> wrote: >>> On Oct 3, 5:28 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> >>> wrote: >>>> Side-effects are bad in any subprograms, be them functions or procedures. >> >>> Technically "side-effects" are being used whenever you change an >>> internal state in a module, which is not always undesired. >> >> These are not "side-effects", they are just effects. >> The whole point of using computers is to cause changes of state. > > http://en.wikipedia.org/wiki/Side_effect_(computer_science) > > the functional programming folks would disagree with your "whole point" I had a very distinguished group of them as colleagues for nearly 15 years, so I am only too aware of their profound misunderstanding of what computers are actually for. -- Bill Findlay <surname><forename> chez blueyonder.co.uk ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-10-11 16:05 ` (see below) @ 2008-10-11 17:49 ` Georg Bauhaus 2008-10-11 18:42 ` (see below) 0 siblings, 1 reply; 24+ messages in thread From: Georg Bauhaus @ 2008-10-11 17:49 UTC (permalink / raw) (see below) wrote: > On 11/10/2008 12:32, in article > d032eee0-fbaf-43f4-a18d-9cdf9aeee7d3@b38g2000prf.googlegroups.com, "Marco" > <prenom_nomus@yahoo.com> wrote: > >> On Oct 4, 6:05 am, "(see below)" <yaldni...@blueyonder.co.uk> wrote: >>> On 04/10/2008 13:30, in article >>> d49286ef-faa1-4b1b-8e23-0ed80c015...@p10g2000prf.googlegroups.com, "Marco" >>> >>> <prenom_no...@yahoo.com> wrote: >>>> On Oct 3, 5:28 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> >>>> wrote: >>>>> Side-effects are bad in any subprograms, be them functions or procedures. >>>> Technically "side-effects" are being used whenever you change an >>>> internal state in a module, which is not always undesired. >>> These are not "side-effects", they are just effects. >>> The whole point of using computers is to cause changes of state. >> http://en.wikipedia.org/wiki/Side_effect_(computer_science) >> >> the functional programming folks would disagree with your "whole point" (I'm probably dense, how is this an inevitable conclusion to be drawn from the article?) > I had a very distinguished group of them as colleagues for nearly 15 years, > so I am only too aware of their profound misunderstanding of what computers > are actually for. Maybe Simon Peyton Jones has finally found a way to make real computers visible to scientists with a preference for world-excluding static functions. In "Tackling the Awkward Squad" (2005) he introduces Haskell as "the world's finest imperative programming language" using monads), drawing attention to I/O ("I/O is the raison d'�tre of every program. ---a program that had no observable effect whatsoever (no input, no output) would not be very useful."), error detection and recovery, concurrency, and interfacing to components of the OS or written in other languages. Maybe computer operations need declarative paint and a mathematical superstructure more abstract than that of IF and GOTO in order to be on a CS teacher's radar? ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-10-11 17:49 ` Georg Bauhaus @ 2008-10-11 18:42 ` (see below) 0 siblings, 0 replies; 24+ messages in thread From: (see below) @ 2008-10-11 18:42 UTC (permalink / raw) On 11/10/2008 18:49, in article 48f0e72d$0$6599$9b4e6d93@newsspool3.arcor-online.net, "Georg Bauhaus" <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de> wrote: > (see below) wrote: ... >> I had a very distinguished group of them as colleagues for nearly 15 years, >> so I am only too aware of their profound misunderstanding of what computers >> are actually for. > > Maybe Simon Peyton Jones has finally found a way to > make real computers visible to scientists with a preference > for world-excluding static functions. In > "Tackling the Awkward Squad" (2005) he introduces Haskell > as "the world's finest imperative programming language" > using monads), drawing attention to I/O ("I/O is the raison d'�tre > of every program. ---a program that had no observable effect > whatsoever (no input, no output) would not be very useful."), > error detection and recovery, concurrency, and interfacing to > components of the OS or written in other languages. > > Maybe computer operations need declarative paint and a > mathematical superstructure more abstract than that of > IF and GOTO in order to be on a CS teacher's radar? He always was good at spin. 8-) -- Bill Findlay <surname><forename> chez blueyonder.co.uk ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-10-03 11:51 ` Brian Drummond 2008-10-03 12:28 ` Dmitry A. Kazakov @ 2008-10-03 13:15 ` Jeffrey Creem 1 sibling, 0 replies; 24+ messages in thread From: Jeffrey Creem @ 2008-10-03 13:15 UTC (permalink / raw) Brian Drummond wrote: > On Mon, 29 Sep 2008 22:48:20 +0200, Georg Bauhaus > <see.reply.to@maps.futureapps.de> wrote: > >> Dmitry A. Kazakov wrote: >>> On Mon, 29 Sep 2008 11:55:49 -0700 (PDT), Adam Beneschan wrote: >>>> if Web_Page_Is_Loaded ("http://www.irvine.com") then... >>>> if Load_Web_Page ("http://www.irvine.com") then... >>> I don't like either. >> Me neither. >> >> Some issues become more obvious in a concurrent setting >> perhaps, >> >> Web_Page.Load ("http://www.irvine.com"); >> >> if Web_Page.Is_Loaded then... >> >> There needs to be a lock of some sort joining the two calls. >> Otherwise, the Web_Page object might have changed >> between the two calls, a logic error. > > As someone relatively new to Ada, I have to ask, is there need for > anything more sophisticated than > > Web_Page.Load ("http://www.irvine.com", Loaded); > if Loaded then... > > which avoids side effects in functions, preserves the atomicity of the > operation and test, but allows the test result to be used later. > (The web page may indeed change, but "Loaded" refers to the version > extant during the .Load call) > > Its intent and operation are quite clear, and it's a common paradigm in > other languages. > > Beyond being a little untidy, is there any reason for avoiding it? > > - Brian > Perfectly valid paradigm in an Ada program as well. The risk of a style like this is the traditional sloppy programming risk where one may just ignore Loaded and continue processing down the happy path. In some cases, this may mean that using an exception would have been a better choice. In other cases, this sort of a Loaded status would be fine. In most cases, getting too worked up about the micro-style issues between the exception and the status is a small issue compared to the architectural mess that people in general make of their code. Static analyzers and in many cases some compilers are pretty good about warning on cases where Loaded was written to but not read which can help manage the risk of sloppy programming. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-09-29 18:17 Naming convention to identify functions with side effects Hibou57 (Yannick Duchêne) 2008-09-29 18:45 ` Hibou57 (Yannick Duchêne) 2008-09-29 18:55 ` Adam Beneschan @ 2008-09-29 20:57 ` Georg Bauhaus 2008-09-29 22:22 ` Dr. Adrian Wrigley 3 siblings, 0 replies; 24+ messages in thread From: Georg Bauhaus @ 2008-09-29 20:57 UTC (permalink / raw) Hibou57 (Yannick Duch�ne) wrote: > Hello every body out there, > > Do some one know a commonly used or at least a good, naming convention > to identify functions with side effects ? > I think that you will find some naming thechniques explained in Grady Booch's books. I remember outlines of typical name finding procedures. They analyze functional descriptions and isolate objects, their typical interactions, etc.. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Naming convention to identify functions with side effects 2008-09-29 18:17 Naming convention to identify functions with side effects Hibou57 (Yannick Duchêne) ` (2 preceding siblings ...) 2008-09-29 20:57 ` Georg Bauhaus @ 2008-09-29 22:22 ` Dr. Adrian Wrigley 3 siblings, 0 replies; 24+ messages in thread From: Dr. Adrian Wrigley @ 2008-09-29 22:22 UTC (permalink / raw) On Mon, 29 Sep 2008 11:17:42 -0700, Hibou57 wrote: > Hello every body out there, > > Do some one know a commonly used or at least a good, naming convention > to identify functions with side effects ? All functions have side effects - unless you prefix them with "Pure_". So you would have: function Pure_Polynomial (...) return Float; Programmers generally expect functions not to be pure. So mark the ones which are pure to alert the user. If you can be bothered. I've never seen it used though! -- Adrian ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2008-10-11 18:42 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-09-29 18:17 Naming convention to identify functions with side effects Hibou57 (Yannick Duchêne) 2008-09-29 18:45 ` Hibou57 (Yannick Duchêne) 2008-09-29 18:55 ` Adam Beneschan 2008-09-29 19:52 ` Dmitry A. Kazakov 2008-09-29 20:48 ` Georg Bauhaus 2008-09-29 21:10 ` Adam Beneschan 2008-09-30 15:17 ` Georg Bauhaus 2008-09-30 17:40 ` Ray Blaak 2008-10-02 12:33 ` Ole-Hjalmar Kristensen 2008-10-03 9:18 ` Georg Bauhaus 2008-10-06 7:24 ` Ole-Hjalmar Kristensen 2008-10-03 11:51 ` Brian Drummond 2008-10-03 12:28 ` Dmitry A. Kazakov 2008-10-04 12:30 ` Marco 2008-10-04 13:05 ` (see below) 2008-10-04 15:14 ` Gary Scott 2008-10-11 11:32 ` Marco 2008-10-11 14:57 ` Dmitry A. Kazakov 2008-10-11 16:05 ` (see below) 2008-10-11 17:49 ` Georg Bauhaus 2008-10-11 18:42 ` (see below) 2008-10-03 13:15 ` Jeffrey Creem 2008-09-29 20:57 ` Georg Bauhaus 2008-09-29 22:22 ` Dr. Adrian Wrigley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox