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

Groups > comp.compilers > #2048 > unrolled thread

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

Back to article view | Back to comp.compilers

Contents

  Re: language design after Algol 60, was Add nested-function support Martin Ward <martin@gkc.org.uk> - 2018-04-10 16:11 +0100
    Re: language design after Algol 60, was Add nested-function support "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2018-04-10 16:56 +0100
    Re: language design after Algol 60, was Add nested-function support anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-04-10 16:04 +0000
      Re: language design after Algol 60, was Add nested-function support "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2018-04-10 23:14 +0100
        Re: language design after Algol 60, was Add nested-function support Martin Ward <martin@gkc.org.uk> - 2018-04-13 13:55 +0100
    Re: language design after Algol 60, was Add nested-function support Gene Wirchenko <genew@telus.net> - 2018-04-10 11:04 -0700
    Re: language design after Algol 60, was Add nested-function support Kaz Kylheku <157-073-9834@kylheku.com> - 2018-04-10 18:38 +0000

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

On 08/04/18 14:21, Derek M. Jones wrote:
>> Modern popular languages are neither powerful nor easy to learn.
>
> What evidence do you have for this?

The C standard is over 700 pages: not exactly an easy read.  C has 199
different cases of undefined behaviour that the programmer has to
memorise and avoid using if they want to write conformant and
compatible code.

C++ is even more popular than C but adds layers more complexity
on top of the complexity of C: "If you think C++ is not overly
complicated, just what is a protected abstract virtual base pure
virtual private destructor, and when was the last time you needed one?"
(Tom Cargill, C++ Journal, Fall 1990).

An iostream-based "hello, world" program requires the GNU C++ compiler
to parse 718K bytes.

See also: http://yosefk.com/c++fqa/defective.html

Yet, for all that complexity, "C combines the power of assembly language
with the flexibility of assembley language"!  To do anything useful
in C or C++ one needs to use large numbers of functions from
various libraries. The GNU C library, which contains basic low-level
functions such as string handling, I/O, memory allocation etc,
has a manual which is 1,174 pages long.

On the other hand, the Revised^4 Report on the Algorithmic Language
Scheme ("Dedicated to the Memory of ALGOL 60") is only a 55 page manual
but it includes the full syntax and semantics of the language.

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

[In fairness, a lot of the 700 pages of the C standard are about
the library.  In my copy of C99, pages 9-163 are about the
language, pages 164-401 are about the library, and then there's
about 150 pages of appendices.  But it's certainly a lot bigger
than the language that K&R wrote about in the 1970s. -John]

[toc] | [next] | [standalone]

#2049

Martin,

> On 08/04/18 14:21, Derek M. Jones wrote:
>>> Modern popular languages are neither powerful nor easy to learn.
>>
>> What evidence do you have for this?
>
> The C standard is over 700 pages: not exactly an easy read.

By evidence I mean an evaluation of multiple languages.

Here are some languages from 1957.  Were they powerful and easy
to learn?

http://shape-of-code.coding-guidelines.com/2017/05/21/evidence-for-28-possible-compilers-in-1957/

....> memorise and avoid using if they want to write conformant and
> compatible code.

I thought we were talking about powerful and easy to learn?

> On the other hand, the Revised^4 Report on the Algorithmic Language
> Scheme ("Dedicated to the Memory of ALGOL 60") is only a 55 page manual
> but it includes the full syntax and semantics of the language.

My question was about powerful and easy to learn.  Not about number
of pages in the language specification.
[In my experience, any language that is semantically similar to
languages you already know is easy to learn.  For example, I find
python comprehensions obvious and easy to use because they're just a
syntax for a function mapping.  I know other python programmers who
find them baffling and always write "for" loops instead, presumably
because the languages they'd used didn't do much function mapping.
-John]

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

#2050

Martin Ward <martin@gkc.org.uk> writes:
>Yet, for all that complexity, "C combines the power of assembly language
>with the flexibility of assembley language"!

I wish!  The C standard allows that, but does not guarantee it, so
providing that power and flexibility is a quality-of-implementation
issue.  And unfortunately, at least the gcc and LLVM maintainers do
not want to provide this quality.  A manifesto of this position is

http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

my counter-position papers are:

http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf
http://www.kps2017.uni-jena.de/proceedings/kps2017_submission_5.pdf

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

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

#2056

Anton,

> my counter-position papers are:
>
> http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf
> http://www.kps2017.uni-jena.de/proceedings/kps2017_submission_5.pdf

and another position (which offers solutions):
http://shape-of-code.coding-guidelines.com/2014/08/31/undefined-behavior-pay-up-for-shut-up/

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

#2074

Anton wrote:
> my counter-position papers are:
>
> http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_2015_submission_29.pdf
>
> http://www.kps2017.uni-jena.de/proceedings/kps2017_submission_5.pdf

Quote: "if the totally-defined C specified that shifting by the data
width produces 0, the compiler would have to implement shifts more
expensively on some machines; and if it specified that it produces the
unshifted value, it would have to implement shifts more expensively on
other machines."

This is a perfect example of support for my thesis.  I am not happy
about this, since I was (and still am) hoping that my thesis would be
disproved :-(

To recap the thesis:

The Algol 60 designers placed mathematical simplicity (simplicity in
the language, ease of analysis etc) above the effort to implement the
compiler and execution efficiency of compiled code.

This attitude led to an explosion of productive research and
development in compilers and language implementation.

Since that time, language designers have become very cautious and
timid in specifying powerful new language features and compiler
research has stagnated (with C as an extreme example of this
stagnation).

Not specifying the result of a shift because the implementation is
inefficient on some machines is an extreme example of timidity.
(Mathematically, shifting by 2N bits should be semantically equivalent
to shifting by N bits twice, regardless of the value of N!)

Back in the good old days, language designers developed powerful
languages regardless of implementation efficiency, and hardware
designers responded by developing hardware to implement these powerful
languages more efficiently (hardware stacks, lisp machines,
content-addressable memory and so on).

The post by Hans-Peter Diettrich on Unum numbers is a small
encouraging sign.

--
			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
[I think you'll find that don't specify in ways that might be hard to
compile goes all the way back to Fortran.  Its standards allowed
optimizations like strength reduction if they were mathematically
equivalent to the original code, even if they weren't computationally
equivalent. -John]

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

#2051

On Tue, 10 Apr 2018 16:11:29 +0100, Martin Ward <martin@gkc.org.uk>
wrote:

[some neat stuff which Our Esteemed Moderator comments on]

>[In fairness, a lot of the 700 pages of the C standard are about
>the library.  In my copy of C99, pages 9-163 are about the
>language, pages 164-401 are about the library, and then there's
>about 150 pages of appendices.  But it's certainly a lot bigger
>than the language that K&R wrote about in the 1970s. -John]

     I propose Gene's Language Heuristic:

  1) Take the specification for the language and print a hardcover
book of it.  (Apply reasonable rules for font size, etc.)

  2) Pick up the book.

  3) If you are unable to do so, call dispose.

  4) Whack the language creator hard on the head with the hardcover
book.

  5) Did you kill him?

  6) If yes, call dispose.

  7) Did you incapacitate him?

  8) If yes, hope really hard that he gives up his antisocial
practices of language creation.  End of heuristic.

  9) Seek treatment for shock.

 10) Warily, learn the language.  End of heuristic.


procedure dispose

     Dispose of the book, the language, and the language creator.
(Exactly how is not defined by this heuristic.  If you have had to do
this before, consider reusing that method.)


     There are too many languages that are too similar.

Sincerely,

Gene Wirchenko

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

#2055

On 2018-04-10, Martin Ward <martin@gkc.org.uk> wrote:
> Yet, for all that complexity, "C combines the power of assembly language
> with the flexibility of assembley language"!

Not so; C provides no portable way to inspect the stack or machine
registers. Writing a precisely-tracing garbage collector which can
look for root pointers in the stack is possible in assembly language;
only a conservative approach is feasible in anything remotely resembling
portable C.

Assembly languages are predictable; for instance, they have defined
behaviors on integer overflow.

Decent quality instruction sets architectures provide ways to catch
an exception in a handler which can precisely re-start the program from
the faulting point after doing some fixup. Almost anything can be
treated in a way that assures safety: illegal instruction, division by zero.

In assembly languages, a pointer value held in a register doesn't become
"indeterminate" just because it was passed to some free()-like function.
(And other such nonsense fictions.)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compilers

csiph-web