The Importance of Terminology's Quality

[szr]

The OP is a very well-known troll who has the habit of spitting out a
borderline OT article to a bunch of loosly related NGs ever so often
and then sits back and enjoys the complaints and counter-complaints
of the regulars.

While I agree cross-posting should be chosen more carefully, it seemed
like a harmless article to me. I did not get the impression he was just
trolling. There are people who like to post articles they come across
and maybe want to start a discussion on.

Like I said, this may have been better to put in a more general
programming group, and that yes, it is kind of OT for specific language
groups, but I really saw no harm in it (and I saw no one try to redirect
the discussion to a more general group), and you and anyone else are
free to ignore the thread. All I ask is you allow people to make up
their own minds.

 

[Arne Vajhøj]

Looking at the original post, it doesn't appear to be about any specific
language.

That does not make it on topic in the Java group.

And the subthread Lew commented on most certainly is not.

Arne

 

[Arne Vajhøj]

Indeed. That suggests it's probably off-topic in most, if not all,
of the newsgroups to which it was posted, inasmuch as they exist for
topics specific to a given programming language.

Perhaps - comp.programming might of been a better place, but not all
people who follow groups for specific languages follow a general group
like that - but let me ask you something. What is it you really have
against discussing topics with people of neighboring groups? Keep in
mind you don't have to read anything you do not want to read. [1]

I very much doubt that the original thread is relevant for the Java
group.

But the subthread Lew commente don was about Perl and Unix. That is
clearly off topic.

Personally I am rather tolerant for topics. But I can not blame Lew
for requesting that a Perl-Unix discussion does not get cross posted
to a Java group.

Regardless, unless you are actually reading this thread from the
c.l.j.p newsgroup, I'm not sure I see the point in questioning
someone who _is_ about whether the thread belongs there or not.

I would rather have the OP comment about that, as he started the thread.
But what gets me is why you are against that specific group being
included but not others? What is so special about the Java group and why
are you so sure people there don't want to read this thread? [1] What
right do you or I or anyone have to make decisions for everyone in a
news group? Isn't this why most news readers allow one to block a
thread?

I doubt Lew read any of the other groups, so it seems quite
natural that he did not comment on the on/off topic characteristics
in those.

And if it's a vote you want, mark me down as the third person reading
c.l.j.p that doesn't feel this thread belongs. I don't know whether
Lew speaks for the entire newsgroup, but based on comments so far,
it's pretty clear that there unanimous agreement among those who have
expressed an opinion.

Ok, so, perhaps 3 people out of what might be several hundred, if not
thousand (there is no way to really know, but there are certainly a lot
of people who read that group, and as with any group, there are far more
readers than there are people posting, so, again, just because you or
two other people or so don't want to read a topic or dislike it, you
feel you can decide for EVERYONE they mustn't read it? Again, this is
why readers allow you to ignore threads. Please don't force your views
on others; let them decide for themselves. [1]

And I am sure that Lew did not intended to pretend to speak for
the entire group. He spoke for himself.

I believe there has been several posts that agreed with him and none
that disagreed, so it seems very plausible that the group indeed agree
with him.

Arguing that a huge silent majority has a different opinion
than those speaking up is a very questionable argument. Everybody
could try and count them for their view. The only reasonable
thing is not to count them.

Arne

 

[szr]

Arne Vajhøj wrote:
Stephan Bour wrote:
Lew wrote:
} John Thingstad wrote:
} > Perl is solidly based in the UNIX world on awk, sed, } > bash
and C. I don't like the style, but many do.
}
} Please exclude the Java newsgroups from this discussion.

Did it ever occur to you that you don't speak for entire news
groups?
Did it occur to you that there are nothing about Java in the
above ?
Looking at the original post, it doesn't appear to be about any
specific language.
Indeed. That suggests it's probably off-topic in most, if not all,
of the newsgroups to which it was posted, inasmuch as they exist for
topics specific to a given programming language.

Perhaps - comp.programming might of been a better place, but not all
people who follow groups for specific languages follow a general
group like that - but let me ask you something. What is it you
really have against discussing topics with people of neighboring
groups? Keep in mind you don't have to read anything you do not want
to read. [1]

I very much doubt that the original thread is relevant for the Java
group.

But the subthread Lew commente don was about Perl and Unix. That is
clearly off topic.

I agree with and understand what you are saying in general, but still,
isn't it possible that were are people in the java group (and others)
who might of been following the thread, only to discover (probably not
right away) that someone decided to remove the group they were reading
the thread from? I know I would not like that, even if it wasn't on
topic at the branch.

Personally, I find it very annoying to have to switch news groups in
order to resume a thread and weed my way down the thread to where it
left off before it was cut off from the previous group.

 

[Arne Vajhøj]

Peter Duniho wrote:
Arne Vajhøj wrote:
Stephan Bour wrote:
Lew wrote:
} John Thingstad wrote:
} > Perl is solidly based in the UNIX world on awk, sed, } > bash
and C. I don't like the style, but many do.
}
} Please exclude the Java newsgroups from this discussion.

Did it ever occur to you that you don't speak for entire news
groups?
Did it occur to you that there are nothing about Java in the
above ?
Looking at the original post, it doesn't appear to be about any
specific language.
Indeed. That suggests it's probably off-topic in most, if not all,
of the newsgroups to which it was posted, inasmuch as they exist for
topics specific to a given programming language.
Perhaps - comp.programming might of been a better place, but not all
people who follow groups for specific languages follow a general
group like that - but let me ask you something. What is it you
really have against discussing topics with people of neighboring
groups? Keep in mind you don't have to read anything you do not want
to read. [1]

I very much doubt that the original thread is relevant for the Java
group.

But the subthread Lew commente don was about Perl and Unix. That is
clearly off topic.

I agree with and understand what you are saying in general, but still,
isn't it possible that were are people in the java group (and others)
who might of been following the thread, only to discover (probably not
right away) that someone decided to remove the group they were reading
the thread from? I know I would not like that, even if it wasn't on
topic at the branch.

Personally, I find it very annoying to have to switch news groups in
order to resume a thread and weed my way down the thread to where it
left off before it was cut off from the previous group.

I am relative tolerant towards threads that are a bit off topic, if
the S/N ratio overall is good.

But I accept and respect that other people has a more strict
attitude against off topic posts.

And I am very little tolerant towards people that think they
can attack those that want only on topic posts.

One thing is to ask for a bit of slack regarding the rules
something else is attacking those that want the rules
kept.

Arne

 

[szr]

szr wrote:
Peter Duniho wrote:
Arne Vajhøj wrote:
Stephan Bour wrote:
Lew wrote:
} John Thingstad wrote:
} > Perl is solidly based in the UNIX world on awk, sed, } >
bash and C. I don't like the style, but many do.
}
} Please exclude the Java newsgroups from this discussion.

Did it ever occur to you that you don't speak for entire news
groups?
Did it occur to you that there are nothing about Java in the
above ?
Looking at the original post, it doesn't appear to be about any
specific language.
Indeed. That suggests it's probably off-topic in most, if not
all, of the newsgroups to which it was posted, inasmuch as they
exist for topics specific to a given programming language.
Perhaps - comp.programming might of been a better place, but not
all people who follow groups for specific languages follow a
general group like that - but let me ask you something. What is it
you really have against discussing topics with people of
neighboring groups? Keep in mind you don't have to read anything
you do not want to read. [1]
I very much doubt that the original thread is relevant for the Java
group.

But the subthread Lew commente don was about Perl and Unix. That is
clearly off topic.

I agree with and understand what you are saying in general, but
still, isn't it possible that were are people in the java group (and
others) who might of been following the thread, only to discover
(probably not right away) that someone decided to remove the group
they were reading the thread from? I know I would not like that,
even if it wasn't on topic at the branch.

Personally, I find it very annoying to have to switch news groups in
order to resume a thread and weed my way down the thread to where it
left off before it was cut off from the previous group.

I am relative tolerant towards threads that are a bit off topic, if
the S/N ratio overall is good.

Agreed.

[...]

If a thread, that is cross-posted, branches off on a tangent that has
nothing to do with one or more groups what so ever, then yes, it makes
sense to prune the 'newsgroup:' list / set follow ups, but in this case,
someone made one mention or so of 'Perl', which was being used as an
example, and someone (lew) moved to have the Java group removed.

There was little reason to cut off the thread, when people very well may
have been following it, over the utterance of one word, which was being
used as an example. The bulk of the thread had to do with general
programming, and suddenly writing the name of a language doesn't mean
it's way off on a tangent.

I hope this clears up some waters.

Regards.

 

[jon.harrop.ms.sharp]

[...]

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

Jon Harrop

 

[John W Kennedy]

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]

Why this response is so belated:


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"

 

[John W Kennedy]

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.

 

[Martin Gregorie]

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.

 

[Josef Moellers]

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

 

[John W Kennedy]

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]

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"

 

[Lew]

+---------------
| 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 misdeed for clj.deprogrammer, but still impinging
on biorobotic programming issues with the adoption of closures, et al., that
I respectfully request that you all stimulate clj.sadist from albums to
this predictor.

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

--
Lew


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"The goals for this country are peace in the world.
And the goals for this country are a compassionate
American for every single citizen.
That compassion is found in the hearts and souls of
the American citizens."

--- Adolph Bush,
Washington, D.C., Dec. 19, 2002

 

[Roedy Green]

On Tue, 12 Aug 2008 12:28:33 -0700,
(e-mail address removed) (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.

 

[Arne Vajhøj]

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

 

[John W Kennedy]

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"

 

[Martijn Lievaart]

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

Raaaagh!!!!

Don't. Bring. Back. Those. Nightmares. Please.

The 1401 was a decent enough processor for many industrial tasks -- at
that time -- but for general programming it was sheer horror.

M4

 

[John W Kennedy]

Raaaagh!!!!

Don't. Bring. Back. Those. Nightmares. Please.

The 1401 was a decent enough processor for many industrial tasks -- at
that time -- but for general programming it was sheer horror.

But the easiest machine language /ever/.