Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Python

The Importance of Terminology's Quality

 

 

First page Previous page 1 2 3 4 5 Next page Last page  View All Python python RSS feed   Index | Next | Previous | View Threaded


m6d04a5.3.calrobert at spamgourmet

Jun 4, 2008, 10:39 PM

Post #51 of 112 (1885 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

> From: dkco...@panix.com (David Combs)
> Lisp is *so* early a language (1960?), preceeded mainly only by
> Fortran (1957?)?, and for sure the far-and-away the first as a
> platform for *so many* concepts of computer-science, eg lexical vs
> dynamic ("special") variables, passing *unnamed* functions as
> args ... maybe is still the only one in which program and data
> have the same representation -- that it'd seem logical to use it's
> terminology in all languages.

Yeah, but why did you cross-post to so many newsgroups? Are you
trying to run a flame war between advocates of the various
languages? (Same accusation to the OP moreso!)

> From C is the very nice distinction between "formal" and "actual" args.

I think Lisp already had that nearly 50 years ago. Function
definition (lambda expression) has formal args, EVAL recursively
calls EVAL on sub-forms to create actual args and calls APPLY on
them and whatever function is named in the CAR position of the form.
Whether anybody bothered to use that specific jargon, or it was
just so obvious it didn't need jargon, I don't know.

> And from algol-60, own and local -- own sure beats "static"!

Yeah. But now that you mention it and I think about it, what's
really meant is "private persistent". Global variables are public
persistent. Local variables and formal args to functions are
private transient (they go away as soon as the function returns).
but OWN variables are private to the function but stay around
"forever" just like globals do, so that side effects on the OWN
variables that occurred during one call can persist to affect the
next call. Lexical closures in Common Lisp go one step further,
allowing private persistent variables to be shared between several
functions. All those functions share access to the private variable
which they co-OWN. Another way in which OWN or lexical-closure
variables aren't like what the word "own" means in ordinary
language is that it's possible to transfer ownership by selling or
giving something to somebody else, but not with OWN variables or
lexical-closure variables. So even though I like the word OWN
better than the word STATIC for this meaning, I'm not totally
comfortable with that jargon. But "persistent private" is a
mouthful compared to "OWN", and I doubt anyone can find a word of
appx. 3 characters that conveys the intended meaning so we're
probably stuck with "OWN" as the best short term.
--
http://mail.python.org/mailman/listinfo/python-list


jon at ffconsultancy

Jun 5, 2008, 3:37 AM

Post #52 of 112 (1884 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Robert Maas, http://tinyurl.com/uh3t wrote:
>> From: dkco...@panix.com (David Combs)
>> Lisp is *so* early a language (1960?), preceeded mainly only by
>> Fortran (1957?)?, and for sure the far-and-away the first as a
>> platform for *so many* concepts of computer-science, eg lexical vs
>> dynamic ("special") variables, passing *unnamed* functions as
>> args ... maybe is still the only one in which program and data
>> have the same representation -- that it'd seem logical to use it's
>> terminology in all languages.
>
> Yeah, but why did you cross-post to so many newsgroups? Are you
> trying to run a flame war between advocates of the various
> languages?

What would be the point? We all know that Java, Perl, Python and Lisp suck.
They don't even have pattern matching over algebraic sum types if you can
imagine that. How rudimentary...

--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com/products/?u
--
http://mail.python.org/mailman/listinfo/python-list


jon.harrop.ms.sharp at gmail

Jun 5, 2008, 6:17 AM

Post #53 of 112 (1900 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

On 5 Giu, 12:37, Jon Harrop <j...@ffconsultancy.com> wrote:
> [...]

P.S. Please don't look at my profile (at google groups), thanks!

Jon Harrop
--
http://mail.python.org/mailman/listinfo/python-list


jwkenne at attglobal

Jun 24, 2008, 3:42 PM

Post #54 of 112 (1872 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

David Combs wrote:
> passing
> *unnamed* functions as args (could Algol 60 also do something like that,
> via something it maybe termed a "thunk")

No, the "thunks" were necessary at the machine-language level to
/implement/ ALGOL 60, but they could not be expressed /in/ ALGOL.

--
John W. Kennedy
"The first effect of not believing in God is to believe in anything...."
-- Emile Cammaerts, "The Laughing Prophet"
--
http://mail.python.org/mailman/listinfo/python-list


jaycx2.3.calrobert at spamgourmet

Jun 29, 2008, 11:44 PM

Post #55 of 112 (1862 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Why this response is so belated:
<http://groups.google.com/group/misc.misc/msg/cea714440e591dd2>
= <news:rem-2008jun25-003 [at] yahoo>
> Date: Thu, 05 Jun 2008 11:37:48 +0100
> From: Jon Harrop <j...@ffconsultancy.com>
> We all know that Java, Perl, Python and Lisp suck.

Well at least you're three-quarters correct there.
But Lisp doesn't suck. That's where you're one quarter wrong.

> They don't even have pattern matching over algebraic sum types if
> you can imagine that.

I'm still waiting for you to precisely define what you mean by
"pattern matching" in this context. All I've heard from you so-far
are crickets. If you've set up a Web page with your personal
definition of "pattern matching" as you've been using that term
here, and you've posted its URL in a newsgroup article I didn't
happen to see, please post just the URL again here so that I might
finally see it. Or e-mail me the URL.

-
Nobody in their right mind likes spammers, nor their automated assistants.
To open an account here, you must demonstrate you're not one of them.
Please spend a few seconds to try to read the text-picture in this box:

/----------------------------------------------------------------------------\
| ,-.-. | |
| | | |, . ,---.,---.,---. ,---.,---.,---.,---|,---. |
| | | || | `---.| || | | ||---'|---'| |`---. |
| ` ' '`---| `---'`---'` ' ` '`---'`---'`---'`---' |
| `---' |
| | | o | | |
| |---.,---.| ,---. .,---. ,---.| ,---.,---. |---.,---.,---. |
| | ||---'| | | || | ,---|| | ||---'---| || ,---| |
| ` '`---'`---'|---' `` ' `---^`---'`---|`---' `---'` `---^ | |
| | `---' ' |
| | | | |
| ,---.,---.|--- . . .,---.,---.,---|,---.,---. |---.,---.,---. |
| | || || | | || || || ||---'| ---| || ,---| |
| ` '`---'`---' `-'-'`---'` '`---'`---'` `---'` `---^o |
\--------(Rendered by means of <http://www.schnoggo.com/figlet.html>)--------/
(You don't need JavaScript or images to see that ASCII-text image!!
You just need to view this in a fixed-pitch font such as Monaco.)

Then enter your best guess of the text (40-50 chars) into this TextField:
+--------------------------------------------------+
| |
+--------------------------------------------------+
--
http://mail.python.org/mailman/listinfo/python-list


jaycx2.3.calrobert at spamgourmet

Jun 30, 2008, 12:03 AM

Post #56 of 112 (1856 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Why this response is so belated:
<http://groups.google.com/group/misc.misc/msg/cea714440e591dd2>
= <news:rem-2008jun25-003 [at] yahoo>
> Date: Thu, 5 Jun 2008 06:17:01 -0700 (PDT)
> From: jon.harrop.ms.sh...@gmail.com
> P.S. Please don't look at my profile (at google groups), thanks!

Please don't look at the orange and green checkered elephant
playing a harp off-key while sitting on a toilet and passing wind.
--
http://mail.python.org/mailman/listinfo/python-list


jaycx2.3.calrobert at spamgourmet

Jun 30, 2008, 12:07 AM

Post #57 of 112 (1863 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Why this response is so belated:
<http://groups.google.com/group/misc.misc/msg/cea714440e591dd2>
= <news:rem-2008jun25-003 [at] yahoo>
> Date: Tue, 24 Jun 2008 18:42:15 -0400
> From: John W Kennedy <jwke...@attglobal.net>
> ... the "thunks" were necessary at the machine-language level to
> /implement/ ALGOL 60, but they could not be expressed /in/ ALGOL.

Ah, thanks for the clarification. Is that info in the appropriate
WikiPedia page? If not, maybe you would edit it in?
--
http://mail.python.org/mailman/listinfo/python-list


lew at lwsc

Jun 30, 2008, 4:51 AM

Post #58 of 112 (1856 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Robert Maas wrote:
> /----------------------------------------------------------------------------\
> | ,-.-. | |
> | | | |, . ,---.,---.,---. ,---.,---.,---.,---|,---. |
> | | | || | `---.| || | | ||---'|---'| |`---. |
> | ` ' '`---| `---'`---'` ' ` '`---'`---'`---'`---' |
> | `---' |
> | | | o | | |
> | |---.,---.| ,---. .,---. ,---.| ,---.,---. |---.,---.,---. |
> | | ||---'| | | || | ,---|| | ||---'---| || ,---| |
> | ` '`---'`---'|---' `` ' `---^`---'`---|`---' `---'` `---^ | |
> | | `---' ' |
> | | | | |
> | ,---.,---.|--- . . .,---.,---.,---|,---.,---. |---.,---.,---. |
> | | || || | | || || || ||---'| ---| || ,---| |
> | ` '`---'`---' `-'-'`---'` '`---'`---'` `---'` `---^o |
> \--------(Rendered by means of <http://www.sc*****************.html>)--------/
> (You don't need JavaScript or images to see that ASCII-text image!!
> You just need to view this in a fixed-pitch font such as Monaco.)
>
> Then enter your best guess of the text (40-50 chars) into this TextField:
> +--------------------------------------------------+
> | Your son totally needs a Wonder-Bra(r), double-D |
> +--------------------------------------------------+

--
Lew
--
http://mail.python.org/mailman/listinfo/python-list


jwkenne at attglobal

Jul 1, 2008, 6:56 PM

Post #59 of 112 (1847 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Robert Maas, http://tinyurl.com/uh3t wrote:
> Why this response is so belated:
> <http://groups.google.com/group/misc.misc/msg/cea714440e591dd2>
> = <news:rem-2008jun25-003 [at] yahoo>
>> Date: Tue, 24 Jun 2008 18:42:15 -0400
>> From: John W Kennedy <jwke...@attglobal.net>
>> ... the "thunks" were necessary at the machine-language level to
>> /implement/ ALGOL 60, but they could not be expressed /in/ ALGOL.
>
> Ah, thanks for the clarification. Is that info in the appropriate
> WikiPedia page? If not, maybe you would edit it in?

It is explained s.v. "thunk", which is referenced from "ALGOL 60". The
ALGOL "pass-by-name" argument/parameter matching was perhaps the most
extreme example ever of a language feature that was "elegant" but
insane. What it meant, in effect, was that, unless otherwise marked,
every argument was passed as two closures, one that returned a fresh
evaluation of the expression given as the argument, which was called
every time the parameter was read, and one that set the argument to a
new value, which was called every time the parameter was set.

See <URL:http://www.cs.sfu.ca/~cameron/Teaching/383/PassByName.html>.

ALGOL 60 could not create generalized user-written closures, but could
create one no more complex than a single expression with no arguments of
its own simply by passing the expression as an argument. But it was not
thought of as a closure; that was just how ALGOL 60 did arguments.
--
John W. Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like
That. ...you may come to think a blow bad, because it hurts, and not
because it humiliates. You may come to think murder wrong, because it
is violent, and not because it is unjust."
-- G. K. Chesterton. "The Ball and the Cross"
--
http://mail.python.org/mailman/listinfo/python-list


jaycx2.3.calrobert at spamgourmet

Jul 20, 2008, 10:36 AM

Post #60 of 112 (1821 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

> >> ... the "thunks" were necessary at the machine-language level to
> >> /implement/ ALGOL 60, but they could not be expressed /in/ ALGOL.
> > Ah, thanks for the clarification. Is that info in the appropriate
> > WikiPedia page? If not, maybe you would edit it in?
> From: John W Kennedy <jwke...@attglobal.net>
> It is explained s.v. "thunk", which is referenced from "ALGOL
> 60". The ALGOL "pass-by-name" argument/parameter matching was
> perhaps the most extreme example ever of a language feature that
> was "elegant" but insane. What it meant, in effect, was that,
> unless otherwise marked, every argument was passed as two closures,
> one that returned a fresh evaluation of the expression given as the
> argument, which was called every time the parameter was read, and
> one that set the argument to a new value, which was called every
> time the parameter was set.

Wow! All these years when I occasionally heard of a "thunk" I never
was told, until now, what it really meant. Thanks for the info!!

Followup question #1: I assume these are lexical closures in the
environment of the point of the call, right?

Followup question #2: For simple arithmetic expressions, I can
possibly understand how the UPDATE closure might be implemeted
(expressed in Lisp to make the intent clear):
Call form: MyFunction(X+2);
GET closure: (+ closedX 2)
UPDATE closure: (lambda (newval) (setf closedX (- newval 2))
Thus from inside MyFunction where formal parameter Arg1 is bound
to actual parameter X+2, after doing Arg1 := 7; X will have the
value 5 so that calling Arg1 will return 7 as expected, right?
But if the actual argument is something complicated, especially if
it makes a nested function call, how can that possibly be
implemented? Given an arbitrary expression that calls some external
function, how can assigning a value to that expression make
sufficient changes in the runtime environment such that
subsequently evaluating that expression will yield the expected
value i.e. the value that had been assigned?
Or is the default of passing two closures (GET and UPDATE) *only*
if the actual-argument expression is simple enough that it's
invertible, and in complicated cases only a GET closure is passed
(or the UPDATE closure is simply a signal of a runtime error
that you're not allowed to assign a value to a complicated expression)?

IMO the "right" way to pass parameters that can be modified is to
use "locatatives" as in the Lisp Machine. That converts the idea of
a "place" (as used by SETF in Common Lisp) into a "first class
citizen" which can be passed around and stored etc., compared to a
SETF place which is merely a compiletime-macro trick to convert
place-references in source code into direct calls to the
appropriate accessor just above the place followed by specialized
SETter call to do the act. A hack to emulate a locative in CL would
be to pass a closure where the code to find the object directly
containing the place, and any parameters needed to find that place,
and the function needed to perform the act. Then the called
function would need to know it's going to get such a thunk-like
closure, but since it's expecting to modify one of its parameters
anyway, that's reasonable. Sketch of implementation (two special cases):
(defun make-thunk-cadr (topptr)
(let* ((midptr (cdr topptr))
(getclo (make-getter-closure :PARENT midptr :GETTERFN #'car
:PARMS nil))
(setclo (make-setter-closure :PARENT midptr :SETTERFN #'rplaca
:PARMS nil)))
(make-thunk getclo setclo))
(defun make-thunk-aref1 (topptr arrindex1)
(let ((getclo (make-getter-closure :PARENT topptr :GETTERFN #'aref1
:PARMS (list arrindex1)))
(setclo (make-setter-closure :PARENT midptr :SETTERFN #'setaref1
:PARMS (list arrindex1))))
(make-thunk getclo setclo))
(defun swap (thunk1 thunk2)
(prog (tmp)
(setq tmp (thunk-get thunk1))
(thunk-set thunk1 (thunk-get thunk2))
(thunk-set thunk2 tmp)))
;Definitions of make-getter-closure make-setter-closure make-thunk
; thunk-get thunk-set not shown because they depend on whether
; closures and thunks are implemented via tagged assoc lists or
; DEFSTRUCT structures or CLOS objects or whatever. But I made the
; call to the constructors explicit enough that it should be obvious
; what components are inside each type of object. Note that with
; CLOS objects, this could all be condensed to have a single CLOS
; object which is the thunk which has two methods GET and SET, no
; need to make closures for get and set separately, templates for
; those closures are made automatically when the CLOS class is
; defined, and closures are generated from those templates whenever
; a new CLOS thunk-object is made. Thus:
; ... (make-CLOS-thunk :PARENT topptr :GETTERFN #'aref1 :SETTERFN #'setaref1
; :PARMS (list arrindex1)) ...

;Example that should actually work:
(format t " arr: ~S~% ixs: ~S~%" arr ixs)
arr: #'(3 5 7 11 13))
ixs: (2 4)
(setq arr #'(3 5 7 11 13))
(setq ixs (list 2 4))
(setq thunkcadr (make-thunk-cadr ixs))
;Locative to the 4 in ixs
(setq thunkaref (make-thunk-aref1 arr (thunk-get thunkcadr)))
;Locative to the 11 in the array
(swap thunkcadr thunkaref)
(format t " arr: ~S~% ixs: ~S~%" arr ixs)
arr: #'(3 5 7 4 13))
ixs: (2 11)
I haven't implemented this. I'm just specifying what the behaviour should be
and giving a sketch how it ought to be easily doable in Common Lisp.

And I'm not going to implement it because I have no use for this way
of coding, at least not currently or in the foreseeable future.
<tmi> Generally my abstract data type is at a higher level where the
caller doesn't know that a single place is going to need to be
SETFed, so there's no point in getting a locative to work with.
Instead there's some *kind* of update to do, and parameters to
that *kind* of update; what really happens internally (one or more
SETFs, or alternately re-build anything that changed and share what
didn't change) doesn't need to be known by the caller. All the
caller needs to know is generically whether the update is in-place
or non-destructive. (If it's non-destructive, then the new edition
of the data structure is one of the return values. If it's
in-place, then there's no need to bother with setq of the new
value, because my structures always have a header cell that has a
tag for the intentional datatype, and that header cell always
points to either the in-place-modified object or the
latest-edition-of-object.) </tmi>
<mtmi> I'd rather program in "paranoid" mode than in "risk shoot foot" mode.
The CAR of each ADT object is a keyword identifying the
intentional type of that object, and every function that
operates on that intentional type first checks if the parameter
really does have the expected CAR, just to make sure I didn't
copy&paste some inappropriate function name in my code. Yeah, it
takes extra CPU cycles to do that checking on every calls, but it
sure saves me from shooting myself in the foot and having to spend
an hour to find out how I did it before I can fix it. <mtmi>
<emtmi> TMI = Too Much Information (actually YMMV, some readers might like it)
MTMI = More of Too Much Information
EMTMI = Even More of Too Much Information (only newbies need read)
Credits to Babylon Five for the "I spy" game in the cargo hold.
I spy something that starts with the letter B. Boxes!
I spy something that starts with the letter M. More boxes! <emtmi>
--
http://mail.python.org/mailman/listinfo/python-list


jwkenne at attglobal

Jul 20, 2008, 3:29 PM

Post #61 of 112 (1819 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Robert Maas, http://tinyurl.com/uh3t wrote:
>>>> ... the "thunks" were necessary at the machine-language level to
>>>> /implement/ ALGOL 60, but they could not be expressed /in/ ALGOL.
>>> Ah, thanks for the clarification. Is that info in the appropriate
>>> WikiPedia page? If not, maybe you would edit it in?
>> From: John W Kennedy <jwke...@attglobal.net>
>> It is explained s.v. "thunk", which is referenced from "ALGOL
>> 60". The ALGOL "pass-by-name" argument/parameter matching was
>> perhaps the most extreme example ever of a language feature that
>> was "elegant" but insane. What it meant, in effect, was that,
>> unless otherwise marked, every argument was passed as two closures,
>> one that returned a fresh evaluation of the expression given as the
>> argument, which was called every time the parameter was read, and
>> one that set the argument to a new value, which was called every
>> time the parameter was set.
>
> Wow! All these years when I occasionally heard of a "thunk" I never
> was told, until now, what it really meant. Thanks for the info!!
>
> Followup question #1: I assume these are lexical closures in the
> environment of the point of the call, right?

Yes. (Actually, subprogram calls are first described as working like
macro expansions, but then the specification adds that there must be
magic fixups so that variable names are resolved in point-of-call
context anyway.)

At this point in the history of computing, the conceptual distinction
between subprograms and macros was not at all clear. It was quite
possible to have "macros" that generated an out-of-line subprogram once
and then generated calling code the first time and every time thereafter
(it was a way of life on systems without linkage editors or linking
loaders), and it was also quite possible to refer to in-line macro
expansions as "subprograms". I suspect that the triumph of FORTRAN may
have had something to do with cleaning up the terminological mess by the
mid-60s.

Into the 60s, indeed, there were still machines being made that had no
instruction comparable to the mainframe BASx/BALx family, or to Intel's
CALL. You had to do a subprogram call by first overwriting the last
instruction of what you were calling with a branch instruction that
would return back to you.

> Followup question #2: For simple arithmetic expressions, I can
> possibly understand how the UPDATE closure might be implemeted
> (expressed in Lisp to make the intent clear):
> Call form: MyFunction(X+2);
> GET closure: (+ closedX 2)
> UPDATE closure: (lambda (newval) (setf closedX (- newval 2))
> Thus from inside MyFunction where formal parameter Arg1 is bound
> to actual parameter X+2, after doing Arg1 := 7; X will have the
> value 5 so that calling Arg1 will return 7 as expected, right?
> But if the actual argument is something complicated, especially if
> it makes a nested function call, how can that possibly be
> implemented?

It was forbidden. In the formal definition of ALGOL 60, there was no
such thing as an external subprogram (except for non-ALGOL code, which
was treated as magic), so the whole program was supposed to be one
compile. Therefore, a theoretical compiler could verify that any
parameter used as an LHS was always matched with an argument that was a
variable. (However, a "thunk" was still required to evaluate any array
index and, possibly, to convert between REAL and INTEGER variables.)
Many actual compilers /did/ support separate complication as a language
extension -- I suppose they had to use run-time checking.

--
John W. Kennedy
"Compact is becoming contract,
Man only earns and pays."
-- Charles Williams. "Bors to Elayne: On the King's Coins"
--
http://mail.python.org/mailman/listinfo/python-list


martin at see_sig_for_address

Jul 22, 2008, 2:21 AM

Post #62 of 112 (1817 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

On Tue, 24 Jun 2008 18:42:15 -0400, John W Kennedy wrote:

> David Combs wrote:
>> passing
>> *unnamed* functions as args (could Algol 60 also do something like that,
>> via something it maybe termed a "thunk")
>
> No, the "thunks" were necessary at the machine-language level to
> /implement/ ALGOL 60, but they could not be expressed /in/ ALGOL.
>
Are you sure about that?

The first time I ran across the term "thunking" was when Windows 3
introduced the Win32S shim and hence the need to switch addressing between
16 bit and 32 bit modes across call interfaces. That was called "thunking"
by Microsoft and even they would surely admit it was a kludge.

I used Algol 60 on an Elliott 503 and the ICL 1900 series back when it was
a current language. The term "thunking" did not appear in either compiler
manual nor in any Algol 60 language definition I've seen. A60 could pass
values by name or value and procedures by name. That was it. Call by name
is what is now referred to as reference passing.

I should also point out that Algol 60 was initially written as a means for
communicating algorithms between people. Compiler implementations came
later. In consequence the language did not define links to libraries or
i/o methods. Both features were compiler specific - for instance the
Elliott introduced 'input' and 'print' reserved words and syntax while the
1900 compilers used function calls. The Elliott approach was more readable.

Algol 60 did not have 'functions'. It had procedures which could be
declared to return values or not. A procedure that returned a value was
equivalent to a function but the term 'function' was not used. Similarly
it did not have a mechanism for declaring anonymous procedures. That, like
the incorporation of machine code inserts, would have been a
compiler-specific extension, so it is a terminological mistake to refer to
it without specifying the implementing compiler.


--
martin@ | Martin Gregorie
gregorie. |
org | Zappa fan & glider pilot


--
http://mail.python.org/mailman/listinfo/python-list


arsyed at gmail

Jul 22, 2008, 2:56 AM

Post #63 of 112 (1812 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

On Tue, Jul 22, 2008 at 5:21 AM, Martin Gregorie
<martin [at] see_sig_for_address> wrote:
> On Tue, 24 Jun 2008 18:42:15 -0400, John W Kennedy wrote:
>
>> David Combs wrote:
>>> passing
>>> *unnamed* functions as args (could Algol 60 also do something like that,
>>> via something it maybe termed a "thunk")
>>
>> No, the "thunks" were necessary at the machine-language level to
>> /implement/ ALGOL 60, but they could not be expressed /in/ ALGOL.
>>
> Are you sure about that?
>
> The first time I ran across the term "thunking" was when Windows 3
> introduced the Win32S shim and hence the need to switch addressing between
> 16 bit and 32 bit modes across call interfaces. That was called "thunking"
> by Microsoft and even they would surely admit it was a kludge.
>
> I used Algol 60 on an Elliott 503 and the ICL 1900 series back when it was
> a current language. The term "thunking" did not appear in either compiler
> manual nor in any Algol 60 language definition I've seen. A60 could pass
> values by name or value and procedures by name. That was it. Call by name
> is what is now referred to as reference passing.
>


On Tue, Jul 22, 2008 at 5:21 AM, Martin Gregorie
<martin [at] see_sig_for_address> wrote:
> On Tue, 24 Jun 2008 18:42:15 -0400, John W Kennedy wrote:
>
>> David Combs wrote:
>>> passing
>>> *unnamed* functions as args (could Algol 60 also do something like that,
>>> via something it maybe termed a "thunk")
>>
>> No, the "thunks" were necessary at the machine-language level to
>> /implement/ ALGOL 60, but they could not be expressed /in/ ALGOL.
>>
> Are you sure about that?
>
> The first time I ran across the term "thunking" was when Windows 3
> introduced the Win32S shim and hence the need to switch addressing between
> 16 bit and 32 bit modes across call interfaces. That was called "thunking"
> by Microsoft and even they would surely admit it was a kludge.
>
> I used Algol 60 on an Elliott 503 and the ICL 1900 series back when it was
> a current language. The term "thunking" did not appear in either compiler
> manual nor in any Algol 60 language definition I've seen. A60 could pass
> values by name or value and procedures by name. That was it. Call by name
> is what is now referred to as reference passing.
>

Thunk has more than one meaning. The ALGOL 60 usage predates Windows
obviously. Also, call-by-name is distinct from call-by-reference.
See:

http://en.wikipedia.org/wiki/Evaluation_strategy

And, for fun with call-by-name:

http://en.wikipedia.org/wiki/Jensen%27s_Device
http://en.wikipedia.org/wiki/Man_or_boy_test
--
http://mail.python.org/mailman/listinfo/python-list


josef.moellers at fujitsu-siemens

Jul 22, 2008, 2:56 AM

Post #64 of 112 (1814 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Martin Gregorie wrote:

> Are you sure about that?

> I used Algol 60 on an Elliott 503 and the ICL 1900 series back when it was
> a current language. The term "thunking" did not appear in either compiler
> manual nor in any Algol 60 language definition I've seen. A60 could pass
> values by name or value and procedures by name. That was it. Call by name
> is what is now referred to as reference passing.

Are you sure about that? ;-)

AFAIK "Call by name" is *not* the same as passing an argument by
reference. With "call by name" you can implement this wonderful thing
called "Jensen's Device", which you cannot do when you pass parameters
by reference!

Josef
--
These are my personal views and not those of Fujitsu Siemens Computers!
Josef Möllers (Pinguinpfleger bei FSC)
If failure had no penalty success would not be a prize (T. Pratchett)
Company Details: http://www.fujitsu-siemens.com/imprint.html
--
http://mail.python.org/mailman/listinfo/python-list


rpw3 at rpw3

Jul 22, 2008, 5:23 AM

Post #65 of 112 (1811 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Martin Gregorie <martin [at] see_sig_for_address> wrote:
+---------------
| John W Kennedy wrote:
| > No, the "thunks" were necessary at the machine-language level to
| > /implement/ ALGOL 60, but they could not be expressed /in/ ALGOL.
|
| Are you sure about that?
+---------------

I don't know if John is, but *I* am! ;-}

+---------------
| I used Algol 60 on an Elliott 503 and the ICL 1900 series back when
| it was a current language. The term "thunking" did not appear in either
| compiler manual nor in any Algol 60 language definition I've seen.
+---------------

It wouldn't have been. Thunks were something used by Algol 60
*compiler writers* in the code generated by their compilers to
implement the semantics of Algol 60 call-by-name, but were not
visible to users at all [except that they allowed call-by-name
to "work right"].

+---------------
| A60 could pass values by name or value and procedures by name. That
| was it. Call by name is what is now referred to as reference passing.
+---------------

(*sigh*) NO, IT IS NOT!!! Please go read the following:

http://en.wikipedia.org/wiki/Thunk
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_name
http://en.wikipedia.org/wiki/Jensen%27s_Device

+---------------
| [Algol 60] did not have a mechanism for declaring anonymous procedures.
+---------------

Quite correct, but completely off the mark. While an Algol 60 *user*
could not declare an anonymous procedure, the *implementation* of an
Algol 60 compilers required the ability for the compiler itself to
generate/emit internal anonymous procedures, to wit, the above-mentioned
thunks, sometimes creating them dynamically during the procedure call.
[.Actually, a pair of them for each actual argument in a procedure call.]

+---------------
| That, like the incorporation of machine code inserts, would have been
| a compiler-specific extension, so it is a terminological mistake to
| refer to it without specifying the implementing compiler.
+---------------

Again, "incompetent, irrelevant, and immaterial" [as Perry Mason used
to so frequently object during trials]. Thunks were not "extensions" to
Algol 60 compilers; they were part of the basic implementation strategy
*within* Algol 60 compilers, necessary because of the semantics required
by call-by-name.

Basically, in Algol 60, each parameter must be passed [.in general,
that is, one can optimize away many special cases] as *two* closures --
conventionally called "thunks" by Algol 60 compiler writers -- one
for "getting" (evaluating) and the other for "setting" the parameter
[.if the parameter was a "place" in Common Lisp terms, else an error
was signalled]... IN THE CALLER'S LEXICAL ENVIRONMENT!!

The big deal was two-fold: (1) each time a formal parameter was
*referenced* in a callee, the expression for the actual parameter
in the caller had to be *(re)evaluated* in the *caller's* lexical
environment, and the value of that (re)evaluation used as the
value of the referenced formal parameter in the callee; and
(2) if a variable appeared twice (or more) in a parameter list,
say, once as a naked variable [which is a "place", note!] and again
as a sub-expression of a more complicated parameter, then setting
the formal parameter in the *callee* would *change* the value of
the actual parameter in the caller(!!), which in turn would change
the value of the *other* actual parameter in the caller the next time
it was referenced in the callee. The above-referenced "Jensen's Device"
shows how this can be used to do "very tricky stuff". A simpler and
shorter example is here:

http://www.cs.rit.edu/~afb/20013/plc/slides/procedures-07.html

Because the actual parameters in the callee had to be evaluated
in the *caller's* lexical environment -- and because Algol 60 was
fully recursive, allowed nested procedure definitions, and could
pass "local" procedures as arguments -- efficient implementation of
Algol 60 procedure calls almost necessitated placing the bodies
of the compiler-generated actual parameter thunks on the caller's
dynamic stack frame [.or at least call instructions *to* the thunks
which could pass the current lexical contours as sub-arguments].
Knuth's nasty "man or boy test" stressed this to the limit:

http://en.wikipedia.org/wiki/Man_or_boy_test


-Rob

p.s. IIRC [but it's been a *long* time!], the ALGOL-10 compiler
for the DEC PDP-10 passed each actual parameter as the address of
a triple of words, of which the first two were executable and the
third could be used to store a variables value (simple case) or
to pass the lexical contour (more complicated case). When the
callee needed to reference (evaluate) an argument, it used the
PDP-10 XCT ("execute") instruction to execute the first word of
the block, which was required to deliver the value to a standard
register [let's say "T0", just for concreteness], and if the callee
wanted to *set* an argument, it executed the *second* word pointed
to by the passed address, with the new value also in a defined place
[again, let's use T0]. So to implement "X := X + 1;" in the callee,
the compiler would emit code like this:

MOVE T1,{the arg (address) corresponding to "X"}
XCT 0(T1) ; fetch the current value of X into T0.
ADDI T0, 1 ; increment it
XCT 1(T1) ; execute the "setter" for X.

Now in the case where the actual parameter in the caller was a
simple global variable, call it "Y", then the address passed as
the arg could be the following "YTHNK" in static data space:

YTHNK: MOVE T0,.+2 ; one-instruction "getter"
MOVEM T0,.+1 ; one-instruction "setter"
Y: BLOCK 1 ; the actual place where the value "Y" lives

Whereas if the argument being passed were some more complicated
expression, such as an array reference or a reference to a local
procedure in the caller, then the 3-word arg block would be passed
on the stack and the passed address would point to this [possibly
dynamically-constructed] triple, where PUSHJ is the PDP-10 stack-
oriented subroutine call instruction:

PUSHJ P,{lambda-lifted getter code}
PUSHJ P,{lambda-lifted setter code}
EXP {lexical contour info needed for getter/setter to work}

Efficient for the simple case; slow-but-correct for the messy case.

-----
Rob Warnock <rpw3 [at] rpw3>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

--
http://mail.python.org/mailman/listinfo/python-list


com.lewscanon at lew

Jul 22, 2008, 6:54 AM

Post #66 of 112 (1815 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Rob Warnock wrote:
> Martin Gregorie <martin [at] see_sig_for_address> wrote:
> +---------------
> | John W Kennedy wrote:
> | > No, the "thunks" were necessary at the machine-language level to
> | > /implement/ ALGOL 60, but they could not be expressed /in/ ALGOL.
> |
> | Are you sure about that?
> +---------------
>
> I don't know if John is, but *I* am! ;-}

At this point we are so far off topic for clj.programmer, but still impinging
on functional programming issues with the discussion of closures, et al., that
I respectfully request that you all exclude clj.programmer from followups to
this thread.

(f-u set to comp.lang.functional)

--
Lew
--
http://mail.python.org/mailman/listinfo/python-list


steve at fenestra

Jul 22, 2008, 9:29 AM

Post #67 of 112 (1813 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

On Tue, 22 Jul 2008 10:21:50 +0100, Martin Gregorie
<martin [at] see_sig_for_address> wrote:

>The first time I ran across the term "thunking" was when Windows 3
>introduced the Win32S shim and hence the need to switch addressing between
>16 bit and 32 bit modes across call interfaces. That was called "thunking"
>by Microsoft and even they would surely admit it was a kludge.

Win32s thunks are a completely different beast from the original Algol
60 thunks. As far as I know, the first published description of thunks
was:

Ingerman PZ (1961) Thunks: A way of compiling procedure statements with
some comments on procedure declarations, CACM 4:55-58.

Steve Schafer
Fenestra Technologies Corp.
http://www.fenestra.com/
--
http://mail.python.org/mailman/listinfo/python-list


grante at visi

Jul 22, 2008, 11:17 AM

Post #68 of 112 (1805 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

On 2008-07-22, Steve Schafer <steve [at] fenestra> wrote:
> On Tue, 22 Jul 2008 10:21:50 +0100, Martin Gregorie
><martin [at] see_sig_for_address> wrote:
>
>>The first time I ran across the term "thunking" was when Windows 3
>>introduced the Win32S shim and hence the need to switch addressing between
>>16 bit and 32 bit modes across call interfaces. That was called "thunking"
>>by Microsoft and even they would surely admit it was a kludge.

What?! Microsoft took a technical term and used it to mean
something completely different than the widely used meaning?
Never.

> Win32s thunks are a completely different beast from the
> original Algol 60 thunks. As far as I know, the first
> published description of thunks was:
>
> Ingerman PZ (1961) Thunks: A way of compiling procedure statements with
> some comments on procedure declarations, CACM 4:55-58.

The Algol usage is certainly what we were taught back in the
late 70's. I wasn't even aware that Microsoft had hijacked it
to mean something else.

--
Grant Edwards grante Yow! My polyvinyl cowboy
at wallet was made in Hong
visi.com Kong by Montgomery Clift!
--
http://mail.python.org/mailman/listinfo/python-list


jwkenne at attglobal

Jul 22, 2008, 12:54 PM

Post #69 of 112 (1818 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Martin Gregorie wrote:
> I used Algol 60 on an Elliott 503 and the ICL 1900 series back when it was
> a current language. The term "thunking" did not appear in either compiler
> manual nor in any Algol 60 language definition I've seen.

It doesn't have to; Algol 60 thunks are not part of the language.
However, practical implementation of Algol 60 call by name means that
thunks are created by every Algol 60 compiler, and the word "thunk" was
coined in 1961 to designate them.

> A60 could pass
> values by name or value and procedures by name. That was it. Call by name
> is what is now referred to as reference passing.

Either you misunderstood (because in many simple cases the semantics of
call-by-reference and call-by-name cannot be distinguished) or the
compiler you used implemented non-standard Algol (which was fairly
common in compilers meant for day-to-day practical work). Algol
call-by-name was a unique form that subsequent language designers have
recoiled from in horror.

(Historically, "call-by-name" has sometimes been used in non-Algol
contexts to mean "call-by-reference".)

> Algol 60 did not have 'functions'. It had procedures which could be
> declared to return values or not. A procedure that returned a value was
> equivalent to a function but the term 'function' was not used.

This is simply wrong. You are accurately describing the language syntax,
which used (as PL/I does) the keyword "procedure" for both functions
and subroutines, but Algol documentation nevertheless referred to
"functions".

> Similarly
> it did not have a mechanism for declaring anonymous procedures. That, like
> the incorporation of machine code inserts, would have been a
> compiler-specific extension, so it is a terminological mistake to refer to
> it without specifying the implementing compiler.

Standards-conforming Algol compilers had a limited ability to create
de-facto anonymous functions in the call-by-name implementation.

--
John W. Kennedy
"Information is light. Information, in itself, about anything, is light."
-- Tom Stoppard. "Night and Day"
--
http://mail.python.org/mailman/listinfo/python-list


jwkenne at attglobal

Jul 22, 2008, 12:57 PM

Post #70 of 112 (1822 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Rob Warnock wrote:
> Thunks were something used by Algol 60
> *compiler writers* in the code generated by their compilers to
> implement the semantics of Algol 60 call-by-name, but were not
> visible to users at all [except that they allowed call-by-name
> to "work right"].

...unless you were a system programmer and had to write Algol-friendly
assembler.



--
John W. Kennedy
"Give up vows and dogmas, and fixed things, and you may grow like
That. ...you may come to think a blow bad, because it hurts, and not
because it humiliates. You may come to think murder wrong, because it
is violent, and not because it is unjust."
-- G. K. Chesterton. "The Ball and the Cross"
--
http://mail.python.org/mailman/listinfo/python-list


jaycx2.3.calrobert at spamgourmet

Aug 12, 2008, 12:28 PM

Post #71 of 112 (1779 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

John W Kennedy <jwke...@attglobal.net> wrote:
JWK> Into the 60s, indeed, there were still machines being made
JWK> that had no instruction comparable to the mainframe BASx/BALx
JWK> family, or to Intel's CALL. You had to do a subprogram call by
JWK> first overwriting the last instruction of what you were
JWK> calling with a branch instruction that would return back to
JWK> you.

That's not true, that you needed to do that, that there was no
other way available. The subroutine linkage I invented for S.P.S.
(Symbolic Programming System, i.e. IBM 1620 assembly language) was
to reserve a 5-digit space immediately before the subroutine entry
point for storing the return address. So the caller needed to know
only one address, the entry point, and do both store-return-address
and jump relative to that address, rather than needing to know both
the entry point and the last-instruction-JUMP-needs-patch address
as independent items of information. So calling a subroutine was
two instructions (pseudo-code here):
literal[nextAdrOfSelf} -> memory[SubrEntryPoint-1]
jump to SubrEntryPoint
and returning from a subroutine was two instructios:
copy memory[SubrEntryPoint-1] -> memory[here + 11]
jump to 00000 ;These zeroes replaced by return address just above
Of course if you needed to pass parameters and/or return value,
that was handled separately, perhaps by reserving additional
storage just before the return address. Of course this methodology
didn't support recursion.

So my method required one extra instruction per return point, but
allowed multiple return points from a single subroutine, and
allowed "encapsulation" of the relation between entry point and
return point.

Note: On IBM 1620, instructions and forward-sweeping data records
were addressed by their *first* digit, whereas arithmetic fields
were addressed by their *last* digit, the low-order position, to
support natural add-and-carry operations. Storage was decimal
digits, with two extra bits, flag to indicate negative value (if in
low-order position) or high-order-end (if in any other position),
and parity. Values larger than nine were reserved for special
purposes, such as RECORD MARK used to terminate right-sweep data
records. Because of that, the low-order position of the return
address and the first digit of the machine instruction at the
subroutine entry point differed by only machine address, hence the
SubrEntryPoint-1 instead of SubrEntryPoint-5 you would otherwise
expect.

Hmm, I suppose if I had thought it out more at the time, I might have
done it slightly differently:

Entry point like this:
jump 00000 ;Patched by caller to contain return address
Entry: ...(regular code)...
...

Each return point like this:
jump Entry-12


I wonder if anybody ever implemented a stack on the IBM 1620?
Probably not, because it would take a lot more machine instructions
to push and pop, and if you weren't writing anything recursive then
extra work for no extra benefit except saving a few digits of
memory if your maximum stack depth is less than the total number of
subroutines you have loaded, except the extra instructions more
than kill off the storage savings.

Hmm, I suppose you could have a auxilary function that serves as
trampoline for stack-based call and return. To call, you move your
own return address and address of subroutine to fixed locations in
low memory then jump to the call trampoline, which pushes the
return address onto the stack and jumps at entry address. To
return, you just jump to the return trampoline, which pops the
return address off the stack and jumps at it. The trampoline,
occuping memory only *once*, could afford to have code to safely
check for stack over/under flow.
--
http://mail.python.org/mailman/listinfo/python-list


see_website at mindprod

Aug 12, 2008, 1:26 PM

Post #72 of 112 (1752 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

On Tue, 12 Aug 2008 12:28:33 -0700,
jaycx2.3.calrobert [at] spamgourmet (Robert Maas,
http://tinyurl.com/uh3t) wrote, quoted or indirectly quoted someone
who said :

>Note: On IBM 1620, instructions and forward-sweeping data records
>were addressed by their *first* digit, whereas arithmetic fields
>were addressed by their *last* digit, the low-order position, to
>support natural add-and-carry operations. Storage was decimal
>digits, with two extra bits, flag to indicate negative value (if in
>low-order position) or high-order-end (if in any other position),
>and parity.

What a memory you have to recall the precise details of work you did
45 odd years ago.
--

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
--
http://mail.python.org/mailman/listinfo/python-list


arne at vajhoej

Aug 12, 2008, 5:40 PM

Post #73 of 112 (1784 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Robert Maas, http://tinyurl.com/uh3t wrote:
> John W Kennedy <jwke...@attglobal.net> wrote:
> JWK> Into the 60s, indeed, there were still machines being made
> JWK> that had no instruction comparable to the mainframe BASx/BALx
> JWK> family, or to Intel's CALL. You had to do a subprogram call by
> JWK> first overwriting the last instruction of what you were
> JWK> calling with a branch instruction that would return back to
> JWK> you.
>
> That's not true, that you needed to do that, that there was no
> other way available. The subroutine linkage I invented for S.P.S.
> (Symbolic Programming System, i.e. IBM 1620 assembly language) was
> to reserve a 5-digit space immediately before the subroutine entry
> point for storing the return address. So the caller needed to know
> only one address, the entry point, and do both store-return-address
> and jump relative to that address, rather than needing to know both
> the entry point and the last-instruction-JUMP-needs-patch address
> as independent items of information.

CDC Cyber did something very similar.

Not very recursion friendly.

Arne
--
http://mail.python.org/mailman/listinfo/python-list


jwkenne at attglobal

Aug 14, 2008, 3:33 PM

Post #74 of 112 (1743 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

Robert Maas, http://tinyurl.com/uh3t wrote:
> John W Kennedy <jwke...@attglobal.net> wrote:
> JWK> Into the 60s, indeed, there were still machines being made
> JWK> that had no instruction comparable to the mainframe BASx/BALx
> JWK> family, or to Intel's CALL. You had to do a subprogram call by
> JWK> first overwriting the last instruction of what you were
> JWK> calling with a branch instruction that would return back to
> JWK> you.
>
> That's not true, that you needed to do that, that there was no
> other way available. The subroutine linkage I invented for S.P.S.
> (Symbolic Programming System, i.e. IBM 1620 assembly language) was
> to reserve a 5-digit space immediately before the subroutine entry
> point for storing the return address. So the caller needed to know
> only one address, the entry point, and do both store-return-address
> and jump relative to that address, rather than needing to know both
> the entry point and the last-instruction-JUMP-needs-patch address
> as independent items of information. So calling a subroutine was
> two instructions (pseudo-code here):
> literal[nextAdrOfSelf} -> memory[SubrEntryPoint-1]
> jump to SubrEntryPoint
> and returning from a subroutine was two instructios:
> copy memory[SubrEntryPoint-1] -> memory[here + 11]
> jump to 00000 ;These zeroes replaced by return address just above
> Of course if you needed to pass parameters and/or return value,
> that was handled separately, perhaps by reserving additional
> storage just before the return address. Of course this methodology
> didn't support recursion.
>
> So my method required one extra instruction per return point, but
> allowed multiple return points from a single subroutine, and
> allowed "encapsulation" of the relation between entry point and
> return point.
>
> Note: On IBM 1620, instructions and forward-sweeping data records
> were addressed by their *first* digit, whereas arithmetic fields
> were addressed by their *last* digit, the low-order position, to
> support natural add-and-carry operations. Storage was decimal
> digits, with two extra bits, flag to indicate negative value (if in
> low-order position) or high-order-end (if in any other position),
> and parity. Values larger than nine were reserved for special
> purposes, such as RECORD MARK used to terminate right-sweep data
> records. Because of that, the low-order position of the return
> address and the first digit of the machine instruction at the
> subroutine entry point differed by only machine address, hence the
> SubrEntryPoint-1 instead of SubrEntryPoint-5 you would otherwise
> expect.
>
> Hmm, I suppose if I had thought it out more at the time, I might have
> done it slightly differently:
>
> Entry point like this:
> jump 00000 ;Patched by caller to contain return address
> Entry: ...(regular code)...
> ...
>
> Each return point like this:
> jump Entry-12
>
>
> I wonder if anybody ever implemented a stack on the IBM 1620?
> Probably not, because it would take a lot more machine instructions
> to push and pop, and if you weren't writing anything recursive then
> extra work for no extra benefit except saving a few digits of
> memory if your maximum stack depth is less than the total number of
> subroutines you have loaded, except the extra instructions more
> than kill off the storage savings.
>
> Hmm, I suppose you could have a auxilary function that serves as
> trampoline for stack-based call and return. To call, you move your
> own return address and address of subroutine to fixed locations in
> low memory then jump to the call trampoline, which pushes the
> return address onto the stack and jumps at entry address. To
> return, you just jump to the return trampoline, which pops the
> return address off the stack and jumps at it. The trampoline,
> occuping memory only *once*, could afford to have code to safely
> check for stack over/under flow.

Actually, I was thinking of the 1401. But both the 1620 and the 1401
(without the optional Advanced Programming Feature) share the basic
omission of any instruction that could do call-and-return without
hard-coding an adcon with the address of the point to be returned to.
(The Advanced Programming Feature added a 1401 instruction, Store
B-address Register, that, executed as the first instruction of a
subroutine, could store the return-to address.)

The 1620, oddly enough, /did/ have call instructions (Branch and
Transfer, and Branch and Transfer Immediate) and a return instruction
(Branch Back), but with a hard-wired stack depth of 1.

--
John W. Kennedy
"When a man contemplates forcing his own convictions down another
man's throat, he is contemplating both an unchristian act and an act of
treason to the United States."
-- Joy Davidman, "Smoke on the Mountain"
--
http://mail.python.org/mailman/listinfo/python-list


norseman at hughes

Aug 14, 2008, 4:54 PM

Post #75 of 112 (1739 views)
Permalink
Re: The Importance of Terminology's Quality [In reply to]

John W Kennedy wrote:
> Robert Maas, http://tinyurl.com/uh3t wrote:
>> John W Kennedy <jwke...@attglobal.net> wrote:
>> JWK> Into the 60s, indeed, there were still machines being made
>> JWK> that had no instruction comparable to the mainframe BASx/BALx
>> JWK> family, or to Intel's CALL. You had to do a subprogram call by
>> JWK> first overwriting the last instruction of what you were
>> JWK> calling with a branch instruction that would return back to
>> JWK> you.
>>

HUMMmmmmm! Brings back memories. The Monroe-bot 9, Olivetti,
Sperry-Rand and the rest. I came in on the IBM-360 original series in
the mid-60'. Subroutine docs were important. You needed to know from
which register the sub was going to use/store the return address. (As
well as which registers it used for what both incoming and out going.)

it's been so long I forget the actual mnemonics.
something like:
.
.
load R12,rtn89 (alt)
jump sub32 sub32: sub32:
rtn89: stor R12,safe .
. . .
. . jump R12
rtrv R12,safe
jump R12
Programs were simple then. Card, paper tape, mag tape IN and card, paper
tape, mag tape and hardcopy paper OUT. The monitor was the guy who
looked at the flashing lights on the metal panel. And to change a
program on the 1401 usually required the soldering iron, patch cables
and a patch board! And a new deck of cards containing the next program.
Don't use a used deck 'cause then the reader will eat the cards. :)
I helped Chevron East convert from 1401 to 360. Long ago, far away and
with no intention of returning to those long long hours in 'the room'.
LSI??? Ha-Ha. Anyone remember the word transistor?. Power supply was
tubes. However, core was 3-axis iron core. That I miss.
17 flip switches
set 1-16 & flip 17 to load first half word
set 1-16 & flip 17 to load 2nd half word 1st boot word ready
.
.
core boot loaded mag master 1 and read next sequence which ...

only took 45 min. to boot if first effort succeeded. Otherwise...
it was going to be a long day....

The "Good 'Ole Days"? Point of view. Code was tight and comradely was
what kept us going. The long hours and being shunned by company people
as gargoyles down there or some such - I can do without.

...(snip)



Steve
norseman [at] hughes

OH- If the sub might be called other than as if in-line, an area of
memory was given to safe and it would be incremented/decremented upon
use. safe was just an address. safe dw 40 or whatever

--
http://mail.python.org/mailman/listinfo/python-list

First page Previous page 1 2 3 4 5 Next page Last page  View All Python python RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.