|Which comes first, languages or compilers? email@example.com (gah4) (2023-10-25)|
|Re: Which comes first, languages or compilers? firstname.lastname@example.org (Kaz Kylheku) (2023-10-26)|
|Re: Which comes first, languages or compilers? email@example.com (minf...@arcor.de) (2023-10-27)|
|Re: Which comes first, languages or compilers? firstname.lastname@example.org (Luke A. Guest) (2023-10-27)|
|Re: Which comes first, languages or compilers? DrDiettrich1@netscape.net (Hans-Peter Diettrich) (2023-10-30)|
|Re: Which comes first, languages or compilers? OrangeFish9737@invalid.invalid (OrangeFish9737) (2023-10-30)|
|Re: Which comes first, languages or compilers? email@example.com (Luke A. Guest) (2023-10-30)|
|Re: Which comes first, languages or compilers? firstname.lastname@example.org (Thomas Koenig) (2023-11-02)|
|From:||Thomas Koenig <email@example.com>|
|Date:||Thu, 02 Nov 2023 07:20:18 -0000|
|References:||23-10-008 23-10-011 23-10-012 23-10-014|
|Injection-Info:||gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="69091"; mail-complaints-to="firstname.lastname@example.org"|
|Keywords:||syntax, design, C, comment|
|Posted-Date:||02 Nov 2023 12:59:32 EDT|
Luke A. Guest <email@example.com> schrieb:
> On 30/10/2023 03:26, Hans-Peter Diettrich wrote:
>> On 10/27/23 5:57 PM, Luke A. Guest wrote:
>>> I don't really consider any of Wirth's languages to be designed as
>>> they would not have the gaping big holes they have.
>> The *languages* are all well designed,
> That's not what the Oakwood guidelines say.
What do they say?
> system *libraries* are incomplete
>> or missing.
There is actually a problem with language design - how to handle I/O.
Kernighan discusses briefly this in "UNIX: A History and a Memoir".
You can make I/O part of the language, as FORTRAN first did with
FORMAT (which was an excellent idea). You can leave it unspecified
(which has been shown to be a bad idea). Or you can leave it to
libraries, like C or Modula-2 do.
If you leave it to libraries, the question is how to make up complex
format strings. You can use C's varargs, which make for easy use (but
somewhat difficult error checking), or you can use the Modula-2
approach where each type has its own library function, which makes I/O
a pain to use.
And varargs certainly has issues for compilers, especially in ABI
definition when arguments are usually passed in registers. Lenient
ABIs which allow you to call a normal functions with a varargs
argument list without crashing are certainly a source of errors, even
> [I'd prefer not to refight 30 year old arguments about language design details here.
> At this point Oberon is purely of historical interest and Pascal is close to dead. -John]
A Pascal descendant, Delphi, is still being sold.
And Modula-2 has just gained a gcc front end, so not all of Wirth's
languages are dead.
[The line between language I/O and library I/O is quite blurry. The C
standard makes includes the stdio library as a mandatory part of the
language so compilers often do static compatibility checks of printf
strings and arguments at compile time. Sure, you can build the format
at runtime but it's almost always a static string. And, Fortran lets
you build the FORMAT statement in a runtime string, too. -John]
Return to the
Search the comp.compilers archives again.