FPC Unleashed (inline vars, statement expr, tuples, match, indexed/lazy labels)

[440bx]

The compiler is being told it's a DWORD, that's a fact, not my opinion. 

[LeP]

@440bx
This is off-topic: why do you persist in believing something that's unnatural in the language and for the compiler?
Casting from a string (I'm talking about casts...) to an integer (or dword, or... any other form of "number") is absurd.
And then? The code you develop will remain unique for your own use; you certainly won't be able to share it, and it probably won't be usable for other versions of Pascal.
At that point, you might as well write a function to do this "thing" as you wish, without bothering the compiler (also because I'm sure tomorrow morning someone will be asked to do the same thing for 6 characters, for 8, and perhaps encoded in UTF-32).
Those request, like others that I saw, are legit of course but I think that if there will be too much version of compiler (all incompatible each other) there will be some big issues.

Take only care about maintenance: every addon require that someone will do maintenance and test in every future version of compiler ...

[creaothceann]

As far as I know it should be possible to drop the DWord requirement. C only cares about the size of data, so FourCCs can be declared as array[0..3] of AnsiChar, and constants can be easily declared with that.

[440bx]

Casting from a string (I'm talking about casts...) to an integer (or dword, or... any other form of "number") is absurd.

There is absolutely nothing absurd about it, any byte, again byte can be interpreted as a character, a number, a bit mask, you name it.   capisce ??  The compiler is being _explicitly_ told to interpret a sequence of 4 characters as a 4 byte DWORD.  It's that simple, really, really, really simple, as simple as 0 + 0, it really shouldn't be difficult to understand.

As far as I know it should be possible to drop the DWord requirement. C only cares about the size of data, so FourCCs can be declared as array[0..3] of AnsiChar, and constants can be easily declared with that.

That cannot be done in Delphi variants of Pascal because a typed constant reserves storage and the purpose of the definition is to create a _compiler_ constant, not a read only value somewhere in the binary.

The compiler is failing to do what it is explicitly being told to do, which is, create a 4 byte (DWORD) compiler constant out of the bytes represented as 'abcd' for the programmer's convenience (after all, high level programming languages exist to make life more convenient for programmers, beats flipping switches.)



This is the kind of stuff that justifies using C in spite of its being such a syntactic design disgrace.

[Thaddy]

@440bx

If it is typed it needs storage. At least in .rodata, static requires .data or similar.

All other compilers do the same. That is simply because it needs a reference, it can't be kept in a register. This is basic compiler construction.

[440bx]

@440bx

If it is typed it needs storage. At least in .rodata, static requires .data or similar.

All other compilers do the same. That is simply because it needs a reference, it can't be kept in a register. This is basic compiler construction.

Yes, basic compiler construction... let's see if you can reach that level, in the code:

Code: Pascal  [Select][+][-]

1. const
2.   ACONSTANT = DWORD('abdc');
3.  

I'll help you a little... since there is no type (unless you've smoked a gallon of red paint recently and see storage allocaion in that statement), therefore there should not be any storage involved.  The compiler should be able to evaluate DWORD('abcd') at compile time and associate the resulting value with the identifier ACONSTANT.  As you so accurately pointed out, _basic_, really, really, _basic_ compiler construction (something which you obviously know _absolutely_ nothing about.)

For the record, a correctly implemented compiler could easily figure out the constant value that is represented by DWORD('abcd') (C and C++ do it without breaking a sweat) and that constant value could be assigned to a variable.   Either way, in a correctly implemented compiler, DWORD('abcd') should NOT cause the compiler to reserve storage. 


Also, this discussion is _not_ off topic because @Fibonacci has expressed interest in implementing it for const and var section, therefore it is important to make it crystal clear that DWORD('abcd') is a compiler constant and that NO storage should be reserved for it since, again, it is a compiler constant, it's a 4 byte DWORD constant, nothing else.

[creaothceann]

Perhaps this could at least be worked around if Free Pascal had a proper macro system, or comptime.

Speaking of things that shouldn't be included in binaries: subroutines that are always inlined...

[marcov]

Speaking of things that shouldn't be included in binaries: subroutines that are always inlined...

Removal of unreferenced sections is a combination of compiler and linker issue.  The works of FPC are similar to gcc, which should not be surprising as they started with the same binutils.

There is a parameter -CX for wrapping symbols in sections (gcc:  -ffunction-sections  -fdata-sections. ), and there is a parameter for the final link -XX  (gcc:  -Wl,--gc-sections  )

So it is roughly the same, just the parameters are shorter. On Windows, afaik the release fpc.cfg contains them. On Linux it might depend on where you got your FPC (distro or somewhere else)

[creaothceann]

I added -CX and -XX to the compiler flags in Compiler Explorer; the Random function still appears in the output.

[Thaddy]

@440bx

You can't solve hardcasts. It is YOU that overrides the type system before it kicks in.

[440bx]

@440bx

You can't solve hardcasts. It is YOU that overrides the type system before it kicks in.

Here is the refutation to your latest meaningless word salad:

Code: Pascal  [Select][+][-]

1. const
2.   ACONST = byte('a');
3.  

Guess what ?... that's exactly the same as "const ACONSTD = DWORD('abcd');" no difference.  The problem is FPC seems to get "confused" when there is more than one character.  For instance, it won't accept: "const ACONSTW = word('ab');" either.  C and C++ compilers figure it out effortlessly.

FPC can do the obvious, the single character case because that one it won't turn it into (or mistakenly believe it is) a string.  It can only handle single character constants... a little "improvement" is needed in that area.

Anyway, it seems to be able to resolve "hardcasts" (whatever that means) as long as it is applied to a single character.  Reminds me of Henry Ford, any constant you want as long as it's a single character/byte.  Very convenient.

Anyway, it really is truly very basic for a compiler to be able to interpret values as specified by the programmer.  That's what it's supposed to do.

[Martin_fr]

@440bx

You can't solve hardcasts. It is YOU that overrides the type system before it kicks in.

Here is the refutation to your latest meaningless word salad:

Code: Pascal  [Select][+][-]

1. const
2.   ACONST = byte('a');
3.  

Guess what ?... that's exactly the same as "const ACONSTD = DWORD('abcd');" no difference.  The problem is FPC seems to get "confused" when there is more than one character.  For instance, it won't accept: "const ACONSTW = word('ab');" either.  C and C++ compilers figure it out effortlessly.

While I don't really care for the result (I don't use unleashed), your comparisons lacks.

That is they are not the same, at least not from every angle/view. And so depending on what angle the decision was made on, the comparison above is not applicable. Instead of implying they are the same, you would have to argue for they should be compared by some means in which they might be seen as the same.

Currently the decision appears to  me made on
- char is ordinal -> ordinal can be cast.
- string is not ordinal -> can not be cast.

If you don't want that as base for the decision. well.... but then your argument should be to change that base.

Maybe you meant to argue that, but then you certainly left out a lot of clarity on that intend.

Code: Pascal  [Select][+][-]

1. const   ACONST = byte('a');

versus

Code: Pascal  [Select][+][-]

1. const   ACONST = byte('a'+'');

[440bx]

- string is not ordinal -> can not be cast.

Is the fact that a sequence of 4 characters is NOT always a Pascal string that hard to understand ????????

n bytes, as in any number of bytes, can be interpreted in quite a few ways.  4 bytes, no matter how they appear in the source code, can be interpreted as ANY entity that uses 4 bytes, such as a DWORD.  The fact that the value is being specified with characters instead of digits is irrelevant.  if it were relevant we couldn't represent hex numbers because A thru F are characters and because of that $abcdef couldn't be a number, it would have to be a string of 6 characters.  Fortunately, the compiler is smart enough to interpret those characters as numbers when they are preceded by a "$" sign.  In "const CONSTD = DWORD('abcd');" the compiler is being explicitly told to interpret 'abcd' as the 4 byte sequence in a DWORD because the 'abcd' is cast as a DWORD... hey compiler... those 4 bytes there... those are the 4 bytes that make up a DWORD... capisce ?? (unfortunately the compiler not capisce and... many Pascal users not capisce either!)

Also unfortunate is that explaining the obvious again will not change the result.  Because of that, I'm going to openly patronize those who refuse to understand the obvious by declaring you are all absolutely right, yes, you are all absolutely right.   It still won't change the result but, hopefully, I won't have to read any more preposterous non sense.

in DWORD('abcd'), 'abcd' is not a string, it's just a sequence of 4 characters, that's all it is.  Just like 'a' isn't a string, it's a sequence of 1 character, that's it, that's all it is.  and guess what... a sequence of 4 characters is a sequence of 4 bytes and a sequence of 4 bytes also goes by the name of DWORD which, amazingly, happens to be an ordinal type (at least in 32 bit.)

What's next ??? 111111 is a string too ?  should DWORD(1111) store the 1111 somewhere thus making it invalid as a constant value ??? The arguments being presented are literally absurd and preposterous. 

Again and again, the compiler is being explicitly told to interpret the 4 characters 'abcd' as a DWORD.  It's that simple and, the compiler fails miserably at this absolutely trivial task.  Worst part, FPC users defend this absurdity.  No wonder this is the language of writable constants.

[ccrause]

- string is not ordinal -> can not be cast.

Is the fact that a sequence of 4 characters is NOT always a Pascal string that hard to understand ????????

According to Pascal syntax rules: A character string (or string for short) is a sequence of zero or more characters (byte sized), enclosed in single quotes.  The interpretation of a single character literal as a character type and not a string with a length of one is inconsistent with the formal definition, perhaps the definition should be amended to clarify the special case of a single character literal.  Once a string literal is parsed it is interpreted as a string, therefore string type casting rules apply as others have already mentioned.

Code: [Select]

  b := TMYINTEGER('abcd');    { ok, 4 characters -> size 4 -> same size as TMYINTEGER }

The C equivalent of my interpretation of the above pseudocode example:

Code: C  [Select][+][-]

1. int n = 'abcd';

In C 'abcd' is called a multi-character constant, which is different from a string literal (e.g. "abcd").  This "feature" is implementation defined, so not generally useful if you want to write portable code. Reference

[Martin_fr]

- string is not ordinal -> can not be cast.

Is the fact that a sequence of 4 characters is NOT always a Pascal string that hard to understand ????????

According to Pascal syntax rules: A character string (or string for short) is a sequence of zero or more characters (byte sized), enclosed in single quotes.

I tried to help him (*), by pointing out he wants to rather argue for a change of casting rules, than a change of interpretation.... But alas, I got a scolding answer for that...

(*) I don't support it, not for Pascal, but since we now have a new language called "unleashed"... not a problem for me.