Naming convention to identify functions with side effects

Naming convention to identify functions with side effects

[Hibou57 (Yannick Duchêne)]

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 ?

Re: Naming convention to identify functions with side effects

[Hibou57 (Yannick Duchêne)]

Probably to name it as a verb ....

Re: Naming convention to identify functions with side effects

[Adam Beneschan]

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

Re: Naming convention to identify functions with side effects

[Dmitry A. Kazakov]

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

Re: Naming convention to identify functions with side effects

[Georg Bauhaus]

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".

Re: Naming convention to identify functions with side effects

[Georg Bauhaus]

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..

Re: Naming convention to identify functions with side effects

[Adam Beneschan]

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

Re: Naming convention to identify functions with side effects

[Dr. Adrian Wrigley]

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

Re: Naming convention to identify functions with side effects

[Georg Bauhaus]

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.

Re: Naming convention to identify functions with side effects

[Ray Blaak]

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.

Re: Naming convention to identify functions with side effects

[Ole-Hjalmar Kristensen]

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.

Re: Naming convention to identify functions with side effects

[Georg Bauhaus]

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.

Re: Naming convention to identify functions with side effects

[Brian Drummond]

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

Re: Naming convention to identify functions with side effects

[Dmitry A. Kazakov]

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

Re: Naming convention to identify functions with side effects

[Jeffrey Creem]

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.

Re: Naming convention to identify functions with side effects

[Marco]

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.

Re: Naming convention to identify functions with side effects

[(see below)]

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

Re: Naming convention to identify functions with side effects

[Gary Scott]

(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

Re: Naming convention to identify functions with side effects

[Ole-Hjalmar Kristensen]

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.

Re: Naming convention to identify functions with side effects

[Marco]

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"

Re: Naming convention to identify functions with side effects

[Dmitry A. Kazakov]

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

Re: Naming convention to identify functions with side effects

[(see below)]

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

Re: Naming convention to identify functions with side effects

[Georg Bauhaus]

(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?

Re: Naming convention to identify functions with side effects

[(see below)]

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