Re: do { quit; } else { }

On 07/04/2025 20:31, bart wrote:

On 07/04/2025 19:02, Michael S wrote:

On Mon, 07 Apr 2025 05:45:19 -0700

Of course, proposals for similar feature in other procedural/imperative
language would not be totally different. Pascal is more similar to C
than many other procedural languages, so solution for Pascal would
likely be more similar to C than for example, stackless co-routines
that already exist in such languages like C# (that started current wave
of popularity of the feature) or Python.
However Pascal and C have enough not in common for significant
difference in proposed syntax and implementation. Specifically, in
Pascal:
- heap management is built-n in the language
- non-local goto is built-n in the language

 That's news to me. But then I only used an educational version.
 

- nested procedures
- everything related to separated compilation of the translation units
is handwaved in the docs rather than strictly specified.

 I don't think it's that strictly specified in C. Isn't it vaguely left to the implementation?
 

No.

Much of how different units share macros, types, structs and enums isn't part of the language at all AFAICS: it's just a by-product of different modules happening to include the same header files.
 

Linkage is explained in 6.2.2 - only identifiers with external linkage are shared amongst translation units.  Macros, types, enums are all have no linkage and are therefore never shared.
The only way to make new non-standard types in C is with "struct", "union" or "enum".  Section 6.2.7 of the standard sets out simply and clearly what is required for two types in different translation units to be compatible.  (It doesn't make sense to say they are the "same type" in C lingo, since types have no linkage, but compatibility is the important point.)
Sharing a definition in a header file is normally the easiest way to ensure that the types used in different translation files are compatible, but it is not required.

But it could also be done by repeating declarations in each module; it's rather ad hoc.

It is not remotely "ad hoc" - as far as the language is concerned, including a header file /is/ repeating the declaration in the different translation units.  The way C handles this kind of thing is arguably weaker than in languages that have proper modules (like Ada, or Modula 2), and much more open to mistakes.  On the other hand, it is very flexible and simple to understand, and does not need additional specialised object files or "interface" files.  It is possible to write C code in an "ad hoc" manner (such as declaring an "extern" identifier within a C file rather than a header file), but the language definition is not "ad hoc".

 The Pascal I used only worked with one module; more recent versions do seem to have formal interfaces which are part of the language. So it is more rigorous than C.
 

Yes, most Pascal versions suitable for real development (rather than the older teaching versions) have more formal interfaces.  Personally, I prefer more formal interfaces - more formality and stronger typing reduce flexibility but also reduce the risk of some kinds of errors, and can make a language more amenable to analysis.

 

May be it's
not so in Extended Pascal standard, I never read it.
>
Most importantly, Pascal in its hay days had different (from C)
attitude with regard to standardization. Implementors, especially
bigger ones, freely made very significant mutually incompatible
extensions and nobody in community was upset about it. C way is more
centralized.

 I have a feeling that there were WAY more variations of C than Pascal, largely because C was more popular and more widespread.
 

I suspect you are wrong here.  There are certainly far more C compilers than Pascal compilers, and there are minor variations between the C compilers, but even prior to K&R's book the differences between C compilers was smaller than between the different Pascal versions. Pascal was standardised, but standard Pascal was too limited for most commercial use and different vendors build on it - with Borland's line being the most relevant.  Comparing modern Delphi and standard Pascal is a bit like comparing C# with K&R C.

You still see this know when you delve into systems and applications headers which are often a mess of '#ifdef' blocks which special-case specific compiler versions which all have different characteristics.
 

Certainly there are variations in the details - in particular, there are lots of things in C (and Pascal) that are "implementation defined".
It is the similarity between C compilers that means that often all you need is some #ifdef's for low-level or library code shared between C compilers on significantly different systems or targets.  If you want to write a low-level library for Free Pascal, Delphi, GNU Pascal, and Pascal-P, you write four versions of it.