which language allows you to change an argument's value?

Discussion in 'Ruby' started by Summercool, Sep 30, 2007.

  1. Summercool

    Summercool Guest

    I wonder which language allows you to change an argument's value?
    like:

    foo(&a) {
    a = 3
    }

    n = 1
    print n

    foo(n) # passing in n, not &n
    print n

    and now n will be 3. I think C++ and PHP can let you do that, using
    their reference (alias) mechanism. And C, Python, and Ruby probably
    won't let you do that. What about Java and Perl?

    is there any way to prevent a function from changing the argument's
    value?

    isn't "what i pass in, the function can modify it" not a desireable
    behavior if i am NOT passing in the address of my argument? For one
    thing, if we use a module, and call some functions in that module, and
    the module's author made some changes to his code, then we have no way
    of knowing what we pass in could get changed. Of course, if it is in
    Java, Python, and Ruby, and we pass in a reference to object (not C+
    +'s meaning of alias reference), so the object can get changed, but
    that can be expected, vs passing in n, when n = 1. Even when it is
    Ruby, when everything is an object, passing n in when n = 1 won't ever
    make n become 3. Is there a way to prevent it from happening in the
    languages that allows it?
    Summercool, Sep 30, 2007
    #1
    1. Advertising

  2. Summercool

    rolkA Guest

    On 30 sep, 12:47, Summercool <> wrote:
    > I wonder which language allows you to change an argument's value?
    > like:
    >
    > foo(&a) {
    > a = 3
    >
    > }
    >
    > ...
    > is there any way to prevent a function from changing the argument's
    > value?
    > ...
    > Is there a way to prevent it from happening in the
    > languages that allows it?


    Hi,
    Of course in C++, functions that don't modify argument's value should
    (i'd rather say MUST) wait for a CONST reference or a value :

    // const ref
    foo(const T& a) {
    a = 3; // error

    }
    // value
    foo(T a) {
    a = 3; // ok, but modify only the formal parameter : the argument
    (aka actual parameter) is not changed

    }

    Now if you want to prevent a function (from a library you are using)
    to modify it... Erm well, you shouldn't : a good librairy will never
    wait for a non-const argument if it doesn't need to be modified. So in
    this case "Is there a way to prevent it from happening" is
    unpertinent : you could copy the object, but if the purpose of the
    fucntion was to modify it, it's pointless.
    rolkA, Sep 30, 2007
    #2
    1. Advertising

  3. Summercool

    7stud -- Guest

    SpringFlowers AutumnMoon wrote:
    > we have no way
    > of knowing what we pass in could get changed.


    Sure you do. You look at the function's signature. In order to use
    someone else's library, you have to know the function's signature. And
    the signature explicitly tells you whether the value you pass in could
    be changed.



    --
    Posted via http://www.ruby-forum.com/.
    7stud --, Sep 30, 2007
    #3
  4. Summercool

    Xavier Noria Guest

    On Sep 30, 2007, at 12:50 PM, Summercool wrote:

    > and now n will be 3. I think C++ and PHP can let you do that, using
    > their reference (alias) mechanism. And C, Python, and Ruby probably
    > won't let you do that. What about Java and Perl?


    Java can't do that, Perl _only_ works that way.

    > isn't "what i pass in, the function can modify it" not a desireable
    > behavior if i am NOT passing in the address of my argument? For one
    > thing, if we use a module, and call some functions in that module, and
    > the module's author made some changes to his code, then we have no way
    > of knowing what we pass in could get changed. Of course, if it is in
    > Java, Python, and Ruby, and we pass in a reference to object (not C+
    > +'s meaning of alias reference), so the object can get changed, but
    > that can be expected, vs passing in n, when n = 1. Even when it is
    > Ruby, when everything is an object, passing n in when n = 1 won't ever
    > make n become 3. Is there a way to prevent it from happening in the
    > languages that allows it?


    In general it is bad practice to change the state of the arguments
    you receive, as bad practice as changing the arguments themselves. A
    function shouldn't do that unless it documents it, unless it makes
    sense and it is expected by the caller.

    For example, that's what allows you to write subroutines like chomp
    in Perl:

    chomp $str;

    You expect $str to be chomped and since this is procedural style you
    can implement that with pass-by-reference, and that's fine.

    Otherwise you'd need to pass a reference to $str to be able to change
    the string through the reference (what you do in C for integers)
    which is cumbersome, and in fact would be a workaround for pass-by-
    value.

    In Perl there's no way to prevent a subroutine from changing the
    values in the caller except passing readonly stuff like literals.
    But, you know, people just don't do that. The same way people don't
    start changing argument's state gratuitously in Ruby. Both are
    analogous bad practices.

    -- fxn
    Xavier Noria, Sep 30, 2007
    #4
  5. On 2007-09-30 12:47, Summercool wrote:
    > I wonder which language allows you to change an argument's value?
    > like:
    >
    > foo(&a) {
    > a = 3
    > }
    >
    > n = 1
    > print n
    >
    > foo(n) # passing in n, not &n
    > print n
    >
    > and now n will be 3. I think C++ and PHP can let you do that, using


    Since you know C++ can do it why do you include c.l.c++? Honestly cross-
    posting to groups discussing so many different groups is seldom a good
    idea since the languages differ too much for a useful discussion.

    > their reference (alias) mechanism. And C, Python, and Ruby probably
    > won't let you do that. What about Java and Perl?


    C will let you do it with pointers (it is just a syntactical difference
    from references in this case) and Java's references allows it. I do not
    know about Ruby, Python and Perl, but (AFAIK) the all have OO support so
    I would be surprised if they used purely value semantics.

    > is there any way to prevent a function from changing the argument's
    > value?


    Some languages, like C++ have the ability to make an argument const.

    > isn't "what i pass in, the function can modify it" not a desireable
    > behavior if i am NOT passing in the address of my argument? For one


    Being able to pass the actual object instead of a copy is highly
    desirable for two reasons. In most languages only one return value is
    allowed for a function so the ability to change parameters allows you to
    artificially return more without having to wrap them in constructs. The
    second reason is that for large objects the performance hit of having to
    create a copy each time you call a function can be forbidding.

    > thing, if we use a module, and call some functions in that module, and
    > the module's author made some changes to his code, then we have no way
    > of knowing what we pass in could get changed. Of course, if it is in


    As for knowing when a library function modifies an argument or not, well
    that is why we have documentation.

    > Java, Python, and Ruby, and we pass in a reference to object (not C+
    > +'s meaning of alias reference)


    In what way does the C++ reference differ from those in Java, Python,
    and Ruby in this situation?

    --
    Erik Wikström
    Erik Wikström, Sep 30, 2007
    #5
  6. > And C, Python, and Ruby probably won't let you do that...

    From my understanding, in Ruby all argument passing is by value.
    However, the value passed may not be what you expect... The value that
    is passed is that of the reference, not the value that the reference
    refers to. So, for example:

    def foo(arg)
    arg = 3
    end

    a = 'Mike'

    foo(a)

    This will not change the value of a in the top level. Why? Because foo
    reassigns the argument reference arg to 3, a different object than
    'Mike.' However:

    def bar(arg)
    arg[0] = 'b'
    end

    a = 'Mike'

    bar(a)

    This will change a from 'Mike' to 'bike.' Why? Because instead of
    reassigning arg to a new object, the object itself ('Mike') has been
    modified through the method call []. So, if the method simply reassigns
    the reference, there will be no change in the original (it still refers
    to the same object). But, if the method modifies that object, the
    original reference will reflect that modification, since it is still
    referencing the now modified object.

    It is customary in Ruby to append an exclamation mark (!) to indicate
    methods that actually modify an object in place. So, bar! would have
    been a more appropriate name for the second method.

    Hope that helps.

    David B. Williams
    http://www.cybersprocket.com
    --
    Posted via http://www.ruby-forum.com/.
    David B. Williams, Sep 30, 2007
    #6
  7. Summercool

    Summercool Guest

    On Sep 30, 4:18 am, 7stud -- <> wrote:
    > SpringFlowers AutumnMoon wrote:
    > > we have no way
    > > of knowing what we pass in could get changed.

    >
    > Sure you do. You look at the function's signature. In order to use
    > someone else's library, you have to know the function's signature. And
    > the signature explicitly tells you whether the value you pass in could
    > be changed.


    do you mean in C++? I tried to find signature in two C++ books and it
    is not there. Google has a few results but it looks something like
    prototype. Is signature the same as the function prototype in the .h
    file? If so, don't we usually just include <___.h> and forget about
    the rest. Documentation is fine although in some situation, the
    descriptions is 2 lines, and notes and warnings are 4, 5 times that,
    and the users' discussing it, holding different opinion is again 2, 3
    times of that length. I think in Pascal and C, we can never have an
    argument modified unless we explicitly allow it, by passing in the
    pointer (address) of the argument.

    also i think for string, it is a bit different because by default,
    string is a pointer to char or the address of the first char in C and C
    ++. So it is like passing in the address already. it is when the
    argument n is something like 1 that makes me wonder.
    Summercool, Sep 30, 2007
    #7
  8. Summercool

    Daniel Pitts Guest

    On Sep 30, 3:47 am, Summercool <> wrote:
    > I wonder which language allows you to change an argument's value?
    > like:
    >
    > foo(&a) {
    > a = 3
    >
    > }
    >
    > n = 1
    > print n
    >
    > foo(n) # passing in n, not &n
    > print n
    >
    > and now n will be 3. I think C++ and PHP can let you do that, using
    > their reference (alias) mechanism. And C, Python, and Ruby probably
    > won't let you do that. What about Java and Perl?
    >
    > is there any way to prevent a function from changing the argument's
    > value?
    >
    > isn't "what i pass in, the function can modify it" not a desireable
    > behavior if i am NOT passing in the address of my argument? For one
    > thing, if we use a module, and call some functions in that module, and
    > the module's author made some changes to his code, then we have no way
    > of knowing what we pass in could get changed. Of course, if it is in
    > Java, Python, and Ruby, and we pass in a reference to object (not C+
    > +'s meaning of alias reference), so the object can get changed, but
    > that can be expected, vs passing in n, when n = 1. Even when it is
    > Ruby, when everything is an object, passing n in when n = 1 won't ever
    > make n become 3. Is there a way to prevent it from happening in the
    > languages that allows it?


    Some would say that in truely good OO design, the state should be
    protected by the object (not the constness of the reference to the
    object)
    Daniel Pitts, Sep 30, 2007
    #8
  9. On 2007-09-30 18:49, Summercool wrote:
    > On Sep 30, 4:18 am, 7stud -- <> wrote:
    >> SpringFlowers AutumnMoon wrote:
    >> > we have no way
    >> > of knowing what we pass in could get changed.

    >>
    >> Sure you do. You look at the function's signature. In order to use
    >> someone else's library, you have to know the function's signature. And
    >> the signature explicitly tells you whether the value you pass in could
    >> be changed.

    >
    > do you mean in C++? I tried to find signature in two C++ books and it
    > is not there. Google has a few results but it looks something like
    > prototype. Is signature the same as the function prototype in the .h
    > file?


    A signature is what is required to identify a function and includes
    return type, name of function and the types of the parameters, while it
    looks just like a prototype it is not. A prototype is something you
    write to satisfy your compiler while a signature identifies a function.
    Below are some examples of signatures, only the last can modify the
    values of its parameter.

    void foo(int, float)
    std::string bar(const std::string&, int, int)
    void baz(std::string&)

    > If so, don't we usually just include <___.h> and forget about
    > the rest. Documentation is fine although in some situation, the
    > descriptions is 2 lines, and notes and warnings are 4, 5 times that,
    > and the users' discussing it, holding different opinion is again 2, 3
    > times of that length.


    Unless you read the documentation how do you know which files to
    include? And what documentation are you reading which does not clearly
    specify the functionality of the functions described?

    > I think in Pascal and C, we can never have an
    > argument modified unless we explicitly allow it, by passing in the
    > pointer (address) of the argument.


    In C++ the arguments cannot be modified unless you either pass a pointer
    to a non-const object or a non-const reference, so it is just as
    explicit. (Notice that it is possible to cast the constness away, but
    doing is extremely dangerous and should not be done.)

    > also i think for string, it is a bit different because by default,
    > string is a pointer to char or the address of the first char in C and C
    > ++. So it is like passing in the address already.


    No. A string in C++ is a string, a char array or a pointer to a char is
    something different.

    > it is when the
    > argument n is something like 1 that makes me wonder.



    Get a good book on whatever language you are interested in (I do not
    know which it is since you are all over the place) and read up on that
    languages references, if you still do not understand after that ask your
    questions in the group discussing that language.

    --
    Erik Wikström
    Erik Wikström, Sep 30, 2007
    #9
  10. ..oO(Summercool)

    >I think in Pascal and C, we can never have an
    >argument modified unless we explicitly allow it, by passing in the
    >pointer (address) of the argument.


    Pascal also allows passing by reference, which is done with the keyword
    'var' when declaring the function parameters. Object Pascal also allows
    const parameters.

    Micha
    Michael Fesser, Sep 30, 2007
    #10
  11. Summercool

    Bryan Olson Guest

    Summercool wrote:
    > I wonder which language allows you to change an argument's value?
    > like:
    >
    > foo(&a) {
    > a = 3
    > }
    >
    > n = 1
    > print n
    >
    > foo(n) # passing in n, not &n
    > print n
    >
    > and now n will be 3. I think C++ and PHP can let you do that, using
    > their reference (alias) mechanism. And C, Python, and Ruby probably
    > won't let you do that. What about Java and Perl?


    I think you've missed how Python works, and probably others.
    A Python function receives a reference to the argument, and
    can modify the object if the object is mutable.

    Nevertheless, assigning to the parameter's name will not
    change the passed object. This function does nothing:

    def clear_list_wrong(lst):
    lst = [] # useless re-binding of local name

    This version empties the passed list:

    def clear_list(lst):
    del lst[:]


    > is there any way to prevent a function from changing the argument's
    > value?


    Sure. First choice: Don't change the value in the function.
    Alternatives include making a copy to use as the argument.

    > isn't "what i pass in, the function can modify it" not a desireable
    > behavior if i am NOT passing in the address of my argument? For one
    > thing, if we use a module, and call some functions in that module, and
    > the module's author made some changes to his code, then we have no way
    > of knowing what we pass in could get changed.


    Don't rely on undocumented behavior. Modules worth using are by
    good programmers. Authors of library modules tend to be zealous
    about not breaking client code.


    --
    --Bryan
    Bryan Olson, Sep 30, 2007
    #11
  12. Erik Wikström wrote:
    >> their reference (alias) mechanism. And C, Python, and Ruby probably
    >> won't let you do that. What about Java and Perl?

    >
    > C will let you do it with pointers (it is just a syntactical difference
    > from references in this case) and Java's references allows it.


    Neither C or Java has call by reference.

    C pointers and Java references may work similarly in most cases
    but it is still call by value.

    > I do not
    > know about Ruby, Python and Perl, but (AFAIK) the all have OO support so
    > I would be surprised if they used purely value semantics.


    I can not see why OO should indicate anything about call by reference
    support.

    >> isn't "what i pass in, the function can modify it" not a desireable
    >> behavior if i am NOT passing in the address of my argument? For one

    >
    > Being able to pass the actual object instead of a copy is highly
    > desirable for two reasons. In most languages only one return value is
    > allowed for a function so the ability to change parameters allows you to
    > artificially return more without having to wrap them in constructs. The
    > second reason is that for large objects the performance hit of having to
    > create a copy each time you call a function can be forbidding.


    Usually it is not a good thing, because it makes the code much
    more difficult to read.

    But sometimes it is handy.

    I think C# got it right.

    It allows it but require an explicit marking of it in both formal
    argument list and actual argument list.

    >> Java, Python, and Ruby, and we pass in a reference to object (not C+
    >> +'s meaning of alias reference)

    >
    > In what way does the C++ reference differ from those in Java, Python,
    > and Ruby in this situation?


    C++ and Java are very different in this aspect.

    Arne
    Arne Vajhøj, Sep 30, 2007
    #12
  13. Summercool

    Roedy Green Guest

    On Sun, 30 Sep 2007 10:47:13 -0000, Summercool
    <> wrote, quoted or indirectly quoted someone
    who said :

    >and now n will be 3. I think C++ and PHP can let you do that, using
    >their reference (alias) mechanism. And C, Python, and Ruby probably
    >won't let you do that. What about Java and Perl?


    Seem to me you could in FORTRAN and Pascal, and maybe even Algol. It
    has been a while.

    I have come to appreciate Java's strong isolation convention. It makes
    it a lot easier to track down WHERE in the code a value could
    potentially change and keeps those places to a minimum.

    --
    Roedy Green Canadian Mind Products
    The Java Glossary
    http://mindprod.com
    Roedy Green, Oct 1, 2007
    #13
  14. On Mon, 01 Oct 2007 01:53:47 GMT, Roedy Green
    <> declaimed the following in
    comp.lang.python:


    > Seem to me you could in FORTRAN and Pascal, and maybe even Algol. It
    > has been a while.
    >

    Everything in classic FORTRAN is a passed as a reference -- even
    constant arguments are passed as a reference to the memory location
    containing that constant (which is why it was possible in very early
    FORTRANs to have "a = 1 + 1" yield something other than "2" if preceded
    by, say, "call mutate(1)" where mutate looks like:

    subroutine mutate(arg)
    arg = arg * 2
    end

    )
    --
    Wulfraed Dennis Lee Bieber KD6MOG

    HTTP://wlfraed.home.netcom.com/
    (Bestiaria Support Staff: )
    HTTP://www.bestiaria.com/
    Dennis Lee Bieber, Oct 1, 2007
    #14
  15. > Neither C or Java has call by reference.
    > C pointers and Java references may work similarly in most cases
    > but it is still call by value.

    so what? the references in c++ are passed by value too, its just a nice
    interface to pointers.
    At the end those parameters are pushed on the stack .. thats it.
    Sascha Bohnenkamp, Oct 1, 2007
    #15
  16. On 2007-09-30 23:03, Arne Vajhøj wrote:
    > Erik Wikström wrote:
    >>> their reference (alias) mechanism. And C, Python, and Ruby probably
    >>> won't let you do that. What about Java and Perl?

    >>
    >> C will let you do it with pointers (it is just a syntactical difference
    >> from references in this case) and Java's references allows it.

    >
    > Neither C or Java has call by reference.


    I never said that, what I said was that C allows you to simulate it by
    passing pointers instead, and since you always use references in Java
    (except for primitive types) you always pass a reference.

    > C pointers and Java references may work similarly in most cases
    > but it is still call by value.


    The difference I am trying to show is that between value semantics
    (where a copy of the parameter is used in the function) verses reference
    semantics where you pass a reference to the object. It is true that when
    using a pointer in C you pass a copy of the pointer, but not of the
    object it refers to. Similarly you might pass a copy of the variable
    holding a reference in Java, but not a copy of the object it refers to.
    Thus, in the function you will be working on the referred object, just
    like when passing by reference in C++.

    >> know about Ruby, Python and Perl, but (AFAIK) the all have OO support so
    >> I would be surprised if they used purely value semantics.

    >
    > I can not see why OO should indicate anything about call by reference
    > support.


    There is no direct connection, except that all OO programming languages
    that I know of supports reference semantics. You seldom want to work on
    copies of objects, rather you want to work on the original object and
    for that you need to be able to refer to it, for that you need some kind
    of reference.

    >>> isn't "what i pass in, the function can modify it" not a desireable
    >>> behavior if i am NOT passing in the address of my argument? For one

    >>
    >> Being able to pass the actual object instead of a copy is highly
    >> desirable for two reasons. In most languages only one return value is
    >> allowed for a function so the ability to change parameters allows you to
    >> artificially return more without having to wrap them in constructs. The
    >> second reason is that for large objects the performance hit of having to
    >> create a copy each time you call a function can be forbidding.

    >
    > Usually it is not a good thing, because it makes the code much
    > more difficult to read.
    >
    > But sometimes it is handy.
    >
    > I think C# got it right.
    >
    > It allows it but require an explicit marking of it in both formal
    > argument list and actual argument list.


    I think you are confusing two different things here, one is the ability
    to pass a reference to an object, instead of a copy of the object. This
    is what C++ references allows you to do, just like Java references, C
    pointers, and any other kind of references that I know about.

    The other thing is to allow the function to change what a reference
    refers to, to this not possible with C++ references, C pointers, Java
    references, or most other reference types that I know about. You can do
    this by using a reference to a pointer in C++, a pointer to a pointer in
    C, or using the ref and out keywords in C#. Doing that can be confusing,
    but often the semantics for doing so are pretty obvious.

    >>> Java, Python, and Ruby, and we pass in a reference to object (not C+
    >>> +'s meaning of alias reference)

    >>
    >> In what way does the C++ reference differ from those in Java, Python,
    >> and Ruby in this situation?

    >
    > C++ and Java are very different in this aspect.


    Might be, my question was about what aspect we are talking about.

    --
    Erik Wikström
    Erik Wikström, Oct 1, 2007
    #16
  17. Summercool

    James Kanze Guest

    On Sep 30, 6:49 pm, Summercool <> wrote:
    > On Sep 30, 4:18 am, 7stud -- <> wrote:


    > > SpringFlowers AutumnMoon wrote:
    > > > we have no way
    > > > of knowing what we pass in could get changed.


    > > Sure you do. You look at the function's signature. In order to use
    > > someone else's library, you have to know the function's signature. And
    > > the signature explicitly tells you whether the value you pass in could
    > > be changed.


    That's not really correct. It's more a case that if you don't
    know what a function does, you don't use it. Regardless of the
    language, calling a function without knowing what it does is a
    sure recepe for disaster.

    > do you mean in C++? I tried to find signature in two C++ books and it
    > is not there. Google has a few results but it looks something like
    > prototype. Is signature the same as the function prototype in the .h
    > file? If so, don't we usually just include <___.h> and forget about
    > the rest. Documentation is fine although in some situation, the
    > descriptions is 2 lines, and notes and warnings are 4, 5 times that,
    > and the users' discussing it, holding different opinion is again 2, 3
    > times of that length. I think in Pascal and C, we can never have an
    > argument modified unless we explicitly allow it, by passing in the
    > pointer (address) of the argument.


    In C, that's partially true; no part of the expressions involved
    in the function invocation will be modified through the function
    argument unless the address is specifically taken (or the
    argument has array type). The situation in Pascal, C++, Ada and
    most other languages is different; Pascal and C++ have reference
    parameters (called VAR in Pascal), as well as value paramters,
    Ada has in, inout and out parameters.

    The situation in Java is somewhat more complicated; formally,
    Java only has pass by value, and there's no way a function can
    modify any of the arguments. In practice, however, if the
    expression has an object type, the "value" is a pointer (called
    reference in Java) to the object; if the object is a well
    defined "value" type (e.g. java.lang.String), it will be
    immutable, but entity objects don't follow this rule, and not
    all value objects (e.g. java.awt.Dimension) are well designed.

    > also i think for string, it is a bit different because by default,
    > string is a pointer to char or the address of the first char in C and C
    > ++.


    Strings in C++ are class types, with full value semantics.

    > So it is like passing in the address already. it is when the
    > argument n is something like 1 that makes me wonder.


    C++ requires an lvalue unless the reference is to a const, so
    you cannot pass 1 to a C++ function and expect/worry about it
    being changed. The same holds for most modern languages, I
    think, although the mechanisms involved may differ. (I'd be
    very surprised, for example, if Ada allowed anything but what in
    C++ would be an lvalue to be passed to an inout or an out
    parameter.) In most modern languages, however, you can
    circumvent the controls with enough indirections.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Oct 1, 2007
    #17
  18. On 10/1/07, Dennis Lee Bieber <> wrote:
    > On Mon, 01 Oct 2007 01:53:47 GMT, Roedy Green
    > <> declaimed the following in
    > comp.lang.python:
    >
    >
    > > Seem to me you could in FORTRAN and Pascal, and maybe even Algol. It
    > > has been a while.
    > >

    > Everything in classic FORTRAN is a passed as a reference -- even
    > constant arguments are passed as a reference to the memory location
    > containing that constant (which is why it was possible in very early
    > FORTRANs to have "a = 1 + 1" yield something other than "2" if preceded
    > by, say, "call mutate(1)" where mutate looks like:
    >
    > subroutine mutate(arg)
    > arg = arg * 2
    > end


    Fortran II was like this. It cost me a day or two of head-scratching
    once about 35 years ago.


    --
    Rick DeNatale

    My blog on Ruby
    http://talklikeaduck.denhaven2.com/
    Rick DeNatale, Oct 2, 2007
    #18
  19. Dennis Lee Bieber wrote:
    > On Mon, 01 Oct 2007 01:53:47 GMT, Roedy Green
    > <> declaimed the following in
    > comp.lang.python:
    >
    >
    >> Seem to me you could in FORTRAN and Pascal, and maybe even Algol. It
    >> has been a while.
    >>

    > Everything in classic FORTRAN is a passed as a reference -- even
    > constant arguments are passed as a reference to the memory location
    > containing that constant (which is why it was possible in very early
    > FORTRANs to have "a = 1 + 1" yield something other than "2" if preceded
    > by, say, "call mutate(1)" where mutate looks like:
    >
    > subroutine mutate(arg)
    > arg = arg * 2
    > end
    >
    > )


    However, some implementations passed /and returned/ elementary arguments
    by value, as Ada does. (The object code was typically faster that way,
    and FORTRAN semantics were such that the difference was almost
    impossible to observe.)
    --
    John W. Kennedy
    "The pathetic hope that the White House will turn a Caligula into a
    Marcus Aurelius is as naïve as the fear that ultimate power inevitably
    corrupts."
    -- James D. Barber (1930-2004)
    John W. Kennedy, Oct 3, 2007
    #19
  20. Summercool

    Guest

    In article <1PUMi.21$>,
    John W. Kennedy <> wrote:
    > Dennis Lee Bieber wrote:
    > > On Mon, 01 Oct 2007 01:53:47 GMT, Roedy Green
    > > <> declaimed the following in
    > > comp.lang.python:
    > >
    > >
    > >> Seem to me you could in FORTRAN and Pascal, and maybe even Algol. It
    > >> has been a while.
    > >>

    > > Everything in classic FORTRAN is a passed as a reference -- even
    > > constant arguments are passed as a reference to the memory location
    > > containing that constant (which is why it was possible in very early
    > > FORTRANs to have "a = 1 + 1" yield something other than "2" if preceded
    > > by, say, "call mutate(1)" where mutate looks like:
    > >
    > > subroutine mutate(arg)
    > > arg = arg * 2
    > > end
    > >
    > > )

    >
    > However, some implementations passed /and returned/ elementary arguments
    > by value, as Ada does.


    In FORTRAN/Fortran, don't they call that "copy-in/copy-out"? Same
    thing, just nitpicking a little about terminology, I hope correctly.

    > (The object code was typically faster that way,
    > and FORTRAN semantics were such that the difference was almost
    > impossible to observe.)


    --
    B. L. Massingill
    ObDisclaimer: I don't speak for my employers; they return the favor.
    , Oct 5, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Summercool
    Replies:
    29
    Views:
    734
    James Kanze
    Oct 10, 2007
  2. Summercool
    Replies:
    29
    Views:
    704
    James Kanze
    Oct 10, 2007
  3. Summercool
    Replies:
    17
    Views:
    420
    John W. Kennedy
    Oct 6, 2007
  4. Suganya
    Replies:
    0
    Views:
    434
    Suganya
    Apr 29, 2008
  5. Robert
    Replies:
    7
    Views:
    327
    Nobody
    Feb 2, 2010
Loading...

Share This Page