Re: [fpc-devel] Minor debate with ISO standard on case blocks

On Wed, 31 Jul 2019 01:26:23 +0200 Martok wrote: > Of course, if you wanted a run-time error you would need to insert a run-time > check, and 'some people' seemed to be hell-bent on saving these 2 cycles at > any > cost. > > The patch to switch from option a1) to a2) would be straightforward, f

Re: [fpc-devel] Minor debate with ISO standard on case blocks

If you want something a bit more clear, try ISO/IEC 10206 (Extended Pascal). They split up errors and dynamic violations, which helps make the point clearer. Basically, a "Processor" is sort of an interpreter that first validates the complete program and then activates the program block, "executio

Re: [fpc-devel] Minor debate with ISO standard on case blocks

thaddy schrieb am Di., 30. Juli 2019, 10:04: > On 2019-07-30 01:43, J. Gareth Moreton wrote: > > As someone on the issue pointed out... on page 2, section 3.1: > > > > 3.1 Error > > > I have added this to the bug report. Consider that here all possible > case labels are implemented, the compiler

Re: [fpc-devel] Minor debate with ISO standard on case blocks

Actually I prefer a compiler error/warning on such cases - so being able to write an exhaustive case is a very good option over eventually getting runtime errors - oh, yeah we all have exhaustive unit tests don't we? ;) TypeScript for example has the never type which can be used to write a comp

Re: [fpc-devel] Minor debate with ISO standard on case blocks

This message thread has been interesting to read. I just realized today that I dealt with similar issues in Delphi 19 years ago. This is discussed in the good Microsoft Press book *Code Complete* by Steve McConnell. Using the default else block of a case statement to show a program error mes

Re: [fpc-devel] Minor debate with ISO standard on case blocks

On Tue, 30 Jul 2019 06:38:56 +0200 thaddy wrote: > According to what I found there is no smoking gun: I could not find any > implementation or reference from any reputable source that implements > the case statement in the way that is implemented in trunk: compile time > error when not all of

Re: [fpc-devel] Minor debate with ISO standard on case blocks

On Tue, 30 Jul 2019, Martin Frb wrote: How you're suppsed to construct a working & compliant 'processor' (I assume this means compiler or interpreter or somesuch) after reading this is a mystery to me. Well if we make the following substitutions (to specialize the statement for the case of

Re: [fpc-devel] Minor debate with ISO standard on case blocks

On 30/07/2019 10:29, Michael Van Canneyt wrote: On Tue, 30 Jul 2019, thaddy wrote: Telling. NOTES 1. If it is possible to construct a program in which the violation or non-violation of this International Standard requires knowledge of the data read by the program or the implementation defi

Re: [fpc-devel] Minor debate with ISO standard on case blocks

Yeah, I don't find that description clear either.  One shouldn't have to be a lawyer in order to decrypt such standards! Of course, FPC can follow its own standard, but it should be one that everyone agrees on.  While I think we shouldn't live in the shadow of Delphi or be jammed in the realm

Re: [fpc-devel] Minor debate with ISO standard on case blocks

On Tue, 30 Jul 2019, thaddy wrote: Telling. NOTES 1. If it is possible to construct a program in which the violation or non-violation of this International Standard requires knowledge of the data read by the program or the implementation definition of implementation-defined features, then v

Re: [fpc-devel] Minor debate with ISO standard on case blocks

On Mon, 29 Jul 2019, J. Gareth Moreton wrote: Hi everyone, So there's been an issue raised in regards to ISO compliance with case blocks (when under $mode iso).  Currently, a compiler error is raised if a case block does not have exhaustive c

Re: [fpc-devel] Evaluation order in expressions

On 30.07.2019 09:46, Michael Van Canneyt wrote: I think they updated the documentation meanwhile: http://docwiki.embarcadero.com/RADStudio/Rio/en/Procedures_and_Functions_(Delphi)#Calling_Conventions So you can see it depends on the calling convention. Thanks, I wasn't aware of it! Ondrej

Re: [fpc-devel] Minor debate with ISO standard on case blocks

On 2019-07-30 01:43, J. Gareth Moreton wrote: As someone on the issue pointed out... on page 2, section 3.1: 3.1 Error I have added this to the bug report. Consider that here all possible case labels are implemented, the compiler still throws a compile time error. That means the implementa

Re: [fpc-devel] Minor debate with ISO standard on case blocks

Telling. I took the trouble to look up the case statement in a random selection of about 30 instruction manuals, books and magazines about Pascal from my personal library (only a few pretend to be ISO compliant or mention the standard, though. These beasts are rare) and some compilers. I can n

Re: [fpc-devel] Evaluation order in expressions

On Tue, 30 Jul 2019, Ondrej Pokorny wrote: On 30.07.2019 08:55, Jonas Maebe wrote: Delphi evaluates e.g. all parameters to subroutine calls from left to right, which FPC does not guarantee. If I am not mistaken Delphi doesn't guarantee this either. I remember I "learned it by doing" quite

Re: [fpc-devel] Evaluation order in expressions

On 30.07.2019 08:55, Jonas Maebe wrote: Delphi evaluates e.g. all parameters to subroutine calls from left to right, which FPC does not guarantee. If I am not mistaken Delphi doesn't guarantee this either. I remember I "learned it by doing" quite some time ago and I don't think I used FPC at

Re: [fpc-devel] Evaluation order in expressions

On 2019-07-30 08:23, Ondrej Pokorny wrote: can somebody comment on the Remark from https://www.freepascal.org/docs-html/ref/refch12.html ? _Remark: The order in which expressions of the same precedence are evaluated is not guaranteed to be left-to-right._ Is this valid for boolean expressions