Feature request: hard type creation/declaration

[Kays]

[…] in Wi████s […]

I voted No because this feels like a design flaw. Numeric handles are low‑level. Pascal is a high‑level programming language.

[…] [enumeration data types won’t] do. They are limited to 4 [bytes]. […]

So extend them?

[440bx]

No wonder... smh.

[Martin_fr]

Another work around (just in case you consider using one until...).
But maybe you tried that one already too.

Different pointers are assignment incompatible.

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

1. program Project1;
2. type
3.   TDummyFoo = record end;
4.   TDummyBar = record end;
5.   TFooHandle = ^TDummyFoo;
6.   TBarHandle = ^TDummyBar;
7. var
8.   a: TFooHandle;
9.   b: TBarHandle;
10.  
11. begin
12. a:= b; // fails
13. end.
14.  

Not tested anything else...

[Thaddy]

[…] in Wi████s […]

I voted No because this feels like a design flaw. Numeric handles are low‑level. Pascal is a high‑level programming language.

[…] [enumeration data types won’t] do. They are limited to 4 [bytes]. […]

So extend them?

Note they are not limited to 4 bytes but platform. On 64 bit platforms it is 8 bytes.

[Khrys]

I think this would be a useful feature, but unfortunately I don't think it'll be implemented after seeing @Warfley's demonstration on how deeply ingrained the current behavior is within the compiler.

Here's my suggestion for a workaround: define a generic record type with a dummy parameter that is different for each specialization. This ensures that all distinct handle types are truly incompatible while still having the relevant operators defined (explicit assignment, equal, not equal). Defining just one such advanced record and declaring handle types like  HWND = type THandle  would discard the operator overloads and make the derived types much less useful.

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

1. type
2.   generic THandle<const Name: String> = record
3.   private type
4.     TSelf = specialize THandle<Name>;
5.   strict private
6.     Value: PtrInt;
7.   public
8.     class operator explicit(const Self: TSelf): PtrInt;
9.     class operator explicit(Ordinal: PtrInt): TSelf;
10.     class operator  =(const A, B: TSelf): Boolean;
11.     class operator <>(const A, B: TSelf): Boolean;
12.   end;
13.  
14. class operator THandle.explicit(const Self: TSelf): PtrInt;
15. begin
16.   Result := Self.Value;
17. end;
18.  
19. class operator THandle.explicit(Ordinal: PtrInt): TSelf;
20. begin
21.   Result.Value := Ordinal;
22. end;
23.  
24. class operator THandle.=(const A, B: TSelf): Boolean;
25. begin
26.   Result := (A.Value = B.Value);
27. end;
28.  
29. class operator THandle.<>(const A, B: TSelf): Boolean;
30. begin
31.   Result := (A.Value <> B.Value);
32. end;

Only around 30 lines for the ability to write code like this:

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

1. type
2.   HBITMAP = specialize THandle<'HBITMAP'>;
3.   HWND    = specialize THandle<'HWND'>;
4.  
5. procedure Test(var Window: HWND; var Bitmap: HBITMAP);
6. begin
7.  
8.   if Window = HWND(0) then  // OK
9.     Window := HWND(-1);     // OK
10.  
11.   if Bitmap = -1 then;      // Error: Operator is not overloaded: "<record type>" = "ShortInt"
12.     Bitmap := Window;       // Error: Incompatible types: got "THandle<output.Constant String>" expected "THandle<output.Constant String>"
13. end;

Granted, the error messages aren't the most insightful, but at least it stops semantically invalid code from being compiled.

[MarkMLl]

Do you ever have something actually useful to the topic ? or you have some uncontrollable need to pretend you know way more than you actually do ?

FFS, you've asked for a useful feature that a number of us believe should be implemented. Do you /rally/ have to insult senior members of the community to the detriment of everybody else?

The best way of never seeing anything like this would be for the people who want it to look like utter twats.

MarkMLl

[Martin_fr]

Moderation note: Language please. (all parties).

[MarkMLl]

I think that if this feature is implemented, then later the code will immediately be littered with a bunch of type conversions that will only worsen the readability and clarity of the code.

The biggest obvious problem is numeric  constants. But if the current untyped constants were, by definition, compatible with any numeric type that would remove the requirement for a lot of casts.

Apropos the overall difficulty, one workaround would be if type declarations containing an explicit "type" were always hard types, i.e. not compatible with other integer types etc.

Frankly, I'm unconvinced by Warfley's explanation of how numeric types are defined and implemented. Basically, what he's told us is that integers are an ordered set (without the possibility of intermediate values): but that's the basic mathematical definition of an integer.

Here's my suggestion for a workaround: define a generic record type with a dummy parameter that is different for each specialization.

Yes, I cited that earlier in the thread. However that's still thirty lines that works only with the main branch of the compiler: what we need is a single-line declaration that works as would be reasonably expected.

Numeric handles are low‑level. Pascal is a high‑level programming language.

In which case why not drop this pretence that Pascal is suitable for systems programming? Drop the pretence that it's good for talking directly to the OS, and that it's suitable for embedded programming.

This is something that's been running for 30+ years: when VB came out it needed (V)C++ to write controls etc., while Anders's Pascal Compiler- both Turbo and Delphi- was general-purpose.

However in the specific case of the handle example: handles, should never, by definition, be amenable to numeric manipulation by application code. If they're compatible with arithmetic types at the level of application code then something's broken... or something is about to be broken when a less-than-experienced coder gets his mitt on it.

And half the point of this community is to try to attract new FPC and Lazarus users...

MarkMLl

[MarkMLl]

Moderation note: Language please. (all parties).

Mea culpa, my apologies to the moderators and community.

But sometimes I feel that certain people are not content with merely presenting an argument to prove their opponent wrong, but insist on demeaning him and the validity of his expertise which will invariably backfire.

MarkMLl

[440bx]

Do you /rally/ have to insult senior members of the community to the detriment of everybody else?

I didn't insult him.  I pointed out facts.

[marcov]

Moderation note: Language please. (all parties).

Mea culpa, my apologies to the moderators and community.

But sometimes I feel that certain people are not content with merely presenting an argument to prove their opponent wrong, but insist on demeaning him and the validity of his expertise which will invariably backfire.

Then you track a recent couple of such posts and report them, under no circumstance you start bickering in the threads. The constant discussion and veiled insults to intelligence has to cease, it has become toxic.

[Warfley]

However in the specific case of the handle example: handles, should never, by definition, be amenable to numeric manipulation by application code. If they're compatible with arithmetic types at the level of application code then something's broken... or something is about to be broken when a less-than-experienced coder gets his mitt on it.

That concept is called an opaque type and some languages like Swift or Haskell have them. It's a type the internals of which you do not know about or at best can make some assumptions about (like that it overloades the = and <> operators). C has them also for structs/records but only allows to access them via pointer.

Pascal only has a few very specific opaque types, there are untyped pointers which are a pointer to an opaque type, there is the magical "File" types (like file of XYZ) which are a class of opaque types and then theres Variant which is an implementation specific opaque type.

But Pascal does not have any user definable opaque types. There are simple types, which are basically defined as ordered sets, where Subrange types are defined as subsets of the number plane (and integer, byte, etc. are just instances of that), real types and enumeration types. And then there are composite types like arrays and records.

Now opaque types can be added to this mix, but the question is how the opaque type should be handled. Because Pascal is a relatively low level language, unlike for example Haskell or Swift, there needs to be the decision if the opaque type should fix memory layout or fix interfaces.
Extended Pascal has introduced an opaque typesystem called Schemata, afaik it was never put into practice, but at it's core it's a mix between interfaces and generics. It can be resolved during compile time like generics, or at runtime using pointers (in theory, as I said theres probably no real implementation out there).
But this would not be quite fitting for Handles as Schemata do not define the memory layout but only the interfaces of the type (like opaque types in Swift or go).

What handles would need would be some information about the memory layout but no information about the interface. Basically just a "Binary blob" type. Which would technically be possible to implement, but why not just use:

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

1. TMyHandle = record data: array[0..HANDLESIZE-1] of Byte end;

Now you have created a new type which has absolutely no defined interface other than it is assignable to itself and allowing raw byte access.
If you need additional interfaces you can define them yourself (e.g. by overloading the explicit cast operator and/or the comparison operators = and <>).

So I do not see why you would need to introduce a new kind of type to the language.

[Martin_fr]

Back to the topic.

Out of interest.... If that feature existed, may I assume you would want to have (or do your own) definition of Windows API calls? So that e.g. "setwindowpos" can not be called with anything but a HWND as first argument?

And (as you stated yourself earlier), if a similar function would take special values, such as invalide_handle, then there had to be an INVALID_HWND.

But, and this is my question, what would you do about a function such as SelectObject?
https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-selectobject

The 2nd argument can be a Bitmap, Font, or other Handle?

So now, you don't just need distinct types, you need types that also have some sort of inheritance / parent-type?

Or would you rather add lots of overloaded functions?
See https://learn.microsoft.com/en-us/windows/win32/api/handleapi/nf-handleapi-closehandle it takes more than a dozen different types of handles.

I am not even sure that classic inheritance would solve the Windows API, there may be some types in different groups...

[Martin_fr]

So I do not see why you would need to introduce a new kind of type to the language.

Because (as far as I understand) he feels that such a type is needed commonly enough to simplify the definition.

And also so that certain operators should automatically already exists. So it is not needed to add your own unit of 10 to 30 lines to define all the needed ops.

His example was that, in the record case, if you don't have an operator overload, then you can not do
    TDistinctHandle(0)

Though, on that actually, I think if there was a build in type, then it should not allow that either.
Because either
- the type is numeric/ordinal and comes with all that we have
- It is not / It is a binary blob, it is opaque.

But if it is truly opaque, then even its size is not know (some Pascal code does that for pointed to types that are declared an empty record).

If the size is not known (to the user code), then you shouldn't be able to cast a number to it either.  Because that would imply that it must fit the number, and needs the minimum size. (zero does not have that, but 8192 requires a certain min size).

Casting also violate opaqueness because it allows to gain info on the content. But such info should not be accessible.


That is why I was doubtful a type for what he wants would be easy to define.

Because, well, its not an opaque type. Its an inbetween. With very specific properties chosen.

[Thaddy]

Ergo, this can only be done in languages where "everything is an object".