Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #1991 > unrolled thread

Re: Add nested-function support in a language the based on a stack-machine

Back to article view | Back to comp.compilers

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Add nested-function support in a language the based on a stack-machine Martin Ward <martin@gkc.org.uk> - 2018-03-12 16:17 +0000
    Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <157-073-9834@kylheku.com> - 2018-03-13 03:02 +0000
      Re: Add nested-function support in a language the based on a stack-machine Martin Ward <martin@gkc.org.uk> - 2018-03-19 11:04 +0000
        Re: Add nested-function support in a language the based on a stack-machine Gene Wirchenko <genew@telus.net> - 2018-03-19 12:50 -0700
          Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <157-073-9834@kylheku.com> - 2018-03-20 16:16 +0000
          Re: Add nested-function support in a language the based on a stack-machine Martin Ward <martin@gkc.org.uk> - 2018-03-23 10:44 +0000
            Re: algorithm performance, was Add nested-function support in a language the based on a stack-machine Andy Walker <anw@cuboid.co.uk> - 2018-03-23 18:47 +0000
              Re: algorithm performance, was Add nested-function support in a language the based on a stack-machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-03-24 14:06 +0000
                Re: algorithm performance, was Add nested-function support in a language the based on a stack-machine rpw3@rpw3.org (Rob Warnock) - 2018-03-25 07:02 +0000
                  Re: algorithm performance "Robin Vowels" <robin51@dodo.com.au> - 2018-03-27 01:22 +1100
            Re: sorting performance, Add nested-function support in a language the based on a stack-machine w.clodius@icloud.com (William Clodius) - 2018-03-24 23:25 -0600
        Re: Add nested-function support in a language the based on a stack-machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-03-20 09:06 +0000
          Re: Add nested-function support in a language the based on a stack-machine Bill Findlay <findlaybill@blueyonder.co.uk> - 2018-03-20 12:49 +0000
          Re: language design after Algol 60, was Add nested-function support Martin Ward <martin@gkc.org.uk> - 2018-03-27 14:46 +0100
            Re: language design after Algol 60, was Add nested-function support anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-03-30 14:20 +0000
            Re: language design after Algol 60, was Add nested-function support Martin Ward <martin@gkc.org.uk> - 2018-04-06 16:09 +0100
              Re: language design after Algol 60, was Add nested-function support "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2018-04-08 14:21 +0100
                Re: language design after Algol 60, was Add nested-function support George Neuner <gneuner2@comcast.net> - 2018-04-09 16:51 -0400
                  Re: language design after Algol 60, was Add nested-function support anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-04-10 05:48 +0000
                    Re: language design after Algol 60, was Add nested-function support George Neuner <gneuner2@comcast.net> - 2018-04-10 14:32 -0400
                      Re: language design after Algol 60, was Add nested-function support Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-04-12 01:09 +0200
                        Re: language design after Algol 60, was Add nested-function support bartc <bc@freeuk.com> - 2018-04-12 11:51 +0100
                          Re: language design after Algol 60, was Add nested-function support bartc <bc@freeuk.com> - 2018-04-12 19:40 +0100
                            Re: language design after Algol 60, was Add nested-function support Martin Ward <martin@gkc.org.uk> - 2018-04-13 14:10 +0100
                              Re: language design after Algol 60 "Robin Vowels" <robin51@dodo.com.au> - 2018-04-14 14:11 +1000
                                RE: language design after Algol 60 "Costello, Roger L." <costello@mitre.org> - 2018-04-16 12:56 +0000
                                  Re: language design after Algol 60 "Robin Vowels" <robin51@dodo.com.au> - 2018-04-17 19:08 +1000
                                    Re: Language design after Algol 60 "Robin Vowels" <robin51@dodo.com.au> - 2018-04-18 14:58 +1000
                                    Re: language design after Algol 60 Gene Wirchenko <genew@telus.net> - 2018-04-18 16:12 -0700
                                Re: language design after Algol 60 Martin Ward <martin@gkc.org.uk> - 2018-05-01 10:42 +0100
                            Re: language design after Algol 60 "Robin Vowels" <robin51@dodo.com.au> - 2018-04-14 14:19 +1000
                              Re: language design after Algol 60 bartc <bc@freeuk.com> - 2018-04-14 20:43 +0100
                              Re: language design after Algol 60 Andy Walker <anw@cuboid.co.uk> - 2018-04-15 00:04 +0100
                        Re: language design after Algol 60, was Add nested-function support rpw3@rpw3.org (Rob Warnock) - 2018-04-12 14:05 +0000
                        Re: language design after Algol 60, was Add nested-function support George Neuner <gneuner2@comcast.net> - 2018-04-12 20:51 -0400
                          Re: OOP language design after Algol 60, was Add nested-function support Kaz Kylheku <157-073-9834@kylheku.com> - 2018-04-13 03:22 +0000
                          Re: OOP language design after Algol 60, was Add nested-function support Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-04-13 10:22 +0200
                            Re: OOP language design after Algol 60, was Add nested-function support George Neuner <gneuner2@comcast.net> - 2018-04-14 13:40 -0400
                              Re: OOP language design after Algol 60, was Add nested-function support Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-04-15 00:12 +0200
                              Re: OOP language design after Algol 60, was Add nested-function support Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-04-15 00:23 +0200
                  Re: language design after Algol 60, was Add nested-function support "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2018-04-10 13:15 +0100
                    Re: language design after Algol 60, was Add nested-function support Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-04-11 13:27 +0200
                      Re: language design after Algol 60, was Add nested-function support "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2018-04-11 20:06 +0100
                  Re: language design after Algol 60, was Add nested-function support Kaz Kylheku <157-073-9834@kylheku.com> - 2018-04-10 18:32 +0000
                    Re: language design after Algol 60, was Add nested-function support George Neuner <gneuner2@comcast.net> - 2018-04-12 20:57 -0400
                      Re: OOP language design after Algol 60, was Add nested-function support Kaz Kylheku <157-073-9834@kylheku.com> - 2018-04-13 03:28 +0000
              Re: language design after Algol 60, was Add nested-function support albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2018-05-05 13:50 +0200
        Re: Add nested-function support in a language the based on a stack-machine mac <acolvin@efunct.com> - 2018-03-20 15:27 +0000
    Re: Add nested-function support in a language the based on a stack-machine w.clodius@icloud.com (William Clodius) - 2018-03-12 21:09 -0600
      Re: Add nested-function support in a language the based on a stack-machine Kartik Agaram <ak@akkartik.com> - 2018-03-13 13:27 -0700
        Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <157-073-9834@kylheku.com> - 2018-03-14 00:07 +0000
          Re: Add nested-function support in a language the based on a stack-machine Kartik Agaram <ak@akkartik.com> - 2018-03-13 22:31 -0700
            Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <157-073-9834@kylheku.com> - 2018-03-14 14:49 +0000
      Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <157-073-9834@kylheku.com> - 2018-03-13 20:51 +0000
      Re: Add nested-function support in a language the based on a stack-machine Andy Walker <anw@cuboid.co.uk> - 2018-03-14 00:27 +0000
        Re: Add nested-function support in a language the based on a stack-machine Andy Walker <anw@cuboid.co.uk> - 2018-03-14 16:37 +0000
    Re: Add nested-function support in a language the based on a stack-machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-03-14 15:16 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#2059 — Re: language design after Algol 60, was Add nested-function support

Am 10.04.2018 um 20:32 schrieb George Neuner:
> On Tue, 10 Apr 2018 05:48:43 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:

> Smalltalk had/has single inheritence only, and it's dynamic dispatch
> mechanism is very different from that of C++.

Isn't *multiple inheritance* one of the features that C++ proved
impractical? Which other languages support multiple inheritance?

DoDi
[Lots of languages have multiple inheritance.  Python is one of the
more popular these days.  As you've seen, opinions vary about how
useful it is.  -John]

[toc] | [prev] | [next] | [standalone]

#2063 — Re: language design after Algol 60, was Add nested-function support

On 12/04/2018 00:09, Hans-Peter Diettrich wrote:
> Am 10.04.2018 um 20:32 schrieb George Neuner:
>> On Tue, 10 Apr 2018 05:48:43 GMT, anton@mips.complang.tuwien.ac.at
>> (Anton Ertl) wrote:
>
>> Smalltalk had/has single inheritence only, and it's dynamic dispatch
>> mechanism is very different from that of C++.
>
> Isn't *multiple inheritance* one of the features that C++ proved
> impractical? Which other languages support multiple inheritance?
>
> DoDi
> [Lots of languages have multiple inheritance.  Python is one of the
> more popular these days.  As you've seen, opinions vary about how
> useful it is.  -John]

It's so useful that I have to go and look up what exactly it means (and
then I'm not much the wiser).

But I guess some people develop dependences on such features. If I
question some exotic feature in the Python group, there will always be
someone for whom it is indispensable.

(Never mind that Python lacks what to me are fundamental features such
as named constants, 'switch', records, enumerations, repeat-n-times
loops, static local variables, pass-by-reference, or goto.

Some of those can apparently be emulated - usually badly and
cumbersomely - by making use of the advanced features.)

The trouble is, if you dare to put forward such a point of view, someone
is going to mention the 'blub paradox', just to put you in your place.

--
bartc
[Python certainly has a lot of theology.  I believe that python users
would say that your misssing features are implemented through simple
idioms and aren't worth gunking up the languages, e.g. repeat N times
is "for i in range(N):".  But like I said, it's theology. -John]

[toc] | [prev] | [next] | [standalone]

#2066 — Re: language design after Algol 60, was Add nested-function support

On 12/04/2018 11:51, bartc wrote:

> [Python certainly has a lot of theology.  I believe that python users
> would say that your misssing features are implemented through simple
> idioms and aren't worth gunking up the languages, e.g. repeat N times
> is "for i in range(N):".  But like I said, it's theology. -John]

(Just on that point, that is one of the simpler features and it is just
neater syntax for something that can be expressed in other ways.

But it is not adding extra syntax; if anything it is getting rid of it!
If a for-loop starts like this:

     for i:=1 to n do ...

Then by leaving out the bits not needed you end up with this:

     to n do ...

A repeat-n-times loop (one that doesn't have to maintain an explicit
loop counter accessible as a reference-counted variable from the source
code). And an endless loop by leaving 'to n'. (This comes from Algol-68
actually; not my idea.)

But even if extra syntax is needed, so what? Syntax is free, provided
you don't go mad with it. Compare with the type system and libraries for
which no such curbs appear to exist)

--
bartc
[Syntax is free in the compiler but not necessarily in the brains of
the programmers.  Back when I was writing PL/I programs, people said
my code was unreadable because I'd learned PL/I from the reference
manual, while everyone else learned it from books like "PL/I for
Fortran progammers" or "PL/I for commercial programmers."  My code
used what seemed reasonable to me but others found it a mishmosh of
stuff they knew and stuff they didn't.  -John]

[toc] | [prev] | [next] | [standalone]

#2075 — Re: language design after Algol 60, was Add nested-function support

> [Syntax is free in the compiler but not necessarily in the brains of
> the programmers.  Back when I was writing PL/I programs, people said
> my code was unreadable because I'd learned PL/I from the reference
> manual, while everyone else learned it from books like "PL/I for
> Fortran progammers" or "PL/I for commercial programmers."  My code
> used what seemed reasonable to me but others found it a mishmosh of
> stuff they knew and stuff they didn't.  -John]

The IBM Language Reference for Enterprise PL/I for z/OS is 862 pages.

E.W.Dijkstra wrote in his ACM Turing Lecture 1972:

"Finally, although the subject is not a pleasant one, I must
mention PL/1, a programming language for which the defining
documentation is of a frightening size and complexity.
Using PL/1 must be like flying a plane with 7000 buttons,
switches and handles to manipulate in the cockpit.
I absolutely fail to see how we can keep our growing programs
firmly within our intellectual grip when by its sheer baroqueness
the programming language -- our basic tool, mind you! -- already
escapes our intellectual control."

He concluded:

"We shall do a much better programming job, provided that we approach
the task with a full appreciation of its tremendous difficulty,
provided that we stick to modest and elegant programming languages,
provided that we respect the intrinsic limitations of the human mind
and approach the task as Very Humble Programmers."

--
			Martin

Dr Martin Ward | Email: martin@gkc.org.uk | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
[It was PL/I F, for which the manual was much shorter. The ANSI
standard, on the other hand, was and is unreadable, page after page
of VDL. -John]

[toc] | [prev] | [next] | [standalone]

#2076 — Re: language design after Algol 60

From: "Martin Ward" <martin@gkc.org.uk>
Sent: Friday, April 13, 2018 11:10 PM


> The IBM Language Reference for Enterprise PL/I for z/OS is 862 pages.

The IBM PL/I for OS/2 Language Reference is 491 pages plus 121 pages
for the built-in functions, published 1994.
This reference includes a number of new language features.

The language references also include a number of example programs.

> E.W.Dijkstra wrote in his ACM Turing Lecture 1972:
>
> "Finally, although the subject is not a pleasant one, I must
> mention PL/1, a programming language for which the defining
> documentation is of a frightening size and complexity.
> Using PL/1 must be like flying a plane with 7000 buttons,
> switches and handles to manipulate in the cockpit.

Dijkstra's comment is nonsense.
It seems that he couldn't even spell the name of the language.
[assuming that the quotation is literally correct]

> I absolutely fail to see how we can keep our growing programs
> firmly within our intellectual grip when by its sheer baroqueness
> the programming language -- our basic tool, mind you! -- already
> escapes our intellectual control."

Others seem to have mastered it, but not Dijkstra, apparently.
[Considering how quickly it was designed, PL/I is not a bad language,
but it definitely has parts that fit together poorly.  I once tried
to write a program that used arrays of 12-bit strings and the code
PL/I F generated was very special, not in a good way.  Per one of my
previous comments, few programmers learn all of PL/I, most learn a
subset adequate for the kind of programming they do.  I doubt many
write programs that use both recursive routines with stacks of
controlled storage and decimal picture I/O. -John]

[toc] | [prev] | [next] | [standalone]

#2083 — RE: language design after Algol 60

Robin Vowels wrote:

> Dijkstra's comment is nonsense.

I am curious, why do you say Dijkstra's comment is nonsense?

> [assuming that the quotation is literally correct]

The quote seems to be correct:

https://books.google.com/books?id=JdziBwAAQBAJ&pg=PA15&lpg=PA15&dq=Finally,+although+the+subject+is+not+a+pleasant+one,+I+must+mention+PL/1,+a+programming+language+for+which+the+defining+documentation+is+of+a+frightening+size+and+complexity&source=bl&ots=5709gQOo9K&sig=AfrW2xb-WrcWKpmRAsfxufLS0F4&hl=en&sa=X&ved=0ahUKEwj4od7S677aAhUHvFMKHSF3AcUQ6AEIKTAA#v=onepage&q=Finally%2C%20although%20the%20subject%20is%20not%20a%20pleasant%20one%2C%20I%20must%20mention%20PL%2F1%2C%20a%20programming%20language%20for%20which%20the%20defining%20documentation%20is%20of%20a%20frightening%20size%20and%20complexity&f=false

[Read the page or so around the quote and you'll see that Dijkstra
thought Algol60, of which he was one of the authors, was too
complicated, because BNF made it too easy to specify syntax.  As far
as I can tell, he wanted extremely simple languages to make it easier
to prove programs correct.  But that, of course, is another swamp.
-John]

[toc] | [prev] | [next] | [standalone]

#2084 — Re: language design after Algol 60

From: "Costello, Roger L." <costello@mitre.org>
Sent: Monday, April 16, 2018 10:56 PM
> Robin Vowels wrote:
>
>> Dijkstra's comment is nonsense.
>
> I am curious, why do you say Dijkstra's comment is nonsense?

Dijkstra's comment is nonsense because it is possible to master the
language.  His analogy with flying a plane is entirely erroneous.

Yes, when it was introduced PL/I was a larger and richer language than
FORTRAN, but was easier to learn and to use, and because there were
not numerous restrictions on such things as expressions in DO
statements, extended ranges, awkward rules in constructing and using
FORMAT statements, etc.

It was possible to do much more with the language, especially with
character strings (who recalls Hollerith constants?).

One I recall, storing large arrays in a machne with limited storage --
declare an array of one-digit decimal integers.

[BTW, the current specification of Fortran is longer than that of PL/I.]

[Perhaps he meant that it was impossible for *him* to master the language.
It does have some odd rough edges, e.g., give or take my recollection of
the syntax:

  DCL (A,B,C) CHAR(3);
  A = '123';
  B = '456';
  C = A+B;

What does C contain?  Answer: three spaces. -John]

[toc] | [prev] | [next] | [standalone]

#2085 — Re: Language design after Algol 60

From John Levine
Sent: Monday, April 16, 2018 10:56 PM

> [Perhaps he meant that it was impossible for *him* to master the language.
> It does have some odd rough edges, e.g., give or take my recollection of
> the syntax:

>   DCL (A,B,C) CHAR(3);
>   A = '123';
>   B = '456';
>  C = A+B;

> What does C contain?  Answer: three spaces. -John]

No.  IBM's PL/I for Windows compiler produces two diagnostics:

1: at compilation time, at line 6 [your line 4]:

(6:1) : IBM1211I W Source in string assignment is longer than the target C.

2. At execution time, a fatal error at the assignment C = A+B :

IBM0441I  ONCODE=0150  The STRINGSIZE condition was raised.
   At offset +0000016B in procedure with entry L

Character variables were not really intended for doing decimal arithmetic,
though conversions from character to decimal are more-or-less common.

I'm not sure whether a compiler warning message would have been
produced in the 1960s with the PL/I F-compiler,
but am fairly certain that there would have been no run-time error.
[I got the three spaces in PL/I F.  I dimly recall that if I turned on optimization,
it'd do constant substitution and just move the three spaces into C.  Nice to hear
that they warn you off this design error now. -John]

[toc] | [prev] | [next] | [standalone]

#2087 — Re: language design after Algol 60

On Tue, 17 Apr 2018 19:08:57 +1000, Our Esteemed Moderator wrote:

[snip]

>[BTW, the current specification of Fortran is longer than that of PL/I.]
>
>[Perhaps he meant that it was impossible for *him* to master the language.
>It does have some odd rough edges, e.g., give or take my recollection of
>the syntax:
>
>  DCL (A,B,C) CHAR(3);
>  A = '123';
>  B = '456';
>  C = A+B;
>
>What does C contain?  Answer: three spaces. -John]

     There was an even weirder PL/I one that I tried to find but can
not.  As I recall, it was five implicit conversions that ended up with
a value opposite to the starting value.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#2089 — Re: language design after Algol 60

On 14/04/18 05:11, Robin Vowels wrote:
>> The IBM Language Reference for Enterprise PL/I for z/OS is 862 pages.
>
> The IBM PL/I for OS/2 Language Reference is 491 pages plus 121 pages
> for the built-in functions, published 1994.
> This reference includes a number of new language features.

So in order to master PL/I one would need to read *both* manuals, and
probably a few other similar sized manuals for any other versions or
variants of PL/I that may be in existence.

As we will see below, different versions of PL/I give different
meanings even for a very simple statement such as "C = A+B".  Someone
who has mastered PL/I would need to have *all* of these different
meanings at their fingertips.

> Dijkstra's comment is nonsense because it is possible to master the
> language.  His analogy with flying a plane is entirely erroneous.
...
>> What does C contain?  Answer: three spaces. -John]
>
> No.  IBM's PL/I for Windows compiler produces two diagnostics:
>
> 1: at compilation time, at line 6 [your line 4]:
>
> (6:1) : IBM1211I W Source in string assignment is longer than the target C.
>
> 2. At execution time, a fatal error at the assignment C = A+B :
>
> IBM0441I  ONCODE=0150  The STRINGSIZE condition was raised.
>   At offset +0000016B in procedure with entry L

Clearly *you* have not mastered PL/I: since you had to construct and
execute a sample program in order to find out the meaning of the very
simple statement "C = A+B" on a particular version of PL/I, and you do
not know the meaning of the statement for other versions of PL/I that
you do not have access to:

> I'm not sure whether a compiler warning message would have been
> produced in the 1960s with the PL/I F-compiler,
> but am fairly certain that there would have been no run-time error.

You are "fairly certain" that PL/I F gives a compiler warning, but
John knows that it does not. It would appear from this discussion that
Dijkstra's evaluation of PL/I has been fully justified: "I absolutely
fail to see how we can keep our growing programs firmly within our
intellectual grip when by its sheer baroqueness the programming
language -- our basic tool, mind you! -- already escapes our
intellectual control."

When you have to type in and execute a program to find out what "C =
A+B" does, then you can safely say that the programming language has
indeed escaped your intellectual control.

Later in the same paragraph he described PL/I as having the "growth
characteristics of a dangerous tumor": the growth of the manual from
612 pages in 1994 to 892 pages in 2013 also bears out this statement
as prophetic.

https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340.html

--
			Martin

Dr Martin Ward | Email: martin@gkc.org.uk | http://www.gkc.org.uk
G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
[Every language's manual grows over the years so I don't think that is a fair
comparison.  PL/I was a large language for its time but if you compare it
to, say, C++ or even python with its standard libraries it's not all that
large.  It does have the problem of having been invented in a hurry, so
that there are persistent rough edges where the parts from Fortran and
the parts from Cobol meet.  This will end the skirmishing unless someone
has something about, you know, building PL/I compilers. -John]

[toc] | [prev] | [next] | [standalone]

#2077 — Re: language design after Algol 60

From: "bartc" <bc@freeuk.com>
Sent: Friday, April 13, 2018 4:40 AM


> But it is not adding extra syntax; if anything it is getting rid of it!
> If a for-loop starts like this:
>
>     for i:=1 to n do ...
>
> Then by leaving out the bits not needed you end up with this:
>
>     to n do ...

The control variable, i, must not be omitted.
It may be required for computations within the loop
(including subscript references).

Even if not explicitly referenced within the loop,
its value will be required for fault finding (with error control
and/or with debugger).

> A repeat-n-times loop (one that doesn't have to maintain an explicit
> loop counter accessible as a reference-counted variable from the source
> code).

It's still required, as described above.

[toc] | [prev] | [next] | [standalone]

#2079 — Re: language design after Algol 60

On 14/04/2018 05:19, Robin Vowels wrote:
> From: "bartc" <bc@freeuk.com>
> Sent: Friday, April 13, 2018 4:40 AM
>
>
>> But it is not adding extra syntax; if anything it is getting rid of it!
>> If a for-loop starts like this:
>>
>>     for i:=1 to n do ...
>>
>> Then by leaving out the bits not needed you end up with this:
>>
>>     to n do ...
>
> The control variable, i, must not be omitted.
> It may be required for computations within the loop
> (including subscript references).
>
> Even if not explicitly referenced within the loop,
> its value will be required for fault finding (with error control
> and/or with debugger).

Huh? Who says that?

This example is from my language (inspired by Algol68), where the
control variable /can/ be omitted. And it's not needed any more than you
need one here for this line of code repeated three times:

     print "*"
     print "*"
     print "*"

(For that matter, it can be omitted from a C for-loop too, if only
because that language is so crude it doesn't even have the concept of a
control variable for a loop.)

>> A repeat-n-times loop (one that doesn't have to maintain an explicit
>> loop counter accessible as a reference-counted variable from the source
>> code).
>
> It's still required, as described above.

If implemented as an actual loop (rather than unrolling or whatever),
then there might be a count kept somewhere. But it doesn't need to be in
a format compatible with the regular variables in the language or be
part of its type system.

The count might also increment upwards or downwards; more likely the latter.

If a loop index is needed for fault-finding, then you just switch over
to for-loop that does have the index.

--
bartc

[toc] | [prev] | [next] | [standalone]

#2082 — Re: language design after Algol 60

On 14/04/18 05:19, Robin Vowels wrote:
> From: "bartc" <bc@freeuk.com>
[...]
>> Then by leaving out the bits not needed you end up with this:
>>     to n do ...
> The control variable, i, must not be omitted.

	Can't answer for Python [the previous topic] or for BartC's
own languages, but in Algol 68, as Bart referenced, it most certainly
can, and sometimes ought to be.

	Specific examples:

   (a) Sometimes the control variable does not proceed by constant
increments:

       int i := 0;
       to n do ...;  i +:= f(i) od

   (b) Sometimes the control variable, if present, might overflow, eg in
       the case of a loop that goes round more than "maxint" times:

       while ... do ... od

       [May be worth noting that RR3.5.2 Step 4 contains a bug in the
        printed version in this case, pointed out and corrected somewhere
         in "Algol Bulletin".  You could write "for i by 0 to 2 ..." but
        that is just silly.]

> It may be required for computations within the loop
> (including subscript references).

	And it may not.  Programmer's decision.

> Even if not explicitly referenced within the loop,
> its value will be required for fault finding (with error control
> and/or with debugger).

	*May* be.  Depends on the "error control" and "debugger", and
how they, if they exist, interact with the programmer, on what faults
may have occurred -- perhaps the code was already tested -- and on
the phase of the moon.

	Personally, I'm not a big fan of the style police, nor of
languages that encourage them.

--
Andy Walker,
Nottingham.

[toc] | [prev] | [next] | [standalone]

#2065 — Re: language design after Algol 60, was Add nested-function support

Hans-Peter Diettrich  <DrDiettrich1@netscape.net> wrote:
+---------------
| Isn't *multiple inheritance* one of the features that C++ proved
| impractical? Which other languages support multiple inheritance?
|
| DoDi
| [Lots of languages have multiple inheritance.  Python is one of the
| more popular these days.  As you've seen, opinions vary about how
| useful it is.  -John]
+---------------

Common Lisp has multiple inheritance, as well as multiple dispatch.


-Rob

-----
Rob Warnock		<rpw3@rpw3.org>
627 26th Avenue		<http://rpw3.org/>
San Mateo, CA 94403

[toc] | [prev] | [next] | [standalone]

#2067 — Re: language design after Algol 60, was Add nested-function support

On Thu, 12 Apr 2018 01:09:42 +0200, Hans-Peter Diettrich
<DrDiettrich1@netscape.net> wrote:

>Am 10.04.2018 um 20:32 schrieb George Neuner:
>> On Tue, 10 Apr 2018 05:48:43 GMT, anton@mips.complang.tuwien.ac.at
>> (Anton Ertl) wrote:
>
>> Smalltalk had/has single inheritence only, and it's dynamic dispatch
>> mechanism is very different from that of C++.
>
>Isn't *multiple inheritance* one of the features that C++ proved
>impractical? Which other languages support multiple inheritance?

No.  It proved only that C++ wasn't able to accomodate conflicting
classes effectively.  Lisp handles this same problem much more
effectively, so it isn't a generic fault of MI.

Moreover, most (all?) SI languages implement interfaces (abstract
classes).  Interfaces mainly are a workaround for lacking real MI, so
why would they do that if it were useless?


C++ implemented interfaces also, but it did so because it's object
layout semantics did not allow for the merging of non-conflicting
members, and its dispatch semantics did not adequately address
predictable function dispatch in the case of "diamond" inheritance.

Lisp addresses both of these issues very well, and also handles the
issue of conflicting (by type) members.


>[Lots of languages have multiple inheritance.  Python is one of the
>more popular these days.  As you've seen, opinions vary about how
>useful it is.  -John]

Obviously it depends on the specifics of the hierarchy. There is no
guarantee that MI will save you anything.  But where interfaces are
commonly employed in SI languages, an implementation under MI might
well be less work.

It often is the case that a subclass has to reimplement something from
one of its ancestors, and it *might* be the case with MI that there is
a clash wrt handling something that has to be worked around.  But
using interfaces, it is *guaranteed* that you will have to
(re)implement not just things that conflict, but everything in the
interface.

YMMV,
George

[toc] | [prev] | [next] | [standalone]

#2070 — Re: OOP language design after Algol 60, was Add nested-function support

On 2018-04-13, George Neuner <gneuner2@comcast.net> wrote:
> On Thu, 12 Apr 2018 01:09:42 +0200, Hans-Peter Diettrich
><DrDiettrich1@netscape.net> wrote:
>
>>Am 10.04.2018 um 20:32 schrieb George Neuner:
>>> On Tue, 10 Apr 2018 05:48:43 GMT, anton@mips.complang.tuwien.ac.at
>>> (Anton Ertl) wrote:
>>
>>> Smalltalk had/has single inheritence only, and it's dynamic dispatch
>>> mechanism is very different from that of C++.
>>
>>Isn't *multiple inheritance* one of the features that C++ proved
>>impractical? Which other languages support multiple inheritance?
>
> No.  It proved only that C++ wasn't able to accomodate conflicting
> classes effectively.  Lisp handles this same problem much more
> effectively, so it isn't a generic fault of MI.

More problematic than the lexical conflicts is the whole business
of "virtual inheritance". If you don't use it, you end up with
with multiple copies of the same bases via different paths in the
multiple inheritance DAG.

It all has to do with the specification of C++ inheritance (and
everything else) being motivated by a specific locus of implementations:
how it works at the memory layout level with specific pointers, offsets,
tables and whatnot.

Before the C++ people specify anything, they first have to ensure that
some relatively cheap and fast mechanism can handle it at run-time.
That then guides how the specification is written, even if it is not
explicitly in the wording.

> Moreover, most (all?) SI languages implement interfaces (abstract
> classes).  Interfaces mainly are a workaround for lacking real MI, so
> why would they do that if it were useless?

Are they? Interfaces are only a workaround for lack of MI if you
take it for granted that a class must *declare* inheritance from
B before its instances are permitted to be substituted wherever
a B may be used.

If you do not take that for granted, then you don't need inheritance
at all.

In the Common Lisp object system that you mentioned, we can easily
specialize the same method to string or integer, even though those
are not related by inheritance. We just:

  (defmethod foo ((arg integer))
    ...)

  (defmethod foo ((arg string))
    ...)

The integer and string classes doesn't have to have a declaration
injected into them which them allows their instances to appear
as obj in (foo obj) calls.

So *that* motivation for MI is absent: we can take any class
or classes, and just use them in multiple method-based protocols;
as many as we want.


--
TXR Programming Lanuage: http://nongnu.org/txr
Music DIY Mailing List:  http://www.kylheku.com/diy
ADA MP-1 Mailing List:   http://www.kylheku.com/mp1

[toc] | [prev] | [next] | [standalone]

#2072 — Re: OOP language design after Algol 60, was Add nested-function support

Am 13.04.2018 um 02:51 schrieb George Neuner:
> On Thu, 12 Apr 2018 01:09:42 +0200, Hans-Peter Diettrich
> <DrDiettrich1@netscape.net> wrote:
>
>> Am 10.04.2018 um 20:32 schrieb George Neuner:
>>> On Tue, 10 Apr 2018 05:48:43 GMT, anton@mips.complang.tuwien.ac.at
>>> (Anton Ertl) wrote:
>>
>>> Smalltalk had/has single inheritence only, and it's dynamic dispatch
>>> mechanism is very different from that of C++.
>>
>> Isn't *multiple inheritance* one of the features that C++ proved
>> impractical? Which other languages support multiple inheritance?
>
> No.  It proved only that C++ wasn't able to accomodate conflicting
> classes effectively.  Lisp handles this same problem much more
> effectively, so it isn't a generic fault of MI.
>
> Moreover, most (all?) SI languages implement interfaces (abstract
> classes).  Interfaces mainly are a workaround for lacking real MI, so
> why would they do that if it were useless?

Interfaces don't have all the problems arising from multiple
inheritance. I can see only the disadvantage, that duplicate code may be
required to implement the same interface in multiple classes. But see
below...

I've learned to distinguish class aggregation and composition by asking
whether it *is* something, or *has* something. A house *has* a roof, but
it *isn't* a roof, so it does not inherit from a roof class. This way I
never felt a need for multiple inheritance in my programs. But perhaps
outside my restricted experience there exist other needs...


> It often is the case that a subclass has to reimplement something from
> one of its ancestors, and it *might* be the case with MI that there is
> a clash wrt handling something that has to be worked around.  But
> using interfaces, it is *guaranteed* that you will have to
> (re)implement not just things that conflict, but everything in the
> interface.

An interface can be implemented by a (class type) component of a class.
Then only the specific dependencies between both classes have to be
implemented explicitly. In Delphi the "implements" keyword implements
such object delegation, in addition to method delegation.

DoDi

[toc] | [prev] | [next] | [standalone]

#2078 — Re: OOP language design after Algol 60, was Add nested-function support

On Fri, 13 Apr 2018 10:22:03 +0200, Hans-Peter Diettrich
<DrDiettrich1@netscape.net> wrote:

>Am 13.04.2018 um 02:51 schrieb George Neuner:
>> On Thu, 12 Apr 2018 01:09:42 +0200, Hans-Peter Diettrich
>> <DrDiettrich1@netscape.net> wrote:
>>
>>> Am 10.04.2018 um 20:32 schrieb George Neuner:
>>>> On Tue, 10 Apr 2018 05:48:43 GMT, anton@mips.complang.tuwien.ac.at
>>>> (Anton Ertl) wrote:
>
>> Moreover, most (all?) SI languages implement interfaces (abstract
>> classes).  Interfaces mainly are a workaround for lacking real MI, so
>> why would they do that if it were useless?
>
>Interfaces don't have all the problems arising from multiple
>inheritance. I can see only the disadvantage, that duplicate code may be
>required to implement the same interface in multiple classes. But see
>below...

Addressing your next point, interfaces don't easily solve the problem
that class A really IS-A class B and also IS-A class C.

>I've learned to distinguish class aggregation and composition by asking
>whether it *is* something, or *has* something. A house *has* a roof, but
>it *isn't* a roof, so it does not inherit from a roof class. This way I
>never felt a need for multiple inheritance in my programs. But perhaps
>outside my restricted experience there exist other needs...

HAS-A relationships also can be handled by container delegation if the
object system supports it.  E.g., the house object can contain a roof
object and "roof requests" sent to the house can be forwarded to the
contained roof.

IMO, this is a really useful feature that too few object systems
support.



The distinction between IS-A and HAS-A is something that isn't really
addressed by MI inheritence.  But that isn't to say that it couldn't
be.  Something like "implements" (more below) in an MI language could
be used to inherit preserving the HAS-A distinction for some suitable
predicate.

But IMO it is more natural to ask if something DOES <foo> or IS
<fooable> rather than to ask if it HAS some property <foo>. Obviously,
it's the same question - but the way in which it is asked implies a
slightly different semantic - one which MI answers directly [modulo
class naming] without needing any distinction of interfaces. YMMV.


>> It often is the case that a subclass has to reimplement something from
>> one of its ancestors, and it *might* be the case with MI that there is
>> a clash wrt handling something that has to be worked around.  But
>> using interfaces, it is *guaranteed* that you will have to
>> (re)implement not just things that conflict, but everything in the
>> interface.
>
>An interface can be implemented by a (class type) component of a class.
>Then only the specific dependencies between both classes have to be
>implemented explicitly. In Delphi the "implements" keyword implements
>such object delegation, in addition to method delegation.

But not all languages are so kind.

The problem is in unrelated classes that need to implement the entire
interface.  Consider, e.g., serializable, or displayable - in many
languages you would end up reimplementing the entire interface in
every branch of your heirarchy, with overrides in virtually every
subclass.

The result is that some languages now have many such things built-in -
either implicitly, or via wizard mechanisms like "implements".  Lots
of built-in functionality takes the sting out of using uncooperative
languages that make it hard (or impossible) to implement such
functionality yourself.  Unfortunately, it also tends to blind the
users to the limitations of the language ... until they try to do
something the language just won't permit, and then b*tch about needing
"foreign" functions and having to do things in C or assembler.

The "implements" mechanism saves work in SI languages, but it is less
useful in an MI language where any class can simply inherit whatever
functionality it needs.


>DoDi

YMMV,
George

[toc] | [prev] | [next] | [standalone]

#2080 — Re: OOP language design after Algol 60, was Add nested-function support

Am 14.04.2018 um 19:40 schrieb George Neuner:

> The problem is in unrelated classes that need to implement the entire
> interface.  Consider, e.g., serializable, or displayable - in many
> languages you would end up reimplementing the entire interface in
> every branch of your heirarchy, with overrides in virtually every
> subclass.

Please give an example where inheritance from a "serializable" base
class can do something meaningful, without explicitly coded integration
into the derived class.


> The "implements" mechanism saves work in SI languages, but it is less
> useful in an MI language where any class can simply inherit whatever
> functionality it needs.

See above. Fully unrelated functionality does not even deserve a
relationship between both classes, no inheritance at all. Any
dependencies require explicit code, even in MI.

DoDi

[toc] | [prev] | [next] | [standalone]

#2081 — Re: OOP language design after Algol 60, was Add nested-function support

Am 14.04.2018 um 19:40 schrieb George Neuner:
> On Fri, 13 Apr 2018 10:22:03 +0200, Hans-Peter Diettrich

>> An interface can be implemented by a (class type) component of a class.
>> Then only the specific dependencies between both classes have to be
>> implemented explicitly. In Delphi the "implements" keyword implements
>> such object delegation, in addition to method delegation.
>
> But not all languages are so kind.

A strange argument :-(

If a language can do it without MI, what's the remaining benefit of MI?

DoDi

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.compilers

csiph-web