On 10/1/07, Dennis Lee B. [email protected] wrote:
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/
Dennis Lee B. wrote:
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.)
In article [email protected],
John W. Kennedy [email protected] wrote:
constant arguments are passed as a reference to the memory location
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.
In article [email protected],
John W. Kennedy [email protected] wrote:
versions of the language.
Huh. I’d have said I was remembering the terminology from back
when I was actively using the language, when it was still FORTRAN
and my then-current place of employment still regarded the F77
standard as a bit too new-fangled to be relied on. But I’m sure
your memory’s at least as good as mine, and I can’t quite figure
out how to research which term might have been used when …
[email protected] wrote:
In article [email protected],
John W. Kennedy [email protected] wrote: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.
Back in the day, IBM called it “by copy”. I’m not acquainted with modern
versions of the language.
On Oct 4, 12:35 am, “John W. Kennedy” [email protected] wrote:
Dennis Lee B. wrote:
On Mon, 01 Oct 2007 01:53:47 GMT, Roedy Green
[email protected] 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.)
The Fortran standard is carefully worded to allow either pass by
reference, or copy-in, copy-out. IIRC, IBM’s Fortran-H used
copy-in/copy-out, but most others used call by reference.
Straight copy was never allowed by the standard, and I’ve never
heard of a pre-standard implementation which used it either.
–
James K. (GABI Software) email:[email protected]
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
Roedy Green wrote:
On Sun, 30 Sep 2007 10:47:13 -0000, Summercool
[email protected] 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.
FORTRAN generally looked like call by reference, but was often actually
implemented element variables as copy-in at call time and copy-out at
return time. In standard older FORTRAN, the effective results were the
same. I don’t know how things stand with modern Fortran, where some new
features have made the assumption that copy-in-copy-out is equivalent to
reference more dangerous. Ada is /defined/ as using copy-in-copy-out for
element variables.
ALGOL had a weird “by name” convention. The semantics were essentially
that, for each argument, a closure (historically called a “thunk”) was
constructed, and every time the parameter was referenced, the
corresponding closure was called. Theoretically elegant, but hideous to
implement, and with bizarre side-effects in certain cases.
constant arguments are passed as a reference to the memory location
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.)The Fortran standard is carefully worded to allow either pass by
reference, or copy-in, copy-out. IIRC, IBM’s Fortran-H used
copy-in/copy-out, but most others used call by reference.Straight copy was never allowed by the standard, and I’ve never
heard of a pre-standard implementation which used it either.
This is all to simple. Please discuss Algol pass-by-name. Much more
interesting, and a good candidate for inclusion in C++ – at least, if
we’re going to achieve the goal of PL/1-killer! 
Cheers,
In article [email protected], [email protected] says…
[ … ]
This is all to simple. Please discuss Algol pass-by-name. Much more
interesting, and a good candidate for inclusion in C++ – at least, if
we’re going to achieve the goal of PL/1-killer!
The Algol 60 standard is deceptively simple looking. The entire “Revised
Report on the Algorithmic Language” is only 17 pages – about half as
long as the index of the 2003 version of the C++ standard! Of that,
about a page and a half is devoted to a history of the committee
meetings and such.
Anyway, Algol supported both call by value and call by name. Since it’s
raeasonably short I’ll quote the entire section:
// Start of quote
4.7.3.1. Value assignment (call by value)
All formal parameters quoted in the value part of the procedure
declaration heading are assigned the values (cf. section 2.8 Values and
Types) of the corresponding actual parameters,these assignments being
considredd as being performed explicitly before entering the procedure
body. The effect is a though an aditional block embracing the procedure
body were created in which these assignments were made to variables
local to this fictitious block with types as given in their
corresponding specifications (cf. section 5.4.5). As a consequence,
variables called by value ar considered as nonlocal to the body of the
procedure, but local to the fictitious block (cf. section 5.4.3).
4.7.3.2. Name Replacement (call by name)
Any formal parameter not quoted in the value list is replaced,
throughout the procedure body, by the corresponding actual parameter,
after enclosing this latter in parentheses wherever syntactically
possible. Possible conflicts between identifiers inserted through this
process and other identifiers already present within the procedure will
be avoided by suitable systematic changes of the formal or local
identifiers involved.
// End of quote
If you’re going to compare to C++, ‘export’ virtually springs to mind –
something that initially seems fairly inoccuous, but is virtually
impossible to implement, and probably doesn’t accomplish what you want
when/if you do manage to get it “right”.
–
Later,
Jerry.
The universe is a figment of its own imagination.
Jerry C. wrote:
The universe is a figment of its own imagination.
[email protected] wrote:
I can’t recall – what was the formal name in philosophy for this
thesis?
Zen.
On Oct 7, 2:59 pm, Jerry C. [email protected] wrote:
4.7.3.2. Name Replacement (call by name)
Any formal parameter not quoted in the value list is replaced,
throughout the procedure body, by the corresponding actual parameter,
after enclosing this latter in parentheses wherever syntactically
possible. Possible conflicts between identifiers inserted through this
process and other identifiers already present within the procedure will
be avoided by suitable systematic changes of the formal or local
identifiers involved.
This sounds rather like macro expansion as found in languages ranging
from TeX to various flavors of shell and make.
The universe is a figment of its own imagination.
I can’t recall – what was the formal name in philosophy for this
thesis?
Lew wrote:
Jerry C. wrote:
The universe is a figment of its own imagination.
[email protected] wrote:
I can’t recall – what was the formal name in philosophy for this
thesis?Zen.
No, the word you’re looking for is “bullshit”
On Oct 8, 6:58 am, [email protected] wrote:
On Oct 7, 2:59 pm, Jerry C. [email protected] wrote:
4.7.3.2. Name Replacement (call by name)
Any formal parameter not quoted in the value list is replaced,
throughout the procedure body, by the corresponding actual parameter,
after enclosing this latter in parentheses wherever syntactically
possible. Possible conflicts between identifiers inserted through this
process and other identifiers already present within the procedure will
be avoided by suitable systematic changes of the formal or local
identifiers involved.
This sounds rather like macro expansion as found in languages ranging
from TeX to various flavors of shell and make.
Not really. The arguments of a macro are normally expanded
before macro substitution occurs, even in these languages. (Of
course, the results of expanding the macro are then rescanned,
for new macros.)
int global = 0 ;
void f(
int@ arg ) // Where @ means as above...
{
std::cout << arg << std::endl ;
++ global ;
std::cout << arg << std::endl ;
}
int
main()
{
f( 2 * global ) ;
}
would output 0, then 2; each time the function uses arg, it
evaluates the expression 2 * global.
Although there are tricky ways of getting this effect in ksh,
bash or GNU make, and I think in TeX as well, the usual function
call expands all arguments before calling the function.
Generally, the way to get this behavior is based on the fact
that everything is a string, and that there is really no
distinction between the program and its data. So if you pass a
string like “2*global”, and then invoke the execution of that
string, you get something like the above. This is also “doable”
in C++: write the string to a file, invoke the compiler on it to
create a dynamically loadable object (DLL, .so), then load it
and invoke it. Which is, of course, a lot heavier than what you
have to do in an interpreted language which allows executing
strings.
–
James K. (GABI Software) email:[email protected]
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
[email protected] wrote:
On Oct 8, 4:14 am, James K. [email protected] wrote:
On Oct 8, 6:58 am, [email protected] wrote:
from TeX to various flavors of shell and make.
Not really. [snip loads]
You seem to be meaning to disagree with me,
Yes and no. Algol’s name replacement is definitly different
than the usual macro replacement in shells, make and TeX,
since the argument gets expanded each time it is used, and
not once when the function is called. On the other hand,
such languages often do have the capacity to delay
expansion; they also have the capability of treating any
data string as part of the program, so you can pass an
argument as a string, and then execute it multiple times in
a function. In short, you can easily simulate Algol’s name
replacement in such languages.
Of course, if you pass a functional object in C++, you can
also get much of the same effect as well.
–
James K. (GABI Software) mailto:[email protected]
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
On Oct 8, 4:14 am, James K. [email protected] wrote:
identifiers involved.
This sounds rather like macro expansion as found in languages ranging
from TeX to various flavors of shell and make.Not really. [snip loads]
You seem to be meaning to disagree with me, but it’s unclear exactly
what you are asserting that contradicts anything that I said.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs