Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Sven Barth via fpc-devel]

Sven Barth  schrieb am Di., 9. Juli 2019,
07:41:

> Am 08.07.2019 um 02:52 schrieb J. Gareth Moreton:
> > On an extra note, the assembly language produced is not yet optimal,
> > so it may end up that an x86-specific implementation will be
> > beneficial.  TIsNode contains a virtual method named
> > "DoVariableEnumCheck" that would allow such an extension, coupled with
> > returning "nil" that would defer code generation to
> > "pass_generate_code" (allowing this, but not overriding
> > "pass_generate_code", will trigger an internal error, because the 'is'
> > node normally never allows it to be called).  Nevertheless, even if
> > that is a no-go, it's making me a little excited to see if I can find
> > new peephole optimisations to implement.  But until my old x86_64
> > overhaul is accepted, rejected or reworked (at least to make it
> > successfully merge), I can't really make any new additions yet.
> Some non-technical remarks regarding code formatting (I know the
> compiler does currently not use a consistent style, but there is one
> that is considered the de facto one (I should find the time to write
> that down in the Wiki some time -.-) and new code should be added
> following this):
> - no spaces between operators and symbols, both in assignments and
> expressions as well as parameter declarations
> - local variables are written in lower case with the declarations as
> "name1,name2,name3 : type"
> - types are written in lower case
> - method names are lower case with '_' as separator between words (so
> your DoVariableEnumCheck would become do_variable_enum_check)
>
> And one very important technical remark:
> *No* "as" (or "is") inside the compiler. Use hard casts as you already
> checked for the def type
>

And I'm rather conflicted regarding the usage of "with". But Florian and/or
Jonas should comment whether we want new ones in the compiler or not.

Regards,
Sven

>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Sven Barth via fpc-devel]

Am 08.07.2019 um 02:52 schrieb J. Gareth Moreton:
On an extra note, the assembly language produced is not yet optimal, 
so it may end up that an x86-specific implementation will be 
beneficial.  TIsNode contains a virtual method named 
"DoVariableEnumCheck" that would allow such an extension, coupled with 
returning "nil" that would defer code generation to 
"pass_generate_code" (allowing this, but not overriding 
"pass_generate_code", will trigger an internal error, because the 'is' 
node normally never allows it to be called).  Nevertheless, even if 
that is a no-go, it's making me a little excited to see if I can find 
new peephole optimisations to implement.  But until my old x86_64 
overhaul is accepted, rejected or reworked (at least to make it 
successfully merge), I can't really make any new additions yet.
Some non-technical remarks regarding code formatting (I know the 
compiler does currently not use a consistent style, but there is one 
that is considered the de facto one (I should find the time to write 
that down in the Wiki some time -.-) and new code should be added 
following this):
- no spaces between operators and symbols, both in assignments and 
expressions as well as parameter declarations
- local variables are written in lower case with the declarations as 
"name1,name2,name3 : type"

- types are written in lower case
- method names are lower case with '_' as separator between words (so 
your DoVariableEnumCheck would become do_variable_enum_check)


And one very important technical remark:
*No* "as" (or "is") inside the compiler. Use hard casts as you already 
checked for the def type


Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Ben Grasset]

Ok, after thinking about it for a bit, I decided to go ahead and implement
the "customizable leading whitespace" thing right away, as a lot of people
seemed to want it, and also because I just realized that it would not be
difficult at all to do.

So, that said, my Github fork branch
 of the compiler now contains a
{$MultiLineStringTrimLeft} directive, that does precisely what you might
think. Here's one of my compiler tests, which I think demonstrates it
fairly well:

program tmultilinestring14;

{$modeswitch MultiLineStrings}

{$MultiLineStringTrimLeft 2}

const A = `
  A
  B
  C
  D
`;

{$MultiLineStringTrimLeft 4}

const B = `
A
B
C
D
`;

begin
  Write(A);
  Write(B);

  { The number-to-trim being larger, (even much larger) than the amount of
whitespace is not a problem,
as it stops immediately when it is no longer actually *in* whitespace
regardless. }

  {$MultiLineStringTrimLeft 1}

  { Non-leading whitespace is preserved properly, of course. }

  Write(`
sdfs
sd fs fs
sd  fsfs  sdfd sfdf
sdfs fsd
  `);
end.

The output looks like this, showing that everything appears as though it
was written at the "far left" of the file without indentation:

A
B
C
D

A
B
C
D

sdfs
sd fs fs
sd  fsfs  sdfd sfdf
sdfs fsd

Hopefully this will quell some of the uncertainties people may still have
had about the feature, and also ultimately make it easier to use overall!
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

[Ryan Joseph]

> On Jul 8, 2019, at 5:27 PM, Sven Barth via fpc-devel 
>  wrote:
> 
> Well, in theory you could use a read only index property that returns a 
> pointer and a write only index property that takes the type as is. 
> But overloading only based on the result type is not supported.
> 

I was thinking more along the lines of making read/write access part of the 
overloading but that’s kind of pushing it in terms of what overloading means.

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

[Ryan Joseph]

> On Jul 8, 2019, at 6:11 PM, Ben Grasset  wrote:
> 
> Also, here's a longer (but much better because it doesn't require the data 
> type provided by the user to itself be directly assignable to a pointer) 
> version of that:
> 

That’s getting creative, I like it, thanks.

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

[Ben Grasset]

On Mon, Jul 8, 2019 at 3:47 PM Ben Grasset  wrote:

> On Mon, Jul 8, 2019 at 2:22 PM Ryan Joseph  wrote:
>
>> and it will actually write to the actual record in the array and not a
>> returned copy. However due to how the properties are currently structured
>> this means we can’t use the setter without passing pointers
>>
>
> Ah, I see what you mean. Note you can at least work around this for now
> with operator overloading:
>

Also, here's a longer (but much better because it doesn't require the data
type provided by the user to itself be directly assignable to a pointer)
version of that:

program Example;

{$mode Delphi}{$H+}

uses SysUtils;

type
  PVec3F = ^TVec3F;

  TVec3F = record
X, Y, Z: Single;
  end;

type
  TList = record
  public type
PT = ^T;
TConverter = record
  V: PT;
  class operator Implicit(constref From: T): TConverter; inline;
  class operator Implicit(const From: PT): TConverter; inline;
  class operator Implicit(constref From: TConverter): PT; inline;
end;
  strict private
FData: array of TConverter;
  private
function GetItem(const I: PtrUInt): TConverter; inline;
procedure SetItem(const I: PtrUInt; const Val: TConverter); inline;
function GetLength: PtrInt; inline;
procedure SetLength(const I: PtrInt); inline;
  public
property Items[const I: PtrUInt]: TConverter read GetItem write
SetItem; default;
property Length: PtrInt read GetLength write SetLength;
  end;

  class operator TList.TConverter.Implicit(constref From: T): TConverter;
  begin
Result.V := @From;
  end;

  class operator TList.TConverter.Implicit(const From: PT): TConverter;
  begin
Result.V := From;
  end;

  class operator TList.TConverter.Implicit(constref From: TConverter):
PT;
  begin
Result := From.V;
  end;

  function TList.GetItem(const I: PtrUInt): TConverter;
  begin
if I < System.Length(FData) then
  Result := FData[I]
else
  Result := nil;
  end;

  procedure TList.SetItem(const I: PtrUInt; const Val: TConverter);
  begin
if I < System.Length(FData) then
  FData[I] := Val;
  end;

  function TList.GetLength: PtrInt;
  begin
Result := System.Length(FData);
  end;

  procedure TList.SetLength(const I: PtrInt);
  begin
System.SetLength(FData, I);
  end;

const
  DEFAULT_VEC3F: TVec3F = (
X: 0.0;
Y: 0.0;
Z: 0.0;
  );

var
  PVec: PVec3F;
  VecList: TList;

begin
  VecList.Length := 2;

  // So, you can directly assign to the list by value...
  VecList[0] := DEFAULT_VEC3F;

  // Or via a pointer...
  VecList[1] := @DEFAULT_VEC3F;

  // And directly assign *from* the list to a pointer...
  PVec := VecList[0];
  with PVec^ do begin
X := 2.0;
Y := 4.0;
Z := 6.0;
  end;
  with PVec^ do
WriteLn(Format('[%f %f %f]', [X, Y, Z]));

  // Or just do this
  with VecList[0].V^ do begin
X := 2.0;
Y := 4.0;
Z := 6.0;
  end;

  //And this
  with VecList[0].V^ do
WriteLn(Format('[%f %f %f]', [X, Y, Z]));
end.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[J. Gareth Moreton]

I need to know exactly what's been decided upon.  No arguments, no 
debates, no objections.  What has been accepted as "this is what will be 
implemented after all parties have been heard"? Because I can't put 
myself into a meltdown while my neck is being wrung for not doing what 
people wanted.


Gareth aka. Kit


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

[Sven Barth via fpc-devel]

Ryan Joseph  schrieb am Mo., 8. Juli 2019, 18:04:

>
>
> > On Jul 8, 2019, at 11:07 AM, Sven Barth via fpc-devel <
> fpc-devel@lists.freepascal.org> wrote:
> >
> > As Pascal does not allow differentiating between result types this
> indeed needs to be/stay forbidden.
> >
>
> There actually is a need to distinguish between getters/setters but the
> way property syntax works we’re forced for the return type to be the same
> as the input for the setter. This is a problem I faced before where I want
> the getter to return a pointer but I want the setter to take a direct value.
>

Well, in theory you could use a read only index property that returns a
pointer and a write only index property that takes the type as is.
But overloading only based on the result type is not supported.

Regards,
Sven
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[J. Gareth Moreton]

Apologies.  I've been getting lost and confused in all the details and 
am not even sure what people want any more.  What is the consensus from 
the administrators?


Gareth aka. Kit


On 08/07/2019 21:00, Ondrej Pokorny wrote:

On 08.07.2019 17:19, J. Gareth Moreton wrote:

I disabled it after Pierre pointed out
that you couldn't use Pred or Succ with
them, so wanted to be consistent,
especially as programming them to return
the expected value of False of a value
falls within a hole is not simple. Still,
it's easy enough to re-enable.

Gareth aka. Kit


There has been a much bigger discussion about it than the one post 
from Pierre.


Ondrej


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Ondrej Pokorny]

On 08.07.2019 17:19, J. Gareth Moreton wrote:

I disabled it after Pierre pointed out
that you couldn't use Pred or Succ with
them, so wanted to be consistent,
especially as programming them to return
the expected value of False of a value
falls within a hole is not simple. Still,
it's easy enough to re-enable.

Gareth aka. Kit


There has been a much bigger discussion about it than the one post from 
Pierre.


Ondrej


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

[Ben Grasset]

On Mon, Jul 8, 2019 at 2:22 PM Ryan Joseph  wrote:

> and it will actually write to the actual record in the array and not a
> returned copy. However due to how the properties are currently structured
> this means we can’t use the setter without passing pointers
>

Ah, I see what you mean. Note you can at least work around this for now
with operator overloading:

program Example;

{$mode Delphi}{$H+}

uses SysUtils;

type
  PVec3F = ^TVec3F;

  TVec3F = record
X, Y, Z: Single;
class operator Implicit(constref From: TVec3F): PVec3F; inline;
  end;

  class operator TVec3F.Implicit(constref From: TVec3F): PVec3F;
  begin
Result := @From;
  end;

type
  TList = record
  public type
PT = ^T;
  strict private
FData: array of T;
  private
function GetItem(const I: PtrUInt): PT; inline;
procedure SetItem(const I: PtrUInt; const Val: PT); inline;
function GetLength: PtrInt; inline;
procedure SetLength(const I: PtrInt); inline;
  public
property Items[const I: PtrUInt]: PT read GetItem write SetItem;
default;
property Length: PtrInt read GetLength write SetLength;
  end;

  function TList.GetItem(const I: PtrUInt): PT;
  begin
if I < System.Length(FData) then
  Result := @FData[I]
else
  Result := nil;
  end;

  procedure TList.SetItem(const I: PtrUInt; const Val: PT);
  begin
if I < System.Length(FData) then
  FData[I] := Val^;
  end;

  function TList.GetLength: PtrInt;
  begin
Result := System.Length(FData);
  end;

  procedure TList.SetLength(const I: PtrInt);
  begin
System.SetLength(FData, I);
  end;

var
  I: PtrUInt;
  Vec: TVec3F = (
X: 0.0;
Y: 0.0;
Z: 0.0;
  );
  VecList: TList;

begin
  VecList.Length := 1;
  VecList[0] := Vec;
  with VecList[0]^ do begin
X := 2.0;
Y := 4.0;
Z := 6.0;
  end;
  // Access it again, separately...
  with VecList[0]^ do
WriteLn(Format('[%f %f %f]', [X, Y, Z]));
end.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

[Ryan Joseph]

> On Jul 8, 2019, at 2:16 PM, Ben Grasset  wrote:
> 
> One thing I might point out as a general tip is that you don't really 
> necessarily *need* an array-style index for the kind of access you seem to be 
> going for, especially if using something like TValue which has a lot of 
> assignment operator overloads in place by default.
> 

That was just an example, nothing to do with TValue. We need pointer getters 
for “array of record” so we can do:

list[0]^.x := 100;

and it will actually write to the actual record in the array and not a returned 
copy. However due to how the properties are currently structured this means we 
can’t use the setter without passing pointers:

list[0] := @vec;

That’s why I think it’s worthing considering the overloading properties to 
solve this.

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

[Ben Grasset]

On Mon, Jul 8, 2019 at 12:04 PM Ryan Joseph  wrote:

> There actually is a need to distinguish between getters/setters but the
> way property syntax works we’re forced for the return type to be the same
> as the input for the setter. This is a problem I faced before where I want
> the getter to return a pointer but I want the setter to take a direct value.
>

One thing I might point out as a general tip is that you don't really
necessarily *need* an array-style index for the kind of access you seem to
be going for, especially if using something like TValue which has a lot of
assignment operator overloads in place by default.

Here's a little example I threw together:

program Example;

{$Mode ObjFPC}{$H+}
{$ModeSwitch AdvancedRecords}
{$ImplicitExceptions Off}
{$Assertions On}

uses RTTI;

  operator :=(const RHS: TValue): TObject; inline;
  begin
if RHS.IsObject() then
  Result := RHS.AsObject()
else
  Result := nil;
  end;

type
  TMyClass = class end;

  TMyRecord = record
  strict private
FValue: TValue;
  public
procedure FreeIfNecessary; inline;
  private
function GetValue: TValue; inline;
procedure SetValue(const V: TValue); inline;
  public
property Value: TValue read GetValue write SetValue;
  end;

  procedure TMyRecord.FreeIfNecessary;
  var O: TObject = nil;
  begin
// Unfortunate misnomer.. IsObject() really returns true if
// the value is a class instance, while IsClass()
// returns true if the value is a class reference.
// Ironically, there is no function for actual TP-style objects.
if FValue.IsObject() then
begin
  O := FValue.AsObject();
  if O <> nil then
O.Free();
end;
  end;

  function TMyRecord.GetValue: TValue;
  begin
case FValue.Kind of
  tkSString: Result := FValue.AsString();
  tkAString: Result := FValue.AsAnsiString();
  tkUString: Result := FValue.AsUnicodeString();
  tkFloat: Result := FValue.AsExtended();
  tkInteger, tkInt64: Result := FValue.AsOrdinal();
  tkQWord: Result := FValue.AsUInt64();
  tkBool: Result := FValue.AsBoolean();
  tkClass: Result := FValue.AsObject();
  else
Assert(False, 'Unsupported data type!');
end;
  end;

  procedure TMyRecord.SetValue(const V: TValue);
  begin
FValue := V;
  end;

var
  V: TMyRecord;
  C: TObject = nil;

begin
  V.Value := 2;
  V.Value := 'Hey';
  V.Value := 14.567;
  V.Value := False;
  V.Value := TObject.Create();
  V.FreeIfNecessary();
  V.Value := TMyClass.Create();
  C := V.Value;
  WriteLn(C.ClassName());
  V.FreeIfNecessary();
end.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[J. Gareth Moreton]

I disabled it after Pierre pointed out 
that you couldn't use Pred or Succ with 
them, so wanted to be consistent, 
especially as programming them to return 
the expected value of False of a value 
falls within a hole is not simple. Still, 
it's easy enough to re-enable.

Gareth aka. Kit

On Mon 08/07/19 12:51 , Ondrej Pokorny 
laza...@kluug.net sent:
> On 08.07.2019 02:37, J. Gareth Moreton 
wrote:
> 
> Uploaded the latest patch (AS-IS-enum-
07.patch) over here [1] and also a
> test project that evaluates the "is" 
operator between different ordinal
> types.  
> 
> I though I convinced you not to disable 
the feature on enums with holes
> even in OBJFPC mode... 
> 
> Ondrej
> 
> 
__
_
> fpc-devel maillist - fpc-
de...@lists.freepascal.org
> https://lists.freepascal.org/cgi-
bin/mailman/listinfo/fpc-devel [2]
> 
> 
> 
> Links:
> --
> [1] 
https://bugs.freepascal.org/view.php?
id=33603
> [2]
> http://secureweb.fast.net.uk/parse.php?
redirect=https://lists.freepascal.or
> g/cgi-bin/mailman/listinfo/fpc-devel
> 

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

[Ryan Joseph]

> On Jul 8, 2019, at 11:07 AM, Sven Barth via fpc-devel 
>  wrote:
> 
> As Pascal does not allow differentiating between result types this indeed 
> needs to be/stay forbidden. 
> 

There actually is a need to distinguish between getters/setters but the way 
property syntax works we’re forced for the return type to be the same as the 
input for the setter. This is a problem I faced before where I want the getter 
to return a pointer but I want the setter to take a direct value.

It could be solved by overloading but the syntax for the setter doesn’t make as 
much sense.

type
  generic TList = class
public type
  TReference = ^T;
private
 function GetValue(index: integer): TReference;
 property Values[index: integer]: TReference read GetValue; default;

 procedure SetValue(index: integer; value: T); 
 property Values[index: integer]: T write SetValue; default;
  end;


Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

[Sven Barth via fpc-devel]

Ryan Joseph  schrieb am Mo., 8. Juli 2019, 16:10:

> I just encountered something to consider. Should a property be
> overloadable if the names/args are the same but the return type is
> different? I think if they are not the same access type (i.e. read/write)
> then it could work (not sure about the parsing though) but if both are the
> same access then they should not be allowed.
>

As Pascal does not allow differentiating between result types this indeed
needs to be/stay forbidden.

Regards,
Sven

>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [] property overloads

[Ryan Joseph]

I just encountered something to consider. Should a property be overloadable if 
the names/args are the same but the return type is different? I think if they 
are not the same access type (i.e. read/write) then it could work (not sure 
about the parsing though) but if both are the same access then they should not 
be allowed.

==

property Values[key: variant]: TValue read GetValue; default;
property Values[key: variant]: variant write SetValue; default;

==

property Values[key: variant]: TValue read GetValue; default;
property Values[key: variant]: string read GetValue; default;

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Ben Grasset]

On Mon, Jul 8, 2019 at 8:51 AM Ben Grasset  wrote:

> I'm probably not gonna be working on that myself any time soon, but
> certainly yeah I think that IncludeString has an equal amount of value as a
> feature, and would compliment multi-line strings well.
>

Hmm, perhaps I spoke too soon. The IncludeStringFile patch looks very
simple, actually. Maybe I will in fact take a look at it once I'm properly
done with the initial multi line strings implementation.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Marco van de Voort]

Op 08/07/2019 om 06:27 schreef J. Gareth Moreton:
I'm a bit late to the party again, but the example of an OpenGL shader 
has won me over, since game design is one thing I enjoy doing.  I 
guess I'm still a bit unsure how leading and trailing whitespace 
should be handled, but as long as it's well-documented, I think I'll 
be happy!


Speaking of shaders, I would request the {$INCLUDESTRINGFILE} thing 
alongside it, because things like shaders are programs in themselves 
and may have to be tested in a third-party application, so including 
the file directly rather than copying and pasting its contents would 
be much safer if changes need to be made.



I include them now as resources. Windows only atm though

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Ben Grasset]

On Mon, Jul 8, 2019 at 12:27 AM J. Gareth Moreton 
wrote:

> Speaking of shaders, I would request the {$INCLUDESTRINGFILE} thing
> alongside it, because things like shaders are programs in themselves and
> may have to be tested in a third-party application, so including the
> file directly rather than copying and pasting its contents would be much
> safer if changes need to be made.
>

I'm probably not gonna be working on that myself any time soon, but
certainly yeah I think that IncludeString has an equal amount of value as a
feature, and would compliment multi-line strings well.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Ryan Joseph]

> On Jul 8, 2019, at 12:27 AM, J. Gareth Moreton  
> wrote:
> 
> Speaking of shaders, I would request the {$INCLUDESTRINGFILE} thing alongside 
> it, because things like shaders are programs in themselves and may have to be 
> tested in a third-party application, so including the file directly rather 
> than copying and pasting its contents would be much safer if changes need to 
> be made.

Yeah I wonder if {$INCLUDESTRINGFILE} could leverage the changes with multiline 
strings so it gets included also. The original patch has been sitting there 
dead since 2014.

Regards,
Ryan Joseph

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Ondrej Pokorny]

On 08.07.2019 02:37, J. Gareth Moreton wrote:


Uploaded the latest patch (AS-IS-enum-07.patch) over here 
 and also a test 
project that evaluates the "is" operator between different ordinal types.


I though I convinced you not to disable the feature on enums with holes 
even in OBJFPC mode...


Ondrej


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Ondrej Pokorny]

On 08.07.2019 12:39, Giuliano Colla wrote:

Il 07/07/2019 07:33, J. Gareth Moreton ha scritto:

In the meantime, I'm working on making
"as" and "is" work with ordinal types as
well as enumerations, although currently
some headaches occur if the right-hand
side is larger than the CPU word size
(e.g. Int64 on i386). I'll upload the
patch to the issue once it's working
properly.


Sorry for jumping in without having followed the full discussion, but 
I wonder if "as" and "is" are the best constructs to implement range 
checking. Wouldn't "in" be much more appropriate?


Sort of:

if value in enumvar then DoThat else IgnoreIt;


The IN operator
1.) expects a value on the right side, not a type.
2.) can be overloaded: 
https://www.freepascal.org/docs-html/ref/refse104.html#x213-23500015.6 . 
IS/AS cannot.


Ondrej

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Giuliano Colla]

Il 07/07/2019 07:33, J. Gareth Moreton ha scritto:

In the meantime, I'm working on making
"as" and "is" work with ordinal types as
well as enumerations, although currently
some headaches occur if the right-hand
side is larger than the CPU word size
(e.g. Int64 on i386). I'll upload the
patch to the issue once it's working
properly.


Sorry for jumping in without having followed the full discussion, but I 
wonder if "as" and "is" are the best constructs to implement range 
checking. Wouldn't "in" be much more appropriate?


Sort of:

if value in enumvar then DoThat else IgnoreIt;

Giuliano

--
Do not do to others as you would have them do to you.They might have different 
tastes.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

[Michael Van Canneyt]

On Mon, 8 Jul 2019, J. Gareth Moreton wrote:

I'm a bit late to the party again, but the example of an OpenGL shader 
has won me over, since game design is one thing I enjoy doing.  I guess 
I'm still a bit unsure how leading and trailing whitespace should be 
handled, but as long as it's well-documented, I think I'll be happy!


Speaking of shaders, I would request the {$INCLUDESTRINGFILE} thing 
alongside it, because things like shaders are programs in themselves and 
may have to be tested in a third-party application, so including the 
file directly rather than copying and pasting its contents would be much 
safer if changes need to be made.


I think indeed the 2 (`` and directive) should co-exist.

I strongly believe code and text/data should be separate as much as possible. 
Some of the examples I see makes the hair in my neck crawl... :(


Michael.___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel