Re: [fpc-pascal] Name collisions in scoped enums
> On May 4, 2020, at 12:40 PM, Sven Barth wrote: > > No, keywords have a higher priority than identifiers, their context doesn't > matter (e.g. you can't have a method named "File" either though one could > apply the same reasoning here). If you want to use keywords you have to > escape them using "&". Methods could be called without a prefix and scoped enums must under all circumstances use their prefix right? I thought that made them unique in this regard. It would be nice to have those names freed up also if it was safe. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Name collisions in scoped enums
On Mon, 4 May 2020, Ryan Joseph via fpc-pascal wrote: On May 4, 2020, at 12:40 PM, Sven Barth wrote: No, keywords have a higher priority than identifiers, their context doesn't matter (e.g. you can't have a method named "File" either though one could apply the same reasoning here). If you want to use keywords you have to escape them using "&". Methods could be called without a prefix and scoped enums must under all circumstances use their prefix right? I thought that made them unique in this regard. It would be nice to have those names freed up also if it was safe. Methods can't be keywords either, unless prefixed with &. It's not safe to change this, that's why a keyword is a keyword: it supersedes all identifiers, it is part of the language. If you really must use keywords, just use (&File,&Array), that's what the & is for. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Name collisions in scoped enums
> On May 4, 2020, at 2:12 PM, Michael Van Canneyt > wrote: > > Methods can't be keywords either, unless prefixed with &. > > It's not safe to change this, that's why a keyword is a keyword: it > supersedes all identifiers, it is part of the language. Yes but methods can be used without their class prefix so they aren't comparable as identifiers the same way scoped enums are, because scoped enums require the prefix to be valid at all. Always, that's fine, I just wanted to make sure this wasn't an omission by accident. Speaking of that I just remembered something else. In Swift I liked that they allowed scoped enums to be used without their prefix in the instance that they are assigned to a compatible type, or in the correct context. For example if you have an enum TNames = (A, B, C); and a function SayNames(names: TNames); you can call it as SayNames([A, B]); and this is valid because of the context. Is that possible to implement in scoped enums? It's a nice time saver to not have to deal with the prefix when the context is correct but you still get the namespace protection in the rest of the program. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Name collisions in scoped enums
On Mon, 4 May 2020, Ryan Joseph via fpc-pascal wrote: On May 4, 2020, at 2:12 PM, Michael Van Canneyt wrote: Methods can't be keywords either, unless prefixed with &. It's not safe to change this, that's why a keyword is a keyword: it supersedes all identifiers, it is part of the language. Yes but methods can be used without their class prefix so they aren't comparable as identifiers the same way scoped enums are, because scoped enums require the prefix to be valid at all. Always, that's fine, I just wanted to make sure this wasn't an omission by accident. Speaking of that I just remembered something else. In Swift I liked that they allowed scoped enums to be used without their prefix in the instance that they are assigned to a compatible type, or in the correct context. For example if you have an enum TNames = (A, B, C); and a function SayNames(names: TNames); you can call it as SayNames([A, B]); and this is valid because of the context. Is that possible to implement in scoped enums? It's a nice time saver to not have to deal with the prefix when the context is correct but you still get the namespace protection in the rest of the program. That is how enums work by default in Pascal. If you don't force scoped enums, you can still scope them. if you use $scopedenums on then you simply force the use instead of having it optional. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Name collisions in scoped enums
Ryan Joseph via fpc-pascal schrieb am Mo., 4. Mai 2020, 18:58: > > > > On May 4, 2020, at 2:12 PM, Michael Van Canneyt > wrote: > > > > Methods can't be keywords either, unless prefixed with &. > > > > It's not safe to change this, that's why a keyword is a keyword: it > supersedes all identifiers, it is part of the language. > > Yes but methods can be used without their class prefix so they aren't > comparable as identifiers the same way scoped enums are, because scoped > enums require the prefix to be valid at all. Always, that's fine, I just > wanted to make sure this wasn't an omission by accident. > Keywords have a higher precedence and are handled in the scanner. This will not be changed. > Speaking of that I just remembered something else. In Swift I liked that > they allowed scoped enums to be used without their prefix in the instance > that they are assigned to a compatible type, or in the correct context. > > For example if you have an enum > > TNames = (A, B, C); > > and a function > > SayNames(names: TNames); > > you can call it as SayNames([A, B]); and this is valid because of the > context. > > Is that possible to implement in scoped enums? It's a nice time saver to > not have to deal with the prefix when the context is correct but you still > get the namespace protection in the rest of the program. > No, because there could be a method A that returns a TName. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Empty Set in constants in generics
Ryan Joseph via fpc-pascal schrieb am
Mo., 4. Mai 2020, 18:48:
> Should generics accept empty sets as constants? I think they should and
> this is a bug but I wanted to ask first.
>
>
>
> {$mode objfpc}
>
> program test;
>
> type
> TItem = (A, B, C);
> TItems = set of TItem;
> generic GType = class
> end;
>
> const
> TOtherItems = []; // no problems here
>
> type
> // error: Incompatible types: got "Empty Set" expected "TItems"
> TType = specialize GType<[]>;
>
> begin
> end.
>
Yes, they should indeed.
Regards,
Sven
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Empty Set in constants in generics
> On May 5, 2020, at 1:03 AM, Sven Barth wrote: > > Yes, they should indeed. > https://bugs.freepascal.org/view.php?id=37020 Found another one yesterday also but it's a crash https://bugs.freepascal.org/view.php?id=37014 I think it's a PPU problem. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Name collisions in scoped enums
> On May 4, 2020, at 10:44 PM, Michael Van Canneyt > wrote: > > That is how enums work by default in Pascal. > > If you don't force scoped enums, you can still scope them. > > if you use > $scopedenums on then you simply force the use instead of having it optional. But the names collide then, that's the whole point. We want to protect against name collisions and we don't want to type long prefix names every time. Scoped enums fixes half of that by formalizing the prefix syntax but you still need to type it even when it could be inferred by context. Swift figured out how to do this and so should Pascal imo. From https://docs.swift.org/swift-book/LanguageGuide/Enumerations.html: Each enumeration definition defines a new type. Like other types in Swift, their names (such as CompassPoint and Planet) start with a capital letter. Give enumeration types singular rather than plural names, so that they read as self-evident: • var directionToHead = CompassPoint.west The type of directionToHead is inferred when it’s initialized with one of the possible values of CompassPoint. Once directionToHead is declared as a CompassPoint, you can set it to a different CompassPoint value using a shorter dot syntax: • directionToHead = .east Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Name collisions in scoped enums
Am 05.05.2020 um 04:16 schrieb Ryan Joseph via fpc-pascal:
On May 4, 2020, at 10:44 PM, Michael Van Canneyt wrote:
That is how enums work by default in Pascal.
If you don't force scoped enums, you can still scope them.
if you use
$scopedenums on then you simply force the use instead of having it optional.
But the names collide then, that's the whole point. We want to protect against
name collisions and we don't want to type long prefix names every time. Scoped
enums fixes half of that by formalizing the prefix syntax but you still need to
type it even when it could be inferred by context.
Swift figured out how to do this and so should Pascal imo.
Surprise: Pascal is /not/ about writing less. Pascal is about writing
correct code.
Take this:
=== code begin ===
{$ScopedEnums On}
type
TTest = (
Value1,
Value2
);
TTests = set of TTest;
procedure Something(aArg: array of LongInt); begin end;
procedure Something(aArg: TTests); begin end;
var
Value1: LongInt;
begin
Something([Value1]);
end.
=== code end ===
Right now it's clear what procedure is called, namely the one with the
open array. If we'd allow scoped enums without their enum type then this
would result in a "can't decide which method to call". This example
might appear constructed, but imagine these to procedures coming from
two different, unrelated units.
But there is another reason why what you suggest is even /impossible/:
The parser does not know what is called until it has completely parsed
the call and then has done its overload solution. Thus it /can not/ find
a scoped enum value without its type name (such enum values are not
visible in the unit's symtable after all!). And the compiler is not
allowed to just pick a function and hope for the best as that might lead
to the wrong one (think about the example above or one where you have
two different enums with the same value).
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC development guiding.
Hi Free Pascal team. I'm a long term FPC user and ethusiast of Pascal language and it is my preferred language. In my working day I'm used to coding with C/C++ or even Java sometimes but in fact Pascal is my only real "love". One week ago I received some good news from MSX community, that FPC team is working on Z80 support to FPC (https://wiki.freepascal.org/Z80) and I already built this version (I faced some problems to build but is something that I could help too). The reason why I entered this forum is because I'm very interested and excited to help FPC team to improve Z80 support and even adding support to MSX computers, because I have a big library made to be compatible with Turbo Pascal 3.0 for (CP/M80 and MSXDOS) and this library has a very complete support to several technologies related to MSX Computers (specific crt and conio support, memory mapped management system, DiskIO functions, IDE devices support, graphics support (soon) and so on). I would like to know, what are the steps I need to follow to start contributing with FPC team, (things like about coding style, code patterns) and all necessary documentation to stay tunned with other teams members direction. Regards Leidson Campos PopolonY2k___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC development guiding.
On 2020-05-04 20:30, popolon...@popolony2k.com.br wrote: Hi PopolonY2k, . . One week ago I received some good news from MSX community, that FPC team is working on Z80 support to FPC (https://wiki.freepascal.org/Z80) and I already built this version (I faced some problems to build but is something that I could help too). The reason why I entered this forum is because I'm very interested and excited to help FPC team to improve Z80 support and even adding support to MSX computers, because I have a big library made to be compatible with Turbo Pascal 3.0 for (CP/M80 and MSXDOS) and this library has a very complete support to several technologies related to MSX Computers (specific crt and conio support, memory mapped management system, DiskIO functions, IDE devices support, graphics support (soon) and so on). I would like to know, what are the steps I need to follow to start contributing with FPC team, (things like about coding style, code patterns) and all necessary documentation to stay tunned with other teams members direction. I'm not directly involved in the Z80 port, but I can provide some general information at least. I assume that you already know our bug tracker and you clearly know at least one of our mailing lists. :-) This one (fpc-pascal) is primarily intended as help for FPC users who need to discuss how certain things might be done with FPC, etc. The mailing list fpc-devel is meant for discussing topics related to further development of FPC and thus probably more appropriate for most topics related to the new port. BTW, please be patient when sending your first e-mail to a newly subscribed list, it usually takes at least several hours to get through, but don't worry, all the following ones should be processed immediately. Regarding coding style - apart from looking at the sources, you can find some guidelines in the Wiki - https://wiki.freepascal.org/Coding_style. If you want to contribute to the new port and/or its RTL, the general solution is using our bug tracker. There might be some other options (e.g. providing patches on Github), but the bug tracker is the general one. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
