Re: [fpc-pascal] Traits Proposal

[Ben Grasset via fpc-pascal]

This seems possibly a *little* too similar to the existing Interface type
in Object Pascal, however, I *would* really like to see some kind of
functionality that basically amounts to "has the same capabilities as
Interfaces and works on records and objects too, but does NOT require any
kind of heap allocation".

So whether it be this, or just an improvement on the Interfaces we already
have, I'd definitely personally be in favor of something that "works like
Interfaces except minus the negative performance implications."

On Tue, Feb 9, 2021 at 9:27 PM Ryan Joseph via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> We had talked about this some time ago and it's been rattling around in my
> brain so I wanted to write it down into a formal proposal where we can
> discuss it and hopefully agree upon a syntax. Everything is preliminary and
> tentative but this is a syntax which allows a "composition over
> inheritance" model, also known as "mix-ins" in some languages. That idea is
> similar to multiple inheritance except you have a concrete reference to the
> trait being implemented so you can resolve conflicts easily.
>
> Here's what I have so far. Please feel free to look at it and give any
> feedback.
>
> https://github.com/genericptr/freepascal/wiki/Traits-Proposal
>
> 
>
> type
>   TSomeTrait = trait
> public
>   field: integer;
>   procedure DoThis;
>   end;
>
>   TMyClass = class
> private
>   _trait: TSomeTrait;
> public
>   property someTrait: TSomeTrait implements _trait;
>   end;
>
> var
>   c: TMyClass;
> begin
>   c := TMyClass.Create;
>   c.DoThis;
>   writeln(c.field):
> end;
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpcmake packaging

[Ben Grasset via fpc-pascal]

What you want is FPMake, not FPCMake. FPCMake is just a generator of GNU
makefiles. As Michael said elsewhere though, FPMake is an API designed
specifically for compiling FPC programs, basically. You write a program
using the API, put it in a file that should always be called "fpmake.pp",
and then either invoke fppkg on it or just literally build it with FPC
yourself and run it (as in like, either "fppkg build" in the directory
where your "fpmake.pp" is, or "fpc ./fpmake.pp && ./fpmake build" in the
directory where your "fpmake.pp" is). Again though, since it is literally
just a program, you can also put any custom logic you want in there.

See here for more info: https://wiki.freepascal.org/FPMake

On Tue, Sep 1, 2020 at 9:05 AM Ryan Joseph via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> I've never used fpcmake before and instead relied on my own custom build
> system solutions which are a pain to maintain and non-standard which it
> makes extra work configuring the pascal language server I'm using now.
>
> My first question of fpcmake is, can I package application bundles and
> copy resources using it? For example some things I need to do:
>
> - create a directory structure and copy the executable into it
> - copy resource files that may have changed
> - run some shell commands which apple provides for compiling various
> resources files
> - copy a info.plist text file and replace some patterns in the file to
> reflect the build version
>
> Are those the kind of things fpcmake can do or do I need another build
> system for this?
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generic type conflicts

[Ben Grasset via fpc-pascal]

On Fri, Nov 8, 2019 at 11:18 AM Ben Grasset  wrote:

> I know what you mean, and I'm aware, but you actually kind of can to the
> fairly straightforward extent that I'm concerned about with Ryan's patch
> (i.e. simply passing constant results as constraints rather than function
> parameters.)
>

Also, if you were referring specifically to the "making the choice part",
looking at the PDQSort C++ code again, all it was actually doing is
evaluating the *types* involved, not the comparison function itself. Which
would be fairly straightforward to replicate in FPC using something like a
constant TTypeKind constraint.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generic type conflicts

[Ben Grasset via fpc-pascal]

On Fri, Nov 8, 2019 at 11:04 AM Jonas Maebe  wrote:

> You can't. It's the main difference between C++ templates, which is a
> Turing-complete programming language, and generics, which is simply a
> parametrising mechanic.
>

I know what you mean, and I'm aware, but you actually kind of can to the
fairly straightforward extent that I'm concerned about with Ryan's patch
(i.e. simply passing constant results as constraints rather than function
parameters.)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generic type conflicts

[Ben Grasset via fpc-pascal]

On Fri, Nov 8, 2019 at 1:33 AM Michael Van Canneyt 
wrote:

> As an aside:
> In my opinion (keep in mind I am not a big fan of generics) the above code
> would be a prime example where one should not be using generics, but
> simple overloads.
> If you need to use GetTypeKind in a generic, I think you're on the wrong
> path.
> Use of IsManagedType() in a generic is stretching it, but GetTypeKind() is
> over the line.
>

I agree to an extent that it's not a *huge* problem and that there are
workarounds in many cases, however there's definitely certain things that
simply cannot be achieved in an equally performant way via any alternative
such as normal overloading.

That said, Ryan's currently-in-limbo patch for constant generic parameters
actually itself in theory already provides proper solutions for quite a few
aspects of the general problem, so even as it stands right now we're at
least making progress towards improving the situation I'd say.

For example, I recently did a translation of the fairly well-known
"PDQSort" algorithm from C++ to Pascal:

https://github.com/Akira13641/PasPDQSort

The original C++ version used "constexpr" template parameters to determine
at compile time whether or not the user-provided comparison function was
one for which it should use the "branchless" version of its code for item
partitioning or not, and based on that passed the boolean "true" or "false"
result as another constant template parameter.

The end result of course being that the compiled code is always tuned
precisely to the given comparison function, without any kind of runtime
selection based on non-constant boolean function parameters (which is what
I've currently had to write the "branchless" choice as, defaulting to
"true" unless the user specifies otherwise.)

With Ryan's patch, I'll at least be able to write that choice as a constant
parameter instead, although I'm unaware of any way to replicate actually
having the compiler *make* the choice.

So perhaps what's needed is not even necessarily something like "static if"
support, but rather just more compiler intrinsics along the lines of
GetTypeKind / IsManagedType that evaluate different things and return
constant values, which in combination with Ryan's patch will go a long way
as far as increasing the granularity of control available to users of FPC
as far as this kind of stuff.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generic type conflicts

[Ben Grasset via fpc-pascal]

On Thu, Nov 7, 2019 at 10:23 AM Michael Van Canneyt 
wrote:

> If I understood Sven's example correct, then the compiler does exactly this
> already.
>

It does in the sense of *code generation* for things that are specifically
compiler intrinsics (which I was aware of), but not in a sense that makes
the issue Ryan was posting about here avoidable. Maybe this will explain
what I'm trying to get at a bit better:

program Example;

{$mode ObjFPC}

// Without actually specializing and using GDiv,
// this program compiles fine.

generic function GDiv(const A, B: T): T; inline;
begin
  if GetTypeKind(T) in [tkInteger, tkInt64, tkQWord] then
Result := A div B
  else if GetTypeKind(T) = tkFloat then
Result := A / B
  else
Result := Default(T);
end;

// However, once we do specialize it...

procedure UseGDiv;
begin
  // Example.pas(13,17) Error: Incompatible types: got "Double" expected
"Int64"
  WriteLn(specialize GDiv(1, 2));
  // Example.pas(11,17) Error: Operator is not overloaded: "Double" div
"Double"
  WriteLn(specialize GDiv(1, 2));
end;

// Note: I'm fully aware that having the *normal* if-statement work in such
a way that the
// the above would compile is neither feasible or a good idea. However,
imagine something
// like the following hypothetical version of GDiv, which would rely on the
conditional
// compilation aspect of the scanner to be aware of more than it currently
is, and also
// for the conditional compilation syntax to be somewhat more advanced:

generic function GDiv(const A, B: T): T; inline;
begin
  // Here, we're doing precisely the same kind of thing that is currently
  // possible with SizeOf, Declared, Defined, and so on.
  {$IF GetTypeKind(T) in [tkInteger, tkInt64, tkQWord]}
Result := A div B
  {$ELSEIF GetTypeKind(T) = tkFloat}
Result := A / B
  {$ELSE}
Result := Default(T);
  {$ENDIF}
end;

begin
end.

Of course, implementing that kind of thing in the scanner would likely be
far more difficult than implementing it as something that happens in
"normal" code, via some syntax or perhaps intrinsic that makes it
distinctively a fully-statically-considered conditional, as opposed to a
partially-statically considered one as is the case with normal "if".
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generic type conflicts

[Ben Grasset via fpc-pascal]

On Thu, Nov 7, 2019 at 3:03 AM Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> If there is no type checking, then it is *not* verified by the compiler.
>

Perhaps "no type checking" was not the write way to put it. A better way to
describe it might be:

Since the compiler *always* knows exactly which type a generic type
constraint currently amounts to, it is clearly capable of properly choosing
specific code paths based on that, if given some kind of
constant-evaluatable boolean condition that is specifically based on
TTypeKind.

In general, it's *exactly* the same concept as something like using SizeOf
in an {$IF} / {$ELSEIF} directive pair (where the compiler does indeed
completely ignore everything in the "false" section):

program Example;

begin
  // You can in fact put stuff that isn't even close to valid code in
whichever block is false for you, below.
  {$IF SizeOf(Pointer) = 4}
WriteLn('The size of a pointer is 4 bytes.');
  {$ELSEIF SizeOf(Pointer) = 8}
WriteLn('The size of a pointer is 8 bytes.');
  {$ENDIF}
end.

Not that it has to do precisely the same thing for a hypothetical
TTypeKind-based choice.

E.G. it could still do the full checking, as the only thing that really
matters is that it does not actively raise error messages only relevant for
Integer under code blocks only entered for tkFloat.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generic type conflicts

[Ben Grasset via fpc-pascal]

On Wed, Nov 6, 2019 at 7:33 PM Ben Grasset  wrote:

> Encouraging typecasting (which cares only about the sizes of the types
> involved, nothing else) at the programmer level is far more error-prone in
> a variety of ways.
>

Also: it's slower in many cases, because it tends to involve "if"
statements that *remain* as if statements in the final generated assembly
code, whereas a static check would allow for simply generating *only* the
code for the path that's actually taken.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generic type conflicts

[Ben Grasset via fpc-pascal]

On Wed, Nov 6, 2019 at 12:44 PM Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> Pascal has a strong type safety, thus something like the if-expression
> won't be used/allowed to weaken that.
>
> If that means that some things can't be implemented in generics the "easy"
> way, then so be it.
>

I agree that Pascal has strong type safety.

IMO conditional branching based on compile-time constant evaluation, that
cannot fail, does not do anything resembling weakening it, however.

It strengthens it, and has no downsides, because it's verified by the
compiler.

Encouraging typecasting (which cares only about the sizes of the types
involved, nothing else) at the programmer level is far more error-prone in
a variety of ways.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generic type conflicts

[Ben Grasset via fpc-pascal]

On Wed, Nov 6, 2019 at 2:01 AM Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> A normal if-statements has the same non-evaluation.
>

Not in the way I meant, though.

Like, I thought the difference between "normal if" and "ternary if" was
supposed to be the same as the difference between the existing IfThen()
function and the intrinsic version of IfThen(), on which you based the
"if-then-else" syntax I think.

By which I mean, something similar to the difference between "if" and
"static if" in the D programming language (at least when given things that
are possible to evaluate at compile time, like GetTypeKind is in Pascal).
For example:

import std.stdio;
import std.traits;

// Would not compile, because everything is evaluated fully,
// and in this case the parameters we pass aren't
// compatible with all branches.
void PrintSomething(T)(T value) {
  if (isFloatingPoint!(T)) {
writefln("Floating point value: %f", value * value);
  } else if (isIntegral!(T)) {
writefln("Integral value: %d", value * value);
  } else if (isSomeString!(T)) {
writefln("String value: %s", value ~ value);
  }
}

// Compiles fine, as only the relevant branch for
// a given parameter is evaluated.
void StaticPrintSomething(T)(T value) {
  static if (isFloatingPoint!(T)) {
writefln("Floating point value: %f", value * value);
  }
  else static if (isIntegral!(T)) {
writefln("Integral value: %d", value * value);
  }
  else static if (isSomeString!(T)) {
// "~" does string concatenation in D
writefln("String value: %s", value ~ value ~ value);
  }
}

void main() {
  StaticPrintSomething(1);
  StaticPrintSomething(1.0);
  StaticPrintSomething("hey");
}

The point being that the type-checking is neither useful or necessary in
scenarios where the branch being evaluated is statically known to be
unreachable ahead of time.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generic type conflicts

[Ben Grasset via fpc-pascal]

On Tue, Nov 5, 2019 at 5:24 PM Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> Does this really work? Cause the compiler should nevertheless typecheck
> the code in the other branch and thus without casts that shouldn't compile.
> Also if it should indeed work, it would also work without the
> if-expression, but with an if-statement.
>

Hm, it actually doesn't quite for that particular example, testing it for
real. It definitely did for a few other generic things I experimented with
though (that were impossible otherwise.) I'll see if I can find the source
files anywhere.

Why would it work the same way as a normal if statement, though? Isn't the
non-evaluation of the false branch pretty much the only point of the
ternary "form"? E.G. you'd specifically use it when you had two branches
that you knew would never *both* be compilable.
You'd be able to do the same thing with an {$IFDEF}, for example, if
{$IFDEFS} specifically carried through across generic specializations.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Generic type conflicts

[Ben Grasset via fpc-pascal]

On Sat, Nov 2, 2019 at 11:51 AM Ryan Joseph via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> Are there any solutions for this currently? I feel like generics need to
> support some compiler directives so different blocks of code can specialize
> different depending on the type.
>

There's one, that works *exactly* like you want (although it's not
currently present in trunk FPC) which is to apply the (still-working) patch
Sven posted in this mailing list thread a few years ago:
https://www.mail-archive.com/fpc-pascal@lists.freepascal.org/msg41336.html

It introduces a const-evaluated "ternary if" of the form "Variable := if
Expression else Expression;" where only the true branch is taken into
consideration by the compiler at all.

Combining it with handy compiler intrinsics like GetTypeKind makes stuff
like the following modified version of your code possible:

{$mode objfpc}
{$modeswitch advancedrecords}

program generic_vector_2;

type
  generic TVec2 = record
X, Y: TScalar;
class function Create(const AX, AY: TScalar): TVec2; static; inline;
class operator / (const Left, Right: TVec2): TVec2; inline;
  end;

  class function TVec2.Create(const AX, AY: TScalar): TVec2;
  begin
with Result do begin
  X := AX;
  Y := AY;
end;
  end;

  class operator TVec2./(const Left, Right: TVec2): TVec2;
  begin
// GetTypeKind is evaluated at compile time, so the following works
perfectly with "ternary if".
Result :=
  if GetTypeKind(TScalar) = tkFloat then
TVec2.Create(Left.X / Right.X, Left.Y / Right.Y)
  else
TVec2.Create(Left.X div Right.X, Left.Y div Right.Y);
  end;

type
  TVec2f = specialize TVec2;
  TVec2i = specialize TVec2;

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

Re: [fpc-pascal] for-in loop cast

[Ben Grasset]

On Thu, Sep 26, 2019 at 11:59 AM Ben Grasset  wrote:

> -snip-
>

I meant to change the last part of the revised code example to:

  for value in list do

because obviously the pointer cast is no longer necessary in that case.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] for-in loop cast

[Ben Grasset]

 On Thu, Sep 26, 2019 at 11:37 AM Ryan Joseph  wrote:

> Question I’ve always had. Why do I need to cast “value” to “pointer"
> otherwise I get: Incompatible types: got "Pointer" expected “TObject”
> error?. I don’t find this very helpful and it doesn’t really make sense
> even.
>

Well, TObjectList is a descendant of TList, which is of course a
non-generic list of void pointers. The enumerator for TList that allows the
for-in loop to work, called TListEnumerator, as such obviously implements
GetCurrent as returning "pointer".

TObjectList doesn't have its own enumerator implementation on top of the
TList one or anything like that, so when you use for-in on TObjectList,
you're using the pointer-based TList one.

The fix for this is simple IMO: use a generic list class instead. For
example, if you want something that works exactly like your code example,
you can specialize TObjectList from Generics.Collections literally *with*
TObject:

type
  TBaseObjectList = TObjectList;
var
  list: TBaseObjectList;
  value: TObject;
begin
  for pointer(value) in list do
;
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [Lazarus] Tests results of several pascal based JSON parsers

[Ben Grasset]

On Sat, Aug 31, 2019 at 9:40 AM Anthony Walter  wrote:

> > Could you include https://github.com/BeRo1985/pasjson in the comparison?
>
> Sure. I also have a few other people have requested. I will also list the
> license of each in the first table.
>

Note that I'm not sure if it's FPC-compatible, but I've found
https://github.com/neslib/Neslib.Json to be *by far* the fastest JSON
library for Delphi.

So if you can get it to compile with FPC (probably with {$mode
DelphiUnicode} amongst other things) it would be an interesting addition to
your tests as well.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Tests results of several pascal based JSON parsers

[Ben Grasset]

On Fri, Aug 30, 2019 at 5:16 AM Michael Van Canneyt 
wrote:

> The shootout benchmarks for example are dismally coded for FPC with as a
> result that they perform badly.
>

Not all of them! At least, not anymore:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/binarytrees.html

More recently I also managed to bring the execution time for "Mandelbrot"
up to 8.52 seconds for FPC, whereas the version that had been around for a
long time before that ran in 22 seconds:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/mandelbrot-fpascal-8.html


 I'm hoping to figure out how to bring it up even more, but I think I might
need to wait for 3.2.0 for that (loop unrolling on by default at -O3,
e.t.c.)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Virtual object methods

[Ben Grasset]

On Thu, Jun 27, 2019 at 5:57 PM Ryan Joseph  wrote:

>
> Heap allocate how so? Calling the constructor seems to fix this and puts
> the VMT table on the stack (I think anyways). Btw I’m doing this
> specifically as testing for a possible “advancedobjects” mode switch and
> the only reason to use objects is for inheritance on the stack (otherwise
> records or classes).
>

I actually misunderstood what you were trying to do (read the program too
quickly.) Never mind.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Virtual object methods

[Ben Grasset]

On Thu, Jun 27, 2019 at 4:17 PM Ryan Joseph  wrote:

> Why do I get a runtime error with this?
>

If you specifically need inheritance (combined with virtual methods) you
should probably just use classes, because doing it with objects will
require heap allocation regardless.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String conversions

[Ben Grasset]

On Wed, Jun 26, 2019 at 5:36 PM Ryan Joseph  wrote:

> Yes indeed. FPC already has an overwhelming amount of string types. As I
> said though a SetCapacity option for growing would be nice (for dynamic
> arrays also) because += is such a common operation. As it stands I often
> don’t use dynamic arrays (and now ansistring) because of growing
> limitations, which is a shame really.
>

Well, I think the idea is that stuff like capacity is what you'd have / do
have in actual containers built *around* strings and / or dynamic arrays,
as they're both just built in primitives.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String conversions

[Ben Grasset]

On Wed, Jun 26, 2019 at 3:28 PM Ben Grasset  wrote:

> I think Ryan probably meant his own custom types. And certainly, you can
> do some interesting stuff with operator overloading that mostly avoids the
> normal AnsiString overhead. Here's an example.
> <https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,lang:pascal,source:'unit+output%3B%0A%0A%7B$mode+ObjFPC%7D%7B$H%2B%7D%0A%7B$modeswitch+AdvancedRecords%7D%0A%7B$ImplicitExceptions+Off%7D%0A%0Ainterface%0A%0Atype+%0A++TPCharEx+%3D+record%0AP:+PChar%3B%0AL:+SizeInt%3B%0Aclass+operator+:%3D(constref+LHS:+AnsiString):+TPCharEx%3B+inline%3B%0Aclass+operator+:%3D(constref+LHS:+ShortString):+TPCharEx%3B+inline%3B%0A++end%3B%0A%0Afunction+Reversed(constref+P:+TPCharEx):+AnsiString%3B%0Aprocedure+ImplicitConversionTest%3B+inline%3B%0A%0Aimplementation%0A%0Aclass+operator+TPCharEx.:%3D(constref+LHS:+AnsiString):+TPCharEx%3B%0Abegin%0A++with+Result+do+begin%0AP+:%3D+@LHS%5B1%5D%3B%0AL+:%3D+Length(LHS)%3B%0A++end%3B%0Aend%3B%0A%0Aclass+operator+TPCharEx.:%3D(constref+LHS:+ShortString):+TPCharEx%3B%0Abegin%0A++with+Result+do+begin%0AP+:%3D+@LHS%5B1%5D%3B%0AL+:%3D+Ord(LHS%5B0%5D)%3B%0A++end%3B%0Aend%3B%0A%0Afunction+Reversed(constref+P:+TPCharEx):+AnsiString%3B%0Avar+Old,+New:+PChar%3B%0Abegin%0A++SetLength(Result,+P.L+%2B+1)%3B%0A++Old+:%3D+P.P+%2B+P.L%3B%0A++New+:%3D+@Result%5B1%5D%3B%0A++while+Old+%3E%3D+P.P+do+begin%0ANew%5E+:%3D+Old%5E%3B%0AInc(New)%3B%0ADec(Old)%3B%0A++end%3B%0Aend%3B%0A%0Aprocedure+ImplicitConversionTest%3B%0Abegin%0A++WriteLn(Reversed(!'ABCD!'))%3B%0Aend%3B%0A%0Aend.%0A'),l:'5',n:'0',o:'Pascal+source+%231',t:'0')),k:54.64556642679632,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:fpc304,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'0',intel:'0',libraryCode:'1',trim:'1'),lang:pascal,libs:!(),options:'-O3+-Ci-+-Cr-+-g-+-CX+-XXs',source:1),l:'5',n:'0',o:'x86-64+fpc+3.0.4+(Editor+%231,+Compiler+%231)+Pascal',t:'0')),k:44.015665176626996,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compiler:1,editor:1,wrap:'1'),l:'5',n:'0',o:'%231+with+x86-64+fpc+3.0.4',t:'0')),k:1.3387683965766675,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4>
>

Messed up the "Reversed" function a little bit in that example. Fixed
version.
<https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(j:1,lang:pascal,source:'unit+output%3B%0A%0A%7B$mode+ObjFPC%7D%7B$H%2B%7D%0A%7B$modeswitch+AdvancedRecords%7D%0A%7B$ImplicitExceptions+Off%7D%0A%0Ainterface%0A%0Atype+%0A++TPCharEx+%3D+record%0AP:+PChar%3B%0AL:+SizeInt%3B%0Aclass+operator+:%3D(constref+LHS:+AnsiString):+TPCharEx%3B+inline%3B%0Aclass+operator+:%3D(constref+LHS:+ShortString):+TPCharEx%3B+inline%3B%0A++end%3B%0A%0Afunction+Reversed(constref+P:+TPCharEx):+AnsiString%3B%0Aprocedure+ImplicitConversionTest%3B+inline%3B%0A%0Aimplementation%0A%0Aclass+operator+TPCharEx.:%3D(constref+LHS:+AnsiString):+TPCharEx%3B%0Abegin%0A++with+Result+do+begin%0AP+:%3D+@LHS%5B1%5D%3B%0AL+:%3D+Length(LHS)%3B%0A++end%3B%0Aend%3B%0A%0Aclass+operator+TPCharEx.:%3D(constref+LHS:+ShortString):+TPCharEx%3B%0Abegin%0A++with+Result+do+begin%0AP+:%3D+@LHS%5B1%5D%3B%0AL+:%3D+Ord(LHS%5B0%5D)%3B%0A++end%3B%0Aend%3B%0A%0Afunction+Reversed(constref+P:+TPCharEx):+AnsiString%3B%0Avar+Old,+New:+PChar%3B%0Abegin%0A++SetLength(Result,+P.L)%3B%0A++Old+:%3D+P.P+%2B+P.L+-+1%3B%0A++New+:%3D+@Result%5B1%5D%3B%0A++while+Old+%3E%3D+P.P+do+begin%0ANew%5E+:%3D+Old%5E%3B%0AInc(New)%3B%0ADec(Old)%3B%0A++end%3B%0Aend%3B%0A%0Aprocedure+ImplicitConversionTest%3B%0Abegin%0A++WriteLn(Reversed(!'ABCD!'))%3B%0Aend%3B%0A%0Aend.%0A'),l:'5',n:'0',o:'Pascal+source+%231',t:'0')),k:54.64556642679632,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:fpc304,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'0',intel:'0',libraryCode:'1',trim:'1'),lang:pascal,libs:!(),options:'-O3+-Ci-+-Cr-+-g-+-CX+-XXs',source:1),l:'5',n:'0',o:'x86-64+fpc+3.0.4+(Editor+%231,+Compiler+%231)+Pascal',t:'0')),k:44.015665176626996,l:'4',n:'0',o:'',s:0,t:'0'),(g:!((h:output,i:(compiler:1,editor:1,wrap:'1'),l:'5',n:'0',o:'%231+with+x86-64+fpc+3.0.4',t:'0')),k:1.3387683965766675,l:'4',n:'0',o:'',s:0,t:'0')),l:'2',n:'0',o:'',t:'0')),version:4>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] String conversions

[Ben Grasset]

On Wed, Jun 26, 2019 at 5:48 AM Michael Van Canneyt 
wrote:

> I second that.
>
> Michael.
>

I think Ryan probably meant his own custom types. And certainly, you can do
some interesting stuff with operator overloading that mostly avoids the
normal AnsiString overhead. Here's an example.

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

Re: [fpc-pascal] not inlined?

[Ben Grasset]

On Wed, Jun 19, 2019 at 3:40 PM Ryan Joseph  wrote:

> What are the rules with he calling context? I didn’t even know that was a
> factor! I’ll have to look to get some examples.
>

Basically, if you're calling a function marked inline from another
function, the implementation of the function to be inlined has to come
first in the unit.

So for example, the following code generates assembly that is completely
identical for all three functions, because `Proc` gets inlined into `Proc2`
and then through that into `Proc3`.

unit Example;

{$mode ObjFPC}
{$modeswitch AdvancedRecords}

interface

type Letters = (A, B, C);

type
  TRecord = record
procedure Proc; inline;
procedure Proc2; inline;
procedure Proc3;
  end;

implementation

procedure TRecord.Proc;
begin
  WriteLn([B] <= [A, B, C]);
end;

procedure TRecord.Proc2;
begin
  Proc();
end;

procedure TRecord.Proc3;
begin
  Proc2();
end;

end.

If the implementation order was `Proc2` -> `Proc` -> `Proc3`, however,
`Proc3` could still inline away both `Proc` and `Proc2`, but `Proc2` itself
could not inline away `Proc.`

Lastly, if the implementation for `Proc` came after both those for `Proc2`
and `Proc3`, it would not be inlined into either. (I.E. `Proc3` would
directly call `Proc2`, and `Proc2` would directly call `Proc`.)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] not inlined?

[Ben Grasset]

On Wed, Jun 19, 2019 at 2:36 PM Ryan Joseph  wrote:

> The method TDictionary.IsSet is not able to be inlined but why not? What
> are the rules to inlining in FPC? I know calling inherited is not possible
> (makes sense) but I often get this warning and I don’t always understand
> why.
>

It depends a lot on the context you're calling the function-to-be-inlined
from. Can you show more of the code?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] class operator enumerator

[Ben Grasset]

Seems like it's mixed up in some way with the FPC-style enumerator
operator, so the "class" version is recognized but not actually implemented
currently or something.

The normal way for classes/records/objects is to implement a GetEnumerator
function, anyways. Here's an expanded-on version of your example, using
your generic constants feature:

program Test;

{$mode ObjFPC}
{$PointerMath On}
{$modeswitch AdvancedRecords}

type
  generic TConstArray = array[0..N] of T;

  generic TArrayEnumerator = record
  public type
PT = ^T;
  public const
HIGH_INDEX = N;
  private
CurrentIndex: PtrUInt;
DataPointer: PT;
  public
function GetCurrent: T; inline;
class function Create(const A: PT): TArrayEnumerator; static; inline;
function MoveNext: Boolean; inline;
property Current: T read GetCurrent;
  end;

  generic TRec = record
  public type
TRecEnumerator = specialize TArrayEnumerator;
  private
FData: specialize TConstArray;
  public
class operator Initialize(var Rec: TRec);
function GetEnumerator: TRecEnumerator; inline;
  end;

  function TArrayEnumerator.GetCurrent: T;
  begin
Result := DataPointer[CurrentIndex];
  end;

  class function TArrayEnumerator.Create(const A: PT): TArrayEnumerator;
  begin
with Result do begin
  DataPointer := A;
  CurrentIndex := -1;
end;
  end;

  function TArrayEnumerator.MoveNext: Boolean;
  begin
Inc(CurrentIndex);
Result := CurrentIndex <= HIGH_INDEX;
  end;

  class operator TRec.Initialize(var Rec: TRec);
  var I: PtrUInt;
  begin
for I := 0 to N do Rec.FData[I] := I;
  end;

  function TRec.GetEnumerator: TRecEnumerator;
  begin
Result := TRecEnumerator.Create(@FData);
  end;

var
  Arr: specialize TRec;
  Value: SizeInt;

begin
  for Value in Arr do WriteLn(Value);
end.

On Tue, Apr 23, 2019 at 2:08 PM Ryan Joseph 
wrote:

> Is "class operator enumerator” supposed to work or is this a bug that it
> compiles but doesn’t do anything? Seems like it should work.
>
> ===
>
> {$mode objfpc}
> {$modeswitch advancedrecords}
>
> program test;
>
> type
>   TArrayEnumerator = class
> public type
>   TArrayValue = integer;
> public
>   function GetCurrent: TArrayValue;
>   constructor Create(a: pointer);
>   property Current: TArrayValue read GetCurrent;
>   function MoveNext: Boolean;
>   end;
>   TRec = record
> class operator enumerator(a: TRec): TArrayEnumerator;
>   end;
>
> class operator TRec.Enumerator(a: TRec): TArrayEnumerator;
> begin
>   result := TArrayEnumerator.Create(@a);
> end;
>
> function TArrayEnumerator.GetCurrent: TArrayValue;
> begin
> end;
>
> constructor TArrayEnumerator.Create(a: pointer);
> begin
> end;
>
> function TArrayEnumerator.MoveNext: Boolean;
> begin
> end;
>
> var
>   arr: TRec;
>   value: integer;
> begin
>   for value in arr do   //  ERROR: Cannot find an enumerator for the
> type "TRec"
> begin
> end;
> end.
>
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] mode switch madness

[Ben Grasset]

I dunno about setting them globally, but generally I do find modeswitches
rather annoying, as the combination of features is pretty arbitrary, and
they mostly just *disallow* things that couldn't break the code of people
who weren't using those features to begin with if they were allowed.

E.G, I sincerely doubt that anybody has *ever* thought, "man, I sure am
glad that {$mode ObjFPC} does not allowed advanced records. It would be
specifically bad if it did!" because it just doesn't matter if they weren't
using advanced records to start with. It's just a lot of minor rules that
nobody can really explain but that tend to add up in relatively annoying
ways.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[Ben Grasset]

Also, there's:

pgenutil.pas(158,28) Warning: Class types "tenumdef" and "torddef" are not
related

which breaks compilation because the compiler is built with -sew turned on
if you do it through the normal makefiles. I think you need tests before
you do a patch, also? (Unless you already have them ready somewhere and
just didn't upload them yet.)

On Sun, Jan 6, 2019 at 8:36 PM Ryan Joseph 
wrote:

> I updated the github with the requested changes. Is that everything? I’ll
> submit a patch if so.
>
> https://github.com/genericptr/freepascal/tree/generic_constants
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[Ben Grasset]

You still have two C-style operator += instances in pgenutil.pas FYI, that
don't compile with the default settings.

On Sun, Jan 6, 2019 at 8:36 PM Ryan Joseph 
wrote:

> I updated the github with the requested changes. Is that everything? I’ll
> submit a patch if so.
>
> https://github.com/genericptr/freepascal/tree/generic_constants
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[Ben Grasset]

On Sun, Jan 6, 2019 at 4:23 PM Ryan Joseph 
wrote:

> This is exactly the reason I added the feature, there’s no way to extend
> static arrays otherwise! Beyond this one thing I have no idea what to use
> them for. ;)
>

I've got a bunch of stuff in mind actually that I'm waiting on the "final"
version for before I start getting into too seriously. There's a lot that's
possible as far as custom string types and such if you combine this with
operator overloading.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[Ben Grasset]

Just wanted to say, I've been playing around with Ryan's github branch that
contains this functionality and I'm loving it! It really opens up a ton of
interesting possibilities in general, and also a lot of potential for
optimization via constant folding for generic containers that wasn't really
possible previously. Here's a more "advanced" example I threw together of
the kinds of things you can actually do with this (I'm aware the final
syntax for the declarations is going to be slightly different, not that it
matters really):

program Example;

{$Mode ObjFPC}{$H+}{$J-}
{$ModeSwitch AdvancedRecords}
{$PointerMath On}

type
  generic TStaticList = record
  public type
TStaticListEnumerator = record
public type PT = ^T;
strict private
  FFirst, FLast, FCurrent: PT;
public
  class function Create(var List: TStaticList): TStaticListEnumerator;
inline; static;
  function MoveNext: Boolean; inline;
  property Current: PT read FCurrent;
end;
  strict private
Items: array[L..H] of T;
  public
function Low: PtrUInt; inline;
function High: PtrUInt; inline;
procedure Initialize; inline;
function GetEnumerator: TStaticListEnumerator; inline;
  end;

  class function TStaticList.TStaticListEnumerator.Create(var List:
TStaticList): TStaticListEnumerator;
  begin
with Result do begin
  FFirst := @List.Items[L];
  FLast := @List.Items[H];
  FCurrent := FFirst - 1;
end;
  end;

  function TStaticList.TStaticListEnumerator.MoveNext: Boolean;
  begin
Inc(FCurrent);
Result := (FFirst <> FLast) and (FCurrent <= FLast);
  end;

  function TStaticList.Low: PtrUInt;
  begin
Result := L;
  end;

  function TStaticList.High: PtrUInt;
  begin
Result := H;
  end;

  procedure TStaticList.Initialize;
  var I: PtrUInt;
  begin
for I := Low() to High() do Items[I] := T(I);
  end;

  function TStaticList.GetEnumerator: TStaticListEnumerator;
  begin
Result := TStaticListEnumerator.Create(Self);
  end;

var
  AsciiList: specialize TStaticList;
  P: PChar;

begin
  AsciiList.Initialize();
  for P in AsciiList do Write(P^);
end.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Default properties wiki

[Ben Grasset]

Nice! Very thorough. I think most of these are very useful.

On Tue, Dec 18, 2018 at 2:32 AM Ryan Joseph 
wrote:

> I decided to make a wiki going over all the details of default properties
> which I’ve covered so far, including various usage examples. There’s some
> questionable stuff in here and it’s actually a pretty complicated concept
> so I wanted to share it publicly.
>
> Some changes and things of interest:
>
> - While exploring the idea I’ve made it possible to enable multiple
> defaults because it’s trivial to just stop the search at the first default
> if it’s decided to make not sense. There’s some potential for multiple
> “implements” defaults properties to ease delegation which is interesting.
>
> - Because it’s technically possible default properties on array types are
> enabled. This makes it possible to index into an array wrapped in a record
> using [] syntax and for..in loops on the record itself without making an
> enumerator object.
>
> - For certain statements like if..then it’s possible to access the default
> property (for ordinal types like boolean). I think this is going to be
> helpful for nullable types in particular so it was added.
>
> - At the end I included some notes on technical details so you can easily
> find what changes I made in the compiler. I wasn’t sure at all how to
> implement this but this what I’ve arrived at as the best solution. Lots of
> cleanup required of course if we decided this is the correct way forward.
>
> http://wiki.freepascal.org/default_properties
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Default record const values

[Ben Grasset]

On Sat, Nov 10, 2018 at 9:03 PM Ryan Joseph 
wrote:

> Not sure how default fields in generics help here. I just thought it would
> be nice if FPC supported this so we can init records at compile time
> easier. I’d prefer default struct fields like C++ has but typed const
> defaults would be an improvement.
>

I guess I just meant that the other work you did recently seems (to me) to
be in roughly the same "category" of functionality, and that it was also
proof that there's not a whole lot of distance to close as far as the
actual code required to implement it in FPC with regards to that kind of
thing.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Constants in generics

[Ben Grasset]

On Thu, Nov 8, 2018 at 11:50 PM Ryan Joseph 
wrote:

> Question: should other consts besides integers be allowed? I don’t think
> it makes sense personally to use strings, floats or sets but maybe I’m
> wrong.
>

As a daily FPC user there's nothing I find more annoying than compiler
restrictions that are visibly artificial, so I'd say you should definitely
allow basically anything that's physically possible to allow in that
context.
*Someone* will find it useful, trust me. I can already think of various
uses for string constants as generic parameters that I certainly would have
already done in the past if I could have, for example.

On Thu, Nov 8, 2018 at 11:50 PM Ryan Joseph 
wrote:

>
>
> > On Nov 9, 2018, at 4:28 AM, Florian Klämpfl 
> wrote:
> >
> > I like the idea of const in generics, but it needs serious cleanup when
> it's working:
>
> Question: should other consts besides integers be allowed? I don’t think
> it makes sense personally to use strings, floats or sets but maybe I’m
> wrong.
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Default record const values

[Ben Grasset]

On Sat, Nov 10, 2018 at 4:06 AM Ryan Joseph 
wrote:

> Should’t this work? This would be a good way to set default record values
> but it doesn’t seem to be supported.


Personally I think the answer here is keep working on your new/alternate
implementation of default field functionality! It's a missing puzzle piece
for FPC generics in many ways.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Default properties first draft

[Ben Grasset]

AFAIK you need to submit a ".patch" file with your changes against the most
recent trunk revision to the bugtracker (with the category set to "patch",
obviously.) I doubt it'll get considered seriously or looked at at all
otherwise. For what it's worth, I did do a checkout of your branch and then
a merge to get everything fully up to date, and when I went to do a
full-tree build (compiler, RTL, everything) it raised a nonsensical error
in the FCL-XML package in the "dom-html.pp" file, complaining that a call
to GetItem for one of the list classes there didn't have enough parameters
(which is not true.)

That function was being read from through a property, so it seems like you
may possibly have broken something somewhere.

On Fri, Oct 19, 2018 at 12:01 PM Ryan Joseph 
wrote:

> I finally finished what I think is first draft of default properties.
> Since it already took me so much time to just get the basics of the
> compiler figured out I thought I’d post this commit from GitHub and ask if
> I did anything seriously wrong or stupid. There are multiple ways I could
> approach this problem but I may have not achieved it a proper way
> considering the architecture of the compiler, which I admittedly don’t
> understand well.
>
> How should I present for consideration at this stage? If anyone on the
> compiler team can look at the commit to tell me anything that would be
> helpful, or let me know if you need this in some other form that you could
> actually compile (I understand the compiler uses svn but I only know git).
> I have some demos of the basics mostly working but I have
> questions/problems I wasn’t able to solve on my own.
>
>
> https://github.com/genericptr/freepascal/commit/e2992620e2e85d1100f60d13472571b8ebbf0bac
>
> Here’s an example test in case people forgot what this was about.
>
> ==
>
> program default_property_test_16;
> uses
> fgl;
>
> type
> generic TAuto = record
> m_object: T;
> property obj: T read m_object; default;
> class operator Initialize(var a: TAuto);
> class operator Finalize(var a: TAuto);
>   end;
>
> type
>   TObjectAuto = specialize TAuto;
>   TStringList = specialize TFPGList;
>   TStringListAuto = specialize TAuto;
>
> class operator TAuto.Initialize(var a: TAuto);
> begin
>   a.m_object := T.Create;
> end;
>
> class operator TAuto.Finalize(var a: TAuto);
> begin
>   a.m_object.Free;
> end;
>
> var
> list: TStringListAuto;
> str: string;
> i: integer;
> begin
> list.Add('foo');
> list.Add('bar');
> for str in list do
> writeln(str);
> for i := 0 to list.count - 1 do
> writeln(list[i]);
> end.
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Indexing into records using [] property

[Ben Grasset]

If the absence of dereferencing is the most important thing to you, you
could do something like this:

program Example;

{$mode ObjFPC}{$H+}
{$modeswitch AdvancedRecords}

type
  TVec2 = record
X, Y: Integer;
  end;

  TVec2Array = array of TVec2;

  TVecArray = record
  strict private
Values: TVec2Array;
  public
class function Create(const ACapacity: Integer = 16): TVecArray;
inline; static;
procedure Resize(const NewLength: Integer); inline;
property I: TVec2Array read Values write Values;
  end;

  class function TVecArray.Create(const ACapacity: Integer = 16): TVecArray;
  begin
Result := Default(TVecArray);
SetLength(Result.Values, ACapacity);
  end;

  procedure TVecArray.Resize(const NewLength: Integer);
  begin
SetLength(Values, NewLength);
  end;

begin
  with TVecArray.Create(0) do
  begin
Resize(1);
I[0].X := 100;
I[0].Y := 100;
  end;
end.

The only downside there is that you obviously don't quite get the real
"default" property syntax.

On Wed, Oct 10, 2018 at 11:06 PM Ryan Joseph 
wrote:

> I’d like to know if there is a solution to the problem of indexing into
> records using [] properties.
>
> In the example below I have an array of records (a dynamic array for the
> example) and I’d like to use the [] property to index into the values. The
> problem is because the array holds records I need to return a pointer to
> the record so I can access the fields. In the end the only problem is I
> need to dereference the pointer using ^.
>
> Are there any solutions we could propose to this? Some ideas:
>
> 1) I looks like we could have a “var” modifier for function results but
> that concept has only ever existed in function params (like & in C++).
>
> function GetValue(i: integer): TVec2; var;
>
> 2) Maybe a modifier added to GetValue which tells the compiler to call the
> function (and result) like a pointer when the indexer is used?
>
> 
>
> type
> TVec2 = record
> x, y: integer;
> end;
> TVec2Ptr = ^TVec2;
> TVec2Array = array of TVec2;
>
> type
> TVecArray = class
> values: TVec2Array;
> function GetValue(i: integer): TVec2Ptr;
> procedure Resize(newLength: integer);
> property Indexer[i: integer]: TVec2Ptr read GetValue;
> default;
> end;
>
>
> function TVecArray.GetValue(i: integer): TVec2Ptr;
> begin
> result := @values[i];
> end;
>
> procedure TVecArray.Resize(newLength: integer);
> begin
> SetLength(values, newLength);
> end;
>
> var
> arr: TVecArray;
> begin
> arr := TVecArray.Create;
> arr.Resize(1);
> arr[0]^.x := 100;
> arr[0]^.y := 100;
> end.
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Operator overload bug

[Ben Grasset]

On Sat, Aug 4, 2018 at 10:38 AM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> On 28.07.2018 16:38, John Doe wrote:
> > On Mon, Jul 23, 2018 at 1:49 PM, Sven Barth via fpc-pascal
> >  > > wrote:
> >
> > Ryan Joseph  > > schrieb am Mo., 23. Juli 2018,
> > 17:35:
> >
> >
> > > On Jul 23, 2018, at 12:00 AM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org
> > > wrote:
> > >
> > > Yes, it's a bug, so please report it.
> >
> > Thanks, reported. The severity is “minor” which I guess is
> correct.
> >
> >
> > "Minor" is the default severity. We have made the value not editable
> > by users, cause they'd more often than not consider their bugs as
> > more severe than really severe bugs.
> >
> > Regards,
> > Sven
> >
> >
> > Someone posted a working patch for this on the bugtracker report Ryan
> > made, just to let you know.
>
> Working, yes, complete, no.
>
> Nevertheless I fixed the problem in r39554.
>
> Regards,
> Sven


Would be interested to know what I missed with the patch for future
reference (and for better understanding of the compiler codebase.)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Operator overload bug

[Ben Grasset]

It's still open by my view, with "new" status:

https://bugs.freepascal.org/view.php?id=34021

On Tue, Jul 31, 2018 at 11:47 AM, Ryan Joseph 
wrote:

>
>
> > On Jul 30, 2018, at 4:11 PM, Ben Grasset  wrote:
> >
> > If you don't have an SVN patch utility handy you could probably just
> look at it and apply it to your sources yourself. The final version looks
> like it's just two lines changed in a single file.
>
> Thanks for fixing that Ben. I don’t have SVN access (I did some time long
> ago when I was doing the Objective-C stuff but I forgot it) so there’s not
> much I can do. Does the compiler team know about the patch and will they
> apply it? I saw the bug report was closed so I didn’t want them to not see
> it.
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Operator overload bug

[Ben Grasset]

By looks like I meant, "is", not sure why I wrote that. (I'm Akira1364, by
the way.)

On Mon, Jul 30, 2018 at 6:11 PM, Ben Grasset  wrote:

> If you don't have an SVN patch utility handy you could probably just look
> at it and apply it to your sources yourself. The final version looks like
> it's just two lines changed in a single file.
>
> On Mon, Jul 30, 2018 at 11:29 AM, Ryan Joseph 
> wrote:
>
>>
>>
>> > On Jul 28, 2018, at 8:38 AM, John Doe 
>> wrote:
>> >
>> > Someone posted a working patch for this on the bugtracker report Ryan
>> made, just to let you know.
>>
>> Thanks, what do we do now? The patch is sitting there but how does it get
>> applied?
>>
>> https://bugs.freepascal.org/view.php?id=34021
>>
>> Regards,
>> Ryan Joseph
>>
>> ___
>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>>
>
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Operator overload bug

[Ben Grasset]

If you don't have an SVN patch utility handy you could probably just look
at it and apply it to your sources yourself. The final version looks like
it's just two lines changed in a single file.

On Mon, Jul 30, 2018 at 11:29 AM, Ryan Joseph 
wrote:

>
>
> > On Jul 28, 2018, at 8:38 AM, John Doe 
> wrote:
> >
> > Someone posted a working patch for this on the bugtracker report Ryan
> made, just to let you know.
>
> Thanks, what do we do now? The patch is sitting there but how does it get
> applied?
>
> https://bugs.freepascal.org/view.php?id=34021
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

How is auto more "ugly" than literally any other modifier in the entire
language? They're all just english words, of varying length. Also building
features on top of a language will always result in worse performance than
having them be a part of it.

On Wed, Jul 25, 2018 at 10:05 AM, R0b0t1  wrote:

> On Mon, Jul 23, 2018 at 11:11 AM, Ryan Joseph
>  wrote:
> >
> >
> >> On Jul 22, 2018, at 4:54 AM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >>
> >> And that's why there are people who *do* care about it. Of course you
> can put everything and the kitchen think into a language. But if it doesn't
> fit the language than you'll simply end up with a melting pot that doesn't
> feel coherent. Also while people might not consciously think about the
> spirit of the language I think they'll feel if the language is coherent
> with itself or not.
> >
> > The spirit of the language is really hard to define in my opinion. I
> think we all agree that if we changed begin/end to {} we would all be
> offended but why again is “auto” not in the spirit of the language? It
> looks like Pascal to me. Calling Free at the end of blocks and inside
> destructors feels like Pascal to me.
> >
> > Telling the compiler to call it for me by typing “auto” instead of
> “Free” doesn’t feel non-pascal. I don’t get it.
> >
> > type
> > TMyClass = class
> > private
> > list: TFPGList; auto;
> > otherList: TFPGList; auto;
> > end;
> >
> > var
> > c: TMyClass; auto;
> >
> > begin
> > c := TMyClass.Create;
> >
>
> This looks ugly. It also introduces modifiers to variable
> declarations. Some features should not be part of the language, they
> should be built on top of it.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Operator overload bug

[Ben Grasset]

Why wouldn't you just use the TIntegerArray type that's implicitly declared
in the "Objpas" unit by default, if you were going to do that? Doesn't
address the underlying issue anyways.

On Sun, Jul 22, 2018 at 9:10 PM, Vojtěch Čihák 
wrote:

> Hello,
>
>
>
> you can define type:
>
>
>
> TIntArray = array of Integer;
>
>
>
> operator + (left: TMyClass; right: TIntArray): TMyClass; overload;
>
>
>
> and with retyping it works:
>
>
>
> c := c + TIntArray([1, 2, 3]);
>
>
>
> V.
>
>
>
>
>
> __
> > Od: Ben Grasset 
> > Komu: FPC-Pascal users discussions 
> > Datum: 23.07.2018 02:16
> > Předmět: Re: [fpc-pascal] Operator overload bug
> >
> I'd say it's a bug in the sense that the compiler assumes something
> starting with "[" and ending with "]" can only possibly be a set in that
> context.
>
> On Sun, Jul 22, 2018 at 12:10 PM, Ryan Joseph 
> wrote:
>
>> I mentioned this as an aside a while ago but I don’t remember getting a
>> response so I’d like to formally reintroduce the issue.
>>
>> ___
>> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
>
>
> --
>
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Operator overload bug

[Ben Grasset]

Also, one other thing: you should *really* be specifying the
right-hand-side array parameter as "const" there. If you don't, it will be
copied in its entirety instead of being passed by reference. Basically just
always pass everything as "const"  (or "constref" if it's specifically a
record) unless you literally can't.

On Sun, Jul 22, 2018 at 12:10 PM, Ryan Joseph 
wrote:

> I mentioned this as an aside a while ago but I don’t remember getting a
> response so I’d like to formally reintroduce the issue.
>
> Should I file a bug report for this or is it expected behavior? Personally
> I’d really like to get implicit array overloads working properly.
>
>
>
>
> program test;
>
> type
> TMyClass = class
> end;
>
> operator + (left: TMyClass; right: array of integer): TMyClass; overload;
> var
> i: integer;
> begin
> for i in right do
> writeln('add ', i);
> result := left;
> end;
>
> var
> c: TMyClass;
> begin
> c += [1, 2, 3]; // ERROR: Operator is not overloaded: "TMyClass" +
> "Set Of Byte"
> end.
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Operator overload bug

[Ben Grasset]

I'd say it's a bug in the sense that the compiler assumes something
starting with "[" and ending with "]" can only possibly be a set in that
context.

On Sun, Jul 22, 2018 at 12:10 PM, Ryan Joseph 
wrote:

> I mentioned this as an aside a while ago but I don’t remember getting a
> response so I’d like to formally reintroduce the issue.
>
> Should I file a bug report for this or is it expected behavior? Personally
> I’d really like to get implicit array overloads working properly.
>
>
>
>
> program test;
>
> type
> TMyClass = class
> end;
>
> operator + (left: TMyClass; right: array of integer): TMyClass; overload;
> var
> i: integer;
> begin
> for i in right do
> writeln('add ', i);
> result := left;
> end;
>
> var
> c: TMyClass;
> begin
> c += [1, 2, 3]; // ERROR: Operator is not overloaded: "TMyClass" +
> "Set Of Byte"
> end.
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

Isn't Delphi compatibility a major ongoing goal of both FPC and Lazarus,
though?

On Fri, Jul 20, 2018 at 10:01 AM, R0b0t1  wrote:

> On Fri, Jul 20, 2018 at 12:20 AM, Sven Barth via fpc-pascal
>  wrote:
> > Am 20.07.2018 um 00:53 schrieb Ben Grasset:
> >>
> >> If a feature works as intended and is useful (which is all that
> matters),
> >> how is it "blind copying"?
> >
> > Because a feature might change the language in a way that's not in the
> > spirit of the language. Look at how Delphi implemented attributes:
> they're
> > declared in front of the types, fields, parameters, whatever, simply
> copied
> > from how C# implemented them while in the spirit of Pascal they should
> have
> > been *after* the declarations.
> >
>
> This is what bothers me about some of the Delphi extensions that are
> requested, but also some things that are already in FPC. And like
> other people have said: now it's too late. It's there forever, or a
> length of time that is just as good when talking about software.
>
> It's not to say all of these things are bad - it's just I wish more
> thought would have gone into them. Perhaps that would mean changing
> the feature so much that it doesn't resemble what was originally
> proposed.
>
> Cheers,
>  R0b0t1
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

On Fri, Jul 20, 2018 at 1:20 AM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
>
> Because a feature might change the language in a way that's not in the
> spirit of the language. Look at how Delphi implemented attributes: they're
> declared in front of the types, fields, parameters, whatever, simply copied
> from how C# implemented them while in the spirit of Pascal they should have
> been *after* the declarations.
>
> Regards,
> Sven
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>


C# itself is heavily inspired by Delphi though, as it's another Anders
Hejlsberg project. I fail to see what the "spirit of the language" has to
do with anything as far as attributes, either.

Shouldn't the attribute tags just be put wherever it's easiest for the
compiler to deal with them?

I think the vast majority of people care far more about how *useful
Pascal actually
is in real life* than they do
about whether or not it fulfills some not-well-defined notion of "spirit".

Also, as far as I can tell, most of the people who use FPC would consider
the Delphi way to be the correct or normal way of doing things in the first
place.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

If a feature works as intended and is useful (which is all that matters),
how is it "blind copying"?

On Thu, Jul 19, 2018 at 7:25 AM, Marco van de Voort  wrote:

>
> In our previous episode, Ryan Joseph said:
> >
> > That?s pretty disheartening honestly. So there was a useful feature users
> > could be leveraging but it was turned down because it didn?t fit into
> some
> > paradigm or something like that.  Sorry to hear that.
>
> No, because blind copying from one language to another is not always
> feasible.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

I'm quite certain a lot of people would disagree with you on that. But
there you have the reason why the "having to read code you don't like
looking at" argument makes no sense. It's completely subjective.

On Thu, Jul 19, 2018 at 12:37 AM, Martin Schreiber 
wrote:

> On Wednesday 18 July 2018 23:30:19 Ben Grasset wrote:
> >
> > For example, does *anyone *actually think the strange "lowercase
> > everything" capitalization style the compiler uses is "readable"
> nowadays?
>
> Yes.
>
> Martin
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

Yawn, more F.U.D.

On Wed, Jul 18, 2018 at 9:20 PM, Reimar Grabowski  wrote:

> On Wed, 18 Jul 2018 16:12:41 -0600
> Ryan Joseph  wrote:
>
> > Personally for my taste I would like to just add a little keyword to the
> end of the variable so I don’t have to worry about it later.
>
> 1) little, innocent deallocation feature A
> 2) other user comes along: "We already have A, can it be improved a little
> to work in situation X, too?"
> 3) n other users come along
> 4) "Pascal garbage collection - You have earned a trophy!" ;)
>
> R.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

>  For high performance in a game engine you should not allocate/deallocate
memory in the game loop at all (can be done, have done it*, so no arguing
there).

This is a massive oversimplification. Many *modern* game engines do not
even have the kind of loop you're thinking of.

>  Outside the game loop you do not need such a 'high performance' anymore.

Says who?

On Wed, Jul 18, 2018 at 9:08 PM, Reimar Grabowski  wrote:

> On Wed, 18 Jul 2018 15:39:58 -0600
> Ryan Joseph  wrote:
>
> > 1) For high performance situations it really does matter...  I was
> doing a game engine recently and doing the create/free thing when I knew I
> didn’t have to was painful.
>
> For high performance in a game engine you should not allocate/deallocate
> memory in the game loop at all (can be done, have done it*, so no arguing
> there). Increases the performance and frees you of doing "the create/free
> thing", that's killing two birds with one stone. Outside the game loop you
> do not need such a 'high performance' anymore.
>
> R.
>
> *The game uses procedural/random level generation and depending on skill
> there can be over 300 levels in a single run, with all
> allocation/deallocation happening before/after a run.
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

Well, the array TFPGList uses for storage would still be allocated on the
heap in any case no matter what...

On Wed, Jul 18, 2018 at 3:10 PM, Ryan Joseph 
wrote:

>
>
> > On Jul 18, 2018, at 12:47 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > A point against stack based classes is that Object Pascal's object model
> is highly geared towards polymorphism (with things like virtual class
> methods and constructors that C++ does not support). You can't make use of
> this however if the class is instantiated on the stack.
>
> Isn't that what Object does though? Something strange happened when FPC
> implemented classes because they didn’t unify the model between stack and
> heap. That was the obvious thing to do in my mind.
>
> I remember back when I was using Objects and doing like C++ where I used
> new to allocate on the heap then dereference using ^. to access members.
> When classes came around I thought, this is nice, no more new and ^.
> everywhere and easier to use. Fast forward to today and I want the option
> to go stack based back but the models have diverged so much it’s not
> possible anymore.
>
> Just now I wanted to use TFPGList and I wanted it on the stack because I
> didn’t want it to survive outside the function I was in. What do I do now?
>
> Regards,
> Ryan Joseph
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

Ironically, type safety is a good argument for the further development of
various generics related things. Yet unfortunately I don't think anyone is
going to stop using the Contnrs unit in new code anytime soon...
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

The "I might have to read code I don't like" argument people seem to keep
resorting to comes off as rather childish, frankly. It's entirely
subjective and specific to each person.

For example, does *anyone *actually think the strange "lowercase
everything" capitalization style the compiler uses is "readable" nowadays?
It seems rather unlikely that's what would have ended up being used if FPC
was started today.

On Wed, Jul 18, 2018 at 4:57 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> Ryan Joseph  schrieb am Mi., 18. Juli 2018,
> 21:37:
>
>>
>>
>> > On Jul 18, 2018, at 12:44 PM, Sven Barth via fpc-pascal <
>> fpc-pascal@lists.freepascal.org> wrote:
>> >
>> > And to give you a slightly different example: around a year ago or so I
>> implemented a IfThen() intrinsic that works like the if-statement, but as
>> an expression (like C's trinary ?: operator including not evaluating the
>> branch not taken). The majority of the users seemed to like it, but reasons
>> against it surfaced and so I reverted it again.
>> >
>>
>> That’s pretty disheartening honestly. So there was a useful feature users
>> could be leveraging but it was turned down because it didn’t fit into some
>> paradigm or something like that. Sorry to hear that.
>>
>
> Due to it essentially being an overload of IfThen in the Math unit there
> was the possibility of confusion not to mention that it would be the only
> function like construct that would not evaluate all parameters. When I'm
> going to add it again I'm probably going the Oxygen route and use an
> if-expression enabled with a modeswitch 🤷‍♀️
>
>
> Since I’ve been using FPC in 2003-2004 the language has never forced any
>> of its new features on me and I can still program Pascal like I did when I
>> started in the 90’s. Forcing me to use features is where my line is crossed
>> but I struggle to understand why we’re withholding good ideas from users to
>> this extent.
>>
>
> The problem with any language feature is this: even if I don't use it
> someone else will and I'll sooner or later have to read such code. So in
> that sense any language feature is forced upon everyone.
>
> Regards,
> Sven
>
>>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Syntax changes suggestions

[Ben Grasset]

They observably *are* good though, now that they've been implemented,
especially in combination with management operators. These are features
that objectively make FPC better. I'm unsure what the original concern
could have even possibly been, other than some vague notion of "well,
records didn't have methods before, so they shouldn't now!".

Classes are unsuitable performance-wise for many use cases, and TP objects
lack important features such as variant parts. Advanced records are a great
lightweight in-between point.

On Tue, Jul 17, 2018 at 4:15 PM, Sven Barth via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:

> Am 17.07.2018 um 20:00 schrieb Ryan Joseph:
>
>>
>> On Jul 17, 2018, at 11:27 AM, Jim Lee  wrote:
>>>
>>> Likewise, "modern" programming languages are all converging on a common
>>> feature set, like cultural cross-pollination.
>>>
>> if that’s our mindset then how do we account for times when we’ve
>> actually identified a common pattern that a language feature could address?
>> I’m thinking of things like methods in records, for..in loops etc… that
>> made it into the language and are widely adopted and enjoyed.
>>
> Those specific features you mention were added because of Delphi
> compatibility not because someone thought they are good. Florian even
> likened records with methods to a can of worms before they were implemented.
>
> Regards,
> Sven
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: default namespaces

[Ben Grasset]

Cool I guess. Kind of seems not very important at all though. FPC lacks
compatibility with current Delphi in various other far more significant
areas...


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Proposal for new Free Pascal logo

[Ben Grasset]

I'm not at all getting why people think it's "kitten-like." Have you guys
ever actually seen a kitten? This logo looks like a cheetah, as it's
presumably supposed to. And a much better/more tasteful cheetah than that
ancient, annoying "running" GIF at the top of all the Free Pascal websites
honestly.

On Fri, Apr 6, 2018 at 12:27 PM, Reimar Grabowski  wrote:

> On Fri, 6 Apr 2018 09:53:19 +0700
> Mr Bee via fpc-pascal  wrote:
>
> > Lock-in strategy is just a term in business, but it never really locks
> > anybody into anything. You won't be punished if you don't use Swift on
> > Apple's platform or C# on Microsoft's platform. You're still free to use
> > anything on any platforms. But usually you'll get many benefits...
>
> The benefits being mostly that you don't have the disadvantages especially
> introduced for not using it?
>
> > Because you mix the whole things up. Branding is important but it doesn't
> > need to represent the company/product literally.
> But it needs to represent.
>
> > A brand is like our name.
> No, it's not.
>
> R.
>
> P.S.: Cute logos s*ck
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal