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 3 of 3 — ← Prev page 1 2 [3]

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

George,

>>> Modern popular languages are neither powerful nor easy to learn.
>>
>> What evidence do you have for this?
>
> I disagree about "easy to learn" - there are plenty of languages that
> are easy to learn.  But as to the question of "power" ...

Powerful and easy to learn is a claim that proponents of every language
make.  It is a marketing statement.

If you ask them how their language can be more powerful than other
Turing complete languages, hey invariably switch to saying that it's
easy to write powerful programs (whatever they might be).

Something like 30 languages per year get non-trivial implementations.
So the question to ask is, how does your language compare to the
30 languages created last year?  They invariably have not checked
out last year's languages.  Then ask about comparing against the 30
from the year before, and so on.

Inventing languages is invariably vanity research.  Fine, but let's
not take anything claimed seriously.

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

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

Am 10.04.2018 um 14:15 schrieb Derek M. Jones:

> Something like 30 languages per year get non-trivial implementations.

IMO it's not so much the implementation that distinguishes languages,
instead it's their domain and, with big projects in mind, their design
and debug features (strict typing...).

DoDi

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

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

Hans-Peter,

>> Something like 30 languages per year get non-trivial implementations.
>
> IMO it's not so much the implementation that distinguishes languages,
> instead it's their domain and, with big projects in mind, their design
> and debug features (strict typing...).

I got my data from: http://hopl.info/ (sadly, no longer maintained).
They get their data from published papers.

There are probably hundreds of non-trivial domain specific languages
created every year.  We don't get to hear about them because no paper
is published describing them.

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

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

On 2018-04-09, George Neuner <gneuner2@comcast.net> wrote:
> IMO, the evidence that many popular languages are not "powerful" is
> that they are either exclusively or primarily OO, but they implement
> only single inheritance objects.

I'm surprised that anyone finds multiple inheritance so singularly
important.

Single inheritance is really only crippling if two kinds of objects have
to inherit from a common base in order to be substitutable.

Remove that restriction and inheritance is properly reduced to the mere
code/data reuse hack that it is.

If anything, lack of multiple dispatch probably hurts more than lack
of MI.

> Wherever you stand on OO as a programming paradigm, you can't deny
> that single inheritance is the weakest variant of it.

I can place my standpoint almost anywhere in the OO programming
paradigm, yet not see this. Sorry, George!

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

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

On Tue, 10 Apr 2018 18:32:23 +0000 (UTC), Kaz Kylheku
<157-073-9834@kylheku.com> wrote:

>On 2018-04-09, George Neuner <gneuner2@comcast.net> wrote:
>> IMO, the evidence that many popular languages are not "powerful" is
>> that they are either exclusively or primarily OO, but they implement
>> only single inheritance objects.
>
>I'm surprised that anyone finds multiple inheritance so singularly
>important.
>
>Single inheritance is really only crippling if two kinds of objects have
>to inherit from a common base in order to be substitutable.

That's why SI languages implement interfaces - the poor person's MI.


>If anything, lack of multiple dispatch probably hurts more than lack
>of MI.

I agree that multiple dispatch is at least as important.


>> Wherever you stand on OO as a programming paradigm, you can't deny
>> that single inheritance is the weakest variant of it.
>
>I can place my standpoint almost anywhere in the OO programming
>paradigm, yet not see this. Sorry, George!

You can uncover his eyes, but you can't make him see. <grin>
Sorry Kaz!


George

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

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

On 2018-04-13, George Neuner <gneuner2@comcast.net> wrote:
> On Tue, 10 Apr 2018 18:32:23 +0000 (UTC), Kaz Kylheku
><157-073-9834@kylheku.com> wrote:
>
>>On 2018-04-09, George Neuner <gneuner2@comcast.net> wrote:
>>> IMO, the evidence that many popular languages are not "powerful" is
>>> that they are either exclusively or primarily OO, but they implement
>>> only single inheritance objects.
>>
>>I'm surprised that anyone finds multiple inheritance so singularly
>>important.
>>
>>Single inheritance is really only crippling if two kinds of objects have
>>to inherit from a common base in order to be substitutable.
>
> That's why SI languages implement interfaces - the poor person's MI.

Well, SI in *static* languages!

SI in *dynamic* languages doesn't need interfaces.

I should know; I made one:

  1> (defstruct apple nil (:method rot (me) `@me rots`))
  #<struct-type apple>
  2> (defstruct orange nil (:method rot (me) `@me rots`))
  #<struct-type orange>
  3> (each ((f (list (new apple) (new orange))))
       (prinl f.(rot)))
  "#S(apple) rots"
  "#S(orange) rots"

apple and orange are not related; no "rottable" interface is
needed to legitimize the .(rot) call.

I mean, phooey; over my dead &body.

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

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

In article <18-04-002@comp.compilers>, Martin Ward  <martin@gkc.org.uk> wrote:
>On 30/03/18 15:20, Anton Ertl wrote:
>>> The theory is that "the attitude of the Algol 60 designers towards
>>> language design is what led to these innovations appearing".
>>> Clearly, this "attitude" was present before, during and after
>>> the development of Algol 60.
>> Ok, so this theory cannot even be verified of falsified for the
>> features that came before Algol 60.
>
>John asked us to speculate what might have happened differently,
>not produce empirically verifiable theories :-)
>
>I came across this quote the other day, which suggests that the change
>in attitude had already started by 1979:
>
>"The call-by-name mechanism is so expensive that modern languages
>have mostly dropped it in favour of the semantically different,
>but operationally more efficient, call-by-reference"
>--"Understanding and Writing Compilers", Richard Bornat, Macmillan 1979.

Earlier.
Algol 68 already moved to call by reference.

I paraphrase from page 182 183 Informal introduction to Algol68
(Lindsey / van der Meulen)
"
Algol 60 had something called Jensen's devise, using (or misusing)
call-by-name. In algol 68 we use references only.
"
Then they give an example of how the effect of call-by-name of e.g. a
real can be had by using a procedure that returns a a real.

Basically a call-by-name is a procedure where the input
parameters are  obsured, as viewed from the algol 68 perspective.

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#2017

> and Algol 60 was "not only an improvement on its predecessors, but also
> on nearly all its successors" (C.A.R. Hoare).

> How many modern languages can claim the same?

C. For a while I would have allowed C++ as an exception, but that went away
with cfront. Still not sure about go.
[Your moderator reminds you that he has very little patience for yet more
arguments about why C is a good or a bad language. -John]

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

#1996

Martin Ward <martin@gkc.org.uk> wrote:

> <snip>
> So to answer your hypothetical question: how would programming language
> be different if the designers of Algol 60 had decided to put
> implementation convenience above mathematical simplicity
> and expressive power in the language? Well, perhaps compiler
> research would have stagnated from the beginning and we would not even
> have some of the powerful language features we have now:
> such as first order functions, closures, abstract data types and so on.

Didn't Lisp have first order functions and closures in 58? If I remembe
the discussion of APT in the HOPL I conference proceedings correctly it
surprisingly had the equivalent of structs.

>
> (In case you haven't noticed, I am trying to be provocative,
> and hoping to be proved wrong: especially about the stagnation
> in language design!)

However the other members of the committee were in a better position to
know their own minds than Perlis was, and the the first HOPL conference,
in the discussion of Naur's presentation, some of them claimed to have
understood the implications of call by name from the beginning.

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

#2001

On Mon, Mar 12, 2018 at 8:09 PM, William Clodius <w.clodius@icloud.com> wrote:
> Didn't Lisp have first order functions and closures in 58? If I remember
> the discussion of APT in the HOPL I conference proceedings correctly it
> surprisingly had the equivalent of structs.

Lisp had first-class functions but closures require lexical scope,
which didn't land until Scheme in the '70s.

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

#2004

On 2018-03-13, Kartik Agaram <ak@akkartik.com> wrote:
> On Mon, Mar 12, 2018 at 8:09 PM, William Clodius <w.clodius@icloud.com> wrote:
>> Didn't Lisp have first order functions and closures in 58? If I remember
>> the discussion of APT in the HOPL I conference proceedings correctly it
>> surprisingly had the equivalent of structs.
>
> Lisp had first-class functions but closures require lexical scope,
> which didn't land until Scheme in the '70s.

Anonyous functions without environments are basically just
function pointers.

If those are first class functions, then C has first class functions.

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

#2006

On Tue, Mar 13, 2018 at 5:07 PM, Kaz Kylheku <157-073-9834@kylheku.com> wrote:
> Anonymous functions without environments are basically just
> function pointers.
>
> If those are first class functions, then C has first class functions.

C doesn't have anonymous functions (ignoring a combination of GNU
extensions added sometime after 1988). But you mentioned anonymous
functions, so you must be aware of this. So I'm not sure what you're
saying.

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

#2007

On 2018-03-14, Kartik Agaram <ak@akkartik.com> wrote:
> On Tue, Mar 13, 2018 at 5:07 PM, Kaz Kylheku <157-073-9834@kylheku.com> wrote:
>> Anonymous functions without environments are basically just
>> function pointers.
>>
>> If those are first class functions, then C has first class functions.
>
> C doesn't have anonymous functions (ignoring a combination of GNU
> extensions added sometime after 1988). But you mentioned anonymous
> functions, so you must be aware of this. So I'm not sure what you're
> saying.

That's just a syntactic restriction on where functions are
placed in the program text, due to the lack of a function literal
syntax.

If functions don't require an environment, you can easily add anonymous
function literals with a textual preprocessor like GNU m4, by
implementing a completely trivial "no-environment lambda lifting".

Syntax like:

   some_fun(LAMBDA{int (int a, int b){ return a + b; }})

is simply replaced by

   some_fun(f_0013);

accompanied by the insertion of

   static int f_0013(int arg){ return arg + 1; })

into the global scope. This is easy enough that it's usually not a major
inconvenience to simply do it by hand.  If the C preprocessor were
slightly more powerful, it could handle the above.

Once we obtain a function as a function pointer by evaluating its
name, then it has been anonymized. We can pass it around the program,
store it in variables and structures and so on.  It has the same power
as a lambda-with-no-env.

--
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]

#2002

On 2018-03-13, William Clodius <w.clodius@icloud.com> wrote:
> Martin Ward <martin@gkc.org.uk> wrote:
>
>> <snip>
>> So to answer your hypothetical question: how would programming language
>> be different if the designers of Algol 60 had decided to put
>> implementation convenience above mathematical simplicity
>> and expressive power in the language? ...

> Didn't Lisp have first order functions and closures in 58?

No. It was dynamically scoped: locals were basically saved and restored
globals, so lambda didn't capture any enviornment.

Lambda Calculus (even typed and all) was already known, and the
researchers must have been aware of it, or where else would they
have cribbed "LAMBDA" from, right?

Legend has it that MacCarthy has at some point admitted that he didn't
properly understand Lambda Calculus during the early Lisp work; I don't
have a citation for that.

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

#2005

on 13/03/18 03:09, William Clodius wrote:
> Martin Ward <martin@gkc.org.uk> wrote:
>> So to answer your hypothetical question: how would programming language
>> be different if the designers of Algol 60 had decided to put
>> implementation convenience above mathematical simplicity
>> and expressive power in the language?

	[Ie, had specified call-by-reference rather than call-by-name.]

>>					 Well, perhaps compiler
>> research would have stagnated from the beginning [...].

	Three points:

   (a) IAL ["Algol 58"] specified call-by-textual-replacement.  "The
execution ... is effected as though all formal parameters were replaced,
throughout the procedure, by the actual parameters ....  This replacement
may be considered to be a replacement of every occurrence ... of the
formal parameters by the symbols (or sets of symbols) listed as actual
parameters ...."  [Report, section D9]  It would be surprising if a
decent-sized collection of the best brains of the period didn't realise
that *if* IAL were ever to be implemented, some "interesting" games
could be played.

   (b) However, that's a rather big "if".  In those days when it was
almost impossible to transfer code from machine A to machine B, the
primary purpose of the "algorithmic" languages was not to be the
source of a program, but to express algorithms for translation into
machine code or into some other implemented language by typing it
up onto cards or tape.  So there was little or no point in writing
obscure code in Algol [any version thereof].  OK, Algol compilers
did eventually arrive, though few were both reasonably complete and
reasonably efficient.

   (c) I agree that the difficulties of compiling IAL, A60 and A68
stimulated research into compilation techniques.  But that may well
have been the cause of the virtual demise of Algol, upstaged by
languages that were easier to write compilers for [but harder to
write programs *in*].

> However the other members of the committee were in a better position to
> know their own minds than Perlis was, and the the first HOPL conference,
> in the discussion of Naur's presentation, some of them claimed to have
> understood the implications of call by name from the beginning.

	It seems to have been a left-pondian vs right-pondian thing.
As a very crude over-generalisation, one side simply wanted to get
work done, and the other side was much more interested in the limits
of what could be done.  Plenty of exceptions both ways, esp by the
late 1970s.

--
Andy Walker,
Nottingham.
[How close did anyone get to implementing Algol 58?  I know about JOVIAL
but I believe it was pretty far from full IAL. -John]

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

#2008

On 14/03/18 00:27, our moderator wrote:
> [How close did anyone get to implementing Algol 58?  I know about JOVIAL
> but I believe it was pretty far from full IAL. -John]

	AFAIK, no closer than Jovial.  In a sense, there never was a full
IAL;  the report was "preliminary", everyone was waiting for the proper
language, and once Algol 60 came out, they lost interest.

--
Andy Walker,
Nottingham.

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

#2009

Martin Ward <martin@gkc.org.uk> writes:
>On 06/03/18 19:02, john wrote:
>> Hypothetical question: Algol60 call by name was a mistake.  They
>> intended an elegant definition of call by reference and didn't realize
>> until Jensen's device what they'd done.  If they'd done what they
>> intended and we didn't have to invent thunks, how would programming
>> languages be different? -John
>
>Lets go along with the theory that they intended call by reference
>and did not realise that what they had was different until
>Jenson's device was invented.  What happened next (hypothetically!)
>was that the language designers realised two things:
>
>(1) Call by name is mathematically, semantically, simpler
>than call by reference
>
>(2) Call by reference is much easier to implement than call by name.
>Call by name requires significant effort to implement.
>
>The designers decided to go with call by name because it produces
>a mathematically simpler language, even at the expense of greater
>effort to implement the compiler.

Looking at the story of recursion in Algol 60
<https://vanemden.wordpress.com/2014/06/18/how-recursion-got-into-programming-a-comedy-of-errors-3/>,
there was a more mathematical camp in the Algol 60 committee, and a
more implementation-oriented camp.  The mathematicians knew how to
specify what they wanted, the implementors know how to implement what
they wanted.  But since the product of the committee was a
specification, they would also have to know how to specify what they
wanted if they wanted to get it into the report.  I guess that they
did not know how to specify call by reference, so the mathematical way
won in this case, as it did for recursion.

History shows that, for recursion, they took the right decision, while
for parameter passing, they didn't.

>The result was an explosion of productive research and development
>in compilers and language implementation.

Is it really productive to research and develop a feature that turns
out to be a dead end?  Even the closest thing to call-by-name these
days, call-by-need in lazy functional languages, does not use the
techniques developed by call-by-name.

>Since that time, language designers have become very cautious and timid
>in specifying powerful new language features and compiler research
>has stagnated.

The pace in language design certainly has slowed down a lot since the
early days, but I take this as a sign that the field is maturing: Now
that we have a lot of usable and not-too-horrible programming
languages, it becomes harder to produce something that is better.  And
in particular, it is harder to produce something that is better to a
sufficient degree to overcome the various forces that resist such a
change.

Concerning the stagnation in compiler research, that certainly is not
reflected in the numbers of papers submitted and published at compiler
conferences.

>An extreme example is the C language reference
>which merely codifies the intersection of the behaviour of the major
>C compilers, and leaves everything else "undefined".

That is the way to go for a standard that codifies existing practice.
However, it is not ok for compiler maintainers to then take the view
that only programs in that intersection (an almost empty set) need to
be compiled as intended.

>So to answer your hypothetical question: how would programming language
>be different if the designers of Algol 60 had decided to put
>implementation convenience above mathematical simplicity
>and expressive power in the language?

If they had specified call-by-reference and call-by-value, similar to
Pascal?  Programming languages would not be any different.

If they had specified non-recursion?  Recursion may have taken longer
to take hold in mainstream languages.  However, recursion was already
there in Lisp, so it's not as if we needed Algol 60 for that.

In general, while language designers have stood on the shoulders of
their predecessors, I don't have the impression that they let
themselves be limited by limitations of previous languages; such
limitations served more as a motivation for improving things.  Take
Landin's influtential paper "The next 700 programming languages" as an
example.

>Well, perhaps compiler
>research would have stagnated from the beginning and we would not even
>have some of the powerful language features we have now:
>such as first order functions, closures, abstract data types and so on.

Algol 60 did not have first-order functions and closures.  It did have
lexical scoping, though, which the Lisp family only acquired with
Scheme in 1975.

Algol 60 certainly did not have abstract data types.  It did not even
have records.

So these are examples that actually contradict your theory.

- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

[toc] | [prev] | [standalone]

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

Back to top | Article view | comp.compilers

csiph-web