On Mon, 3 Mar 2014 18:02:35 +0100, Jonas Maebe jonas.ma...@elis.ugent.be
wrote:
On 03 Mar 2014, at 17:43, Ewald wrote:
Alright, that I did not know. Thanks for the info. I always assumed
there was an instruction FULD, but it isn't there apparently.
Nevertheless, Hans-Peter's statement is
On 03 Mar 2014, at 21:44, Hans-Peter Diettrich wrote:
Ewald schrieb:
On 03 Mar 2014, at 12:49, Hans-Peter Diettrich wrote:
How (which data type) does *your* parser store untyped numerical
constants?
Roughly like this (syntax may be a bit awry, but you get the point):
TIntegerNumber =
Ewald schrieb:
On 03 Mar 2014, at 00:29, Hans-Peter Diettrich wrote:
`-1` would then be $1 , whereas $
would be $0 . It really is quite
easy to store it like that and `fix` things [picking a fitting
datatype] afterwards.
The datatype
On 03 Mar 2014, at 12:49, Hans-Peter Diettrich wrote:
Ewald schrieb:
On 03 Mar 2014, at 00:29, Hans-Peter Diettrich wrote:
`-1` would then be $1 , whereas $
would be $0 . It really is quite
easy to store it like that and `fix`
On 03 Mar 2014, at 17:43, Ewald wrote:
On 03 Mar 2014, at 12:49, Hans-Peter Diettrich wrote:
What you observed was related to the argument passed to WriteLn. When
WriteLn includes code to output a QWord, then the output should reflect the
bitpattern (unsigned number). The output of an
Ewald schrieb:
On 03 Mar 2014, at 12:49, Hans-Peter Diettrich wrote:
How (which data type) does *your* parser store untyped numerical
constants?
Roughly like this (syntax may be a bit awry, but you get the point):
TIntegerNumber = Record Case SignedNess: TSignedNess of snPositive:
UValue:
On 01 Mar 2014, at 18:17, Jonas Maebe wrote:
On 01 Mar 2014, at 01:19, Ewald wrote:
That is perfectly true. But shouldn't the most basic behaviour of a language
be at the very least intuitive?
It should be well-defined and consistent. One of Pascal's basic principles is
that the
On 02 Mar 2014, at 14:30, Ewald wrote:
On 01 Mar 2014, at 18:17, Jonas Maebe wrote:
Talking about principles:
If hexadecimal is actually used to represent bit patterns (as Hans-Peter
Diettrich wrote), then the decision to use a signed type here seems to
violate this (represent
Ewald schrieb:
Talking about principles: If hexadecimal is actually used to
represent bit patterns (as Hans-Peter Diettrich wrote), then the
decision to use a signed type here seems to violate this (represent
bitpatterns) principle, since the highest bit in a signed number has
a different
On 03 Mar 2014, at 00:29, Hans-Peter Diettrich wrote:
Ewald schrieb:
It seems like sticking to one principle (signed integer as much as
possible) actually breaks another principle (bitpattern).
Wirth and his Pascal language are well designed with signed types above all,
and unsigned
On 01 Mar 2014, at 03:06, Hans-Peter Diettrich wrote:
Numerical constants, where the sign matters, should only be encoded in
decimal. The other formats (hex,oct,bin...) are intended for use with binary
values, where the bit pattern is important. Then the code compiles correctly
on any
On 01 Mar 2014, at 01:19, Ewald wrote:
On 28 Feb 2014, at 23:43, Jonas Maebe wrote:
Because of the (unPascalish) decision to have an unsigned version of the
largest supported integer type, there are indeed some cases that require
decisions to define the behaviour
That is perfectly
Hi,
Consider the following program (compiled using revision 26807 on OSX):
===
Program QWordToExtended;
Begin
WriteLn(Sizeof(Extended));
WriteLn(Sizeof(QWord));
WriteLn(Sizeof(Longword));
WriteLn(Extended(QWord($)));//1
On 28 Feb 2014, at 20:21, Ewald wrote:
WriteLn(Extended(QWord($)));//1
WriteLn(Extended($)); //2
WriteLn(Extended(Longword($))); //3
WriteLn(Extended($));
On 28 Feb 2014, at 20:39, Jonas Maebe wrote:
On 28 Feb 2014, at 20:21, Ewald wrote:
Since I was curious as to the intended-ness of this behaviour I wrote the
second set of tests which show me that this is not true for longwords: both
3 4 give the same result. This lead me to the
On 28 Feb 2014, at 21:07, Ewald wrote:
On 28 Feb 2014, at 20:39, Jonas Maebe wrote:
All hexadecimal constants are (conceptually) parsed as int64, so this is by
design. int64($) is not -1.
So all numeric constants that are not floats are parsed as Int64's?
They are
On 28 Feb 2014, at 23:43, Jonas Maebe wrote:
On 28 Feb 2014, at 21:07, Ewald wrote:
On 28 Feb 2014, at 20:39, Jonas Maebe wrote:
All hexadecimal constants are (conceptually) parsed as int64, so this is by
design. int64($) is not -1.
So all numeric constants that
Ewald schrieb:
On 28 Feb 2014, at 20:39, Jonas Maebe wrote:
All hexadecimal constants are (conceptually) parsed as int64, so
this is by design. int64($) is not -1.
By the way, what do you do when you want to port fpc to a one's
comlement machine (if they still exist)?
18 matches
Mail list logo
