Gerhard Scholz via fpc-pascal said on Sat, 16 Dec 2023 20:07:45 +0100
>I never had the problem because before the else I always inserted a ";"
I know it's 50+ years too late for me to submit ideas for the Pascal
language, but in my perfect world you could put a semicolon at the end
of anything,
Am 17.12.2023 um 16:36 schrieb Adriaan van Os via fpc-pascal:
As the otherwise-clause is not in ISO-7185 Pascal, it seems more
plausible that Borland invented the else-clause (without semicolon)
independently. All other Pascals I have looked at, use an
otherwise-clause (with an obligatory
Tony Whyman via fpc-pascal wrote:
Back in the early eighties, I worked at ICL and we made extensive use of
the Prospero Pascal compiler building embedded systems based on the Z80
microprocessor. I still have a 1988 edition of the language
specification, and this uses EBNF to define the case
Am 17.12.2023 um 06:12 schrieb Adriaan van Os via fpc-pascal:
Anyway, the innocent looking case-statement does have some interesting
aspects.
Indeed.
My Stanford compiler tries to be portable across platforms;
due to its IBM mainframe heritage even on platforms that have "strange"
I find the idea of a "closest containing value" rather weird. For me, programming is strict logic,
not finding something "closest".
What I wrote here, is nonsense. "Closest containing" is rather a grammatical concept, that I
misunderstood.
Regards,
Adriaan van Os
Tony Whyman via fpc-pascal wrote:
Prospero Pascal was close to ISO Pascal (although I have lost my
original copy of ISO Pascal) and I would guess that the above is copied
from ISO Pascal.
You can find the ISO-7185 document on the internet, just search for
"iso7185.pdf".
A less known aspect
On 16/12/2023 19:07, Gerhard Scholz via fpc-pascal wrote:
ELSE/OTHERWISE
I assume that came historically; the first implementation of a PASCAL
compiler I have seen had no else or otherwise in the case startement.
Some ater dialects introduced ELSE, other dialect(s) used OTHERWISE,
FPC then
ted a ";"
- Original Message -
From: "Adriaan van Os via fpc-pascal"
To: "FPC-Pascal users discussions"
Cc: "Adriaan van Os"
Sent: Thursday, December 14, 2023 4:53 PM
Subject: [fpc-pascal] case statement
I am looking in detail at the syn
On Fri, 15 Dec 2023, Adriaan van Os wrote:
Michael Van Canneyt via fpc-pascal wrote:
The fact that the semicolon before the else is optional ?
I don't see a semicolon in the formal syntax.
This works:
OK, than an optional semicolon must be added to the rule
exceptionhandlers = [
Jean SUZINEAU via fpc-pascal wrote:
Le 15/12/2023 à 10:39, Adriaan van Os via fpc-pascal a écrit :
I don't see a semicolon in the formal syntax.
May be included in the ' "DO" statement ' ?
No, have a look at the syntax diagrams, statements never end with a semicolon.
Regards,
Adriaan van
Michael Van Canneyt via fpc-pascal wrote:
The fact that the semicolon before the else is optional ?
I don't see a semicolon in the formal syntax.
This works:
OK, than an optional semicolon must be added to the rule
exceptionhandlers = [ exception-handler { ";" exception-handler } [ ";"
Le 15/12/2023 à 10:39, Adriaan van Os via fpc-pascal a écrit :
I don't see a semicolon in the formal syntax.
May be included in the ' "DO" statement ' ?
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote:
Michael Van Canneyt via fpc-pascal wrote:
On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote:
Note that the same ambiguity exists in the syntax (and
this is less well known)
exceptionhandlers = [ exception-handler { ";"
Michael Van Canneyt via fpc-pascal wrote:
On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote:
Note that the same ambiguity exists in the syntax
(and this is less well known)
exceptionhandlers = [ exception-handler { ";" exception-handler } [
"ELSE" statement-list ] |
On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote:
Note that the same ambiguity exists in the syntax (and
this is less well known)
exceptionhandlers = [ exception-handler { ";" exception-handler } [ "ELSE"
statement-list ] | statement-list ] .
exception-handler = "ON" [
Note that the same ambiguity exists in the syntax (and this
is less well known)
exceptionhandlers = [ exception-handler { ";" exception-handler } [ "ELSE" statement-list ] |
statement-list ] .
exception-handler = "ON" [ identifier ":" ] class-type-identifier "DO"
statement .
as ends with
To: fpc-pascal@lists.freepascal.org
Cc: Martin Wynne
Subject: Re: [fpc-pascal] case statement
I've been using ELSE in IF statements and in CASE statements for 25 years
without realising there was a problem. What a dim-wit I have been.
Martin.
___
fpc
I've been using ELSE in IF statements and in CASE statements for 25
years without realising there was a problem. What a dim-wit I have been.
Martin.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
James Richters via fpc-pascal wrote:
I didn’t know there was such a thing as OTHERWISE. Is there any functional
difference between OTHERWISE and ELSE?
No. It is just that OTHERWISE doesn't have the IF-THEN-ELSE ambiguity. Macintosh Pascal compilers
had OTHERWISE but not ELSE. Maybe,
James Richters via fpc-pascal schrieb am
Do., 14. Dez. 2023, 20:13:
> I didn’t know there was such a thing as OTHERWISE. Is there any
> functional difference between OTHERWISE and ELSE?
>
"otherwise" is what had been defined by ISO Extended Pascal for the
cause-statement.
Aside from not
I didn’t know there was such a thing as OTHERWISE. Is there any functional
difference between OTHERWISE and ELSE?
James
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Michael Van Canneyt via fpc-pascal wrote:
On Thu, 14 Dec 2023, Adriaan van Os via fpc-pascal wrote:
I am looking in detail at the syntax diagrams in the Freepascal
Language Reference (version 3.2.0)
Section 13.2.2 discusses the case-statement. Translated to EBNF (WSN)
the syntax is
On Thu, 14 Dec 2023, Adriaan van Os via fpc-pascal wrote:
I am looking in detail at the syntax diagrams in the Freepascal Language
Reference (version 3.2.0)
Section 13.2.2 discusses the case-statement. Translated to EBNF (WSN) the
syntax is
case-statement = "CASE" expression "OF" case
On Thu, Dec 14, 2023 at 5:01 PM Adriaan van Os via fpc-pascal
wrote:
> I always use "OTHERWISE instead of ELSE, but that's my personal
> preference.
+1
Seeing OTHERWISE in source code just makes me smile.
--
Bart
___
fpc-pascal maillist -
I am looking in detail at the syntax diagrams in the Freepascal Language
Reference (version 3.2.0)
Section 13.2.2 discusses the case-statement. Translated to EBNF (WSN) the
syntax is
case-statement = "CASE" expression "OF" case { ";" case } [ else-part ] [ ";" ]
.
case = constant [ ".."
> On Jan 20, 2022, at 8:10 PM, Ryan Joseph wrote:
>
> I just check at https://gitlab.com/freepascal.org/fpc/source/-/merge_requests
> and I don't see my merge request appeared. If it were GitHub I would expect
> to see it there. What did I do wrong?
So what I did was created a merge request
> On Jan 20, 2022, at 9:11 AM, Ryan Joseph wrote:
>
> The problem was my remote for the branch got lost after rebasing but I think
> I fixed it by re-pulling.
>
> It looks like some unrelated commits are included in my merge request but
> maybe that happened because I rebased the repo after
> On Jan 19, 2022, at 8:14 PM, Ryan Joseph wrote:
>
> Ok I got this almost done (mirroring is great I didn't know I could do that)
> and did the rebase which shows the linear history now.
>
> First a question, do I need to do the "rebase main" again before I push to
> remote or does it
Ok I got this almost done (mirroring is great I didn't know I could do that)
and did the rebase which shows the linear history now.
First a question, do I need to do the "rebase main" again before I push to
remote or does it stay this way now?
Problem is I go to push the changes to the my
On Wed, 19 Jan 2022, Ryan Joseph via fpc-pascal wrote:
On Jan 19, 2022, at 4:19 PM, Ryan Joseph wrote:
Still not following this. Do you need me to do a pull-rebase from main and then
make my pull request?
I used git at work everyday but I'm still a newbie in many ways. Reading this
> On Jan 19, 2022, at 4:19 PM, Ryan Joseph wrote:
>
> Still not following this. Do you need me to do a pull-rebase from main and
> then make my pull request?
I used git at work everyday but I'm still a newbie in many ways. Reading this
now but I'm confused because it seems too late. Please
> On Jan 19, 2022, at 4:15 PM, Michael Van Canneyt
> wrote:
>
> It's explained in the page that Sven referred to ?
>
> It's only when you merge into your feature branch from the main branch that
> you will see an effect.
Still not following this. Do you need me to do a pull-rebase from
On Wed, 19 Jan 2022, Ryan Joseph via fpc-pascal wrote:
On Jan 19, 2022, at 1:26 PM, Sven Barth wrote:
We also take merge requests. If you have a fork anyway, then a merge request is
probably easier. Though you need to have your repository set up to use rebasing
instead of merging, see
> On Jan 19, 2022, at 1:26 PM, Sven Barth wrote:
>
> We also take merge requests. If you have a fork anyway, then a merge request
> is probably easier. Though you need to have your repository set up to use
> rebasing instead of merging, see here:
> https://wiki.freepascal.org/FPC_git#Update
Am 19.01.2022 um 02:48 schrieb Ryan Joseph via fpc-pascal:
On Jan 18, 2022, at 5:28 AM, Sven Barth wrote:
The values will have the same differences between each other upon each start so
ideally this would work anyway, but if one also throws dynamic packages into
the mix things would get
> On Jan 18, 2022, at 5:28 AM, Sven Barth wrote:
>
> The values will have the same differences between each other upon each start
> so ideally this would work anyway, but if one also throws dynamic packages
> into the mix things would get messed up. So better stay with the if-clauses.
Am 17.01.2022 um 13:58 schrieb Ryan Joseph via fpc-pascal:
On Jan 17, 2022, at 5:09 PM, Sven Barth wrote:
The VMT writer already does that, cause the VMT pointer is required for each
constructor call.
The pointer to the VMT table is just PVmt(self) right? If I make a program and
do:
> On Jan 17, 2022, at 5:09 PM, Sven Barth wrote:
>
> The VMT writer already does that, cause the VMT pointer is required for each
> constructor call.
>
The pointer to the VMT table is just PVmt(self) right? If I make a program and
do:
writeln(PtrUInt(TObject.ClassType));
the address
Ryan Joseph via fpc-pascal schrieb am
Mo., 17. Jan. 2022, 08:53:
>
>
> > On Jan 17, 2022, at 1:55 PM, Sven Barth
> wrote:
> >
> > Question then is how you get the VMT address as a constant at compile
> time.
> >
> > I'll need to get back to you with that.
> >
>
> I didn't test yet but I think
> On Jan 17, 2022, at 1:55 PM, Sven Barth wrote:
>
> Question then is how you get the VMT address as a constant at compile time.
>
> I'll need to get back to you with that.
>
I didn't test yet but I think what you're saying is that VMT writer would need
to have generated this address in
Ryan Joseph via fpc-pascal schrieb am
Mo., 17. Jan. 2022, 02:38:
>
>
> > On Jan 16, 2022, at 11:15 PM, Sven Barth
> wrote:
> >
> > The class type already is a unique "ID" for each class type when doing
> an equal comparison. You can essentially take the address of the VMT as the
> constant
> On Jan 16, 2022, at 11:15 PM, Sven Barth wrote:
>
> The class type already is a unique "ID" for each class type when doing an
> equal comparison. You can essentially take the address of the VMT as the
> constant values that the loaded value is compared against.
Does that look something
Am 16.01.2022 um 15:25 schrieb Ryan Joseph via fpc-pascal:
On Jan 16, 2022, at 9:01 PM, Ryan Joseph wrote:
case PtrUInt(o.ClassType) of
4500656856: writeln('TObject');
end;
I may have spoken too soon and without thinking the through clearly (it's
getting late here!). For this to
> On Jan 16, 2022, at 9:01 PM, Ryan Joseph wrote:
>
> case PtrUInt(o.ClassType) of
>4500656856: writeln('TObject');
> end;
I may have spoken too soon and without thinking the through clearly (it's
getting late here!). For this to work we would need a unique ID in the RTTI,
right? I
> On Jan 16, 2022, at 8:18 PM, Ryan Joseph wrote:
>
> https://gitlab.com/genericptr/free-pascal/-/commits/case_label_classref
I just realized too late that the way I implemented this may be not the best
idea. If the class type had an ordinal representation then you could use a
normal case
> On Jan 16, 2022, at 8:38 PM, Marco van de Voort via fpc-pascal
> wrote:
>
> What does it print in this case? I mean tobject matches, and
> tinterfacedobject too.
>
> The most logic solution would be to only run the most specialized case?
It would print the name of the class if it didn't
On 16-1-2022 14:18, Ryan Joseph via fpc-pascal wrote:
I had some fun today on my day off and managed to actually implement this based
on the if-statement based string case labels. Is the compiler team interested
in this feature? I think it's a clearly useful addition to OOP and an
I had some fun today on my day off and managed to actually implement this based
on the if-statement based string case labels. Is the compiler team interested
in this feature? I think it's a clearly useful addition to OOP and an
appropriate new use of the case statement.
> On Jan 16, 2022, at 2:35 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
>
> They are.
>
> No "is", because then the order of the label will start to matter, and that
> runs contrary
> to the case statement's intent.
oh of course they are, I don't know why I forgot that. :P
Regards,
On Sun, 16 Jan 2022, Ryan Joseph via fpc-pascal wrote:
On Jan 16, 2022, at 9:21 AM, Ryan Joseph wrote:
There is a possibility for using "as" operator also though
oops I mean "is" operator. Not sure if these are technically different from
ClassType = ClassType though...
They are.
> On Jan 16, 2022, at 9:21 AM, Ryan Joseph wrote:
>
> There is a possibility for using "as" operator also though
oops I mean "is" operator. Not sure if these are technically different from
ClassType = ClassType though...
Regards,
Ryan Joseph
> On Jan 15, 2022, at 3:24 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> I don't see how an inline variable helps with the casting mess. You'll
> always need a cast.
>
> What I do is Var
> MyInstance : TObject;
> MyNeededClass : TMyNeededClass absolute myInstance:
Yes that's the
On Sat, 15 Jan 2022, Ryan Joseph via fpc-pascal wrote:
On Jan 15, 2022, at 8:30 AM, Michael Van Canneyt via fpc-pascal
wrote:
I saw a new syntax in Swift which I thought was clever and fits a pattern
I've seen before. Basically it's a case statement for class types which
lets you
> On Jan 15, 2022, at 8:30 AM, Michael Van Canneyt via fpc-pascal
> wrote:
>
>> I saw a new syntax in Swift which I thought was clever and fits a pattern
>> I've seen before. Basically it's a case statement for class types which
>> lets you branch depending on which class type the class
On Sat, 15 Jan 2022, Ryan Joseph via fpc-pascal wrote:
I saw a new syntax in Swift which I thought was clever and fits a pattern
I've seen before. Basically it's a case statement for class types which
lets you branch depending on which class type the class instance is at run
time.
I think
I saw a new syntax in Swift which I thought was clever and fits a pattern I've
seen before. Basically it's a case statement for class types which lets you
branch depending on which class type the class instance is at run time.
I wonder if this could be implemented in FPC? The syntax would be
56 matches
Mail list logo
