Syntax changes suggestions

classic Classic list List threaded Threaded
113 messages Options
123456
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

el_es
On 17/07/18 06:16, Sven Barth via fpc-pascal wrote:

> Am 16.07.2018 um 23:14 schrieb R0b0t1:
>> On Mon, Jul 16, 2018 at 3:28 PM, Sven Barth via fpc-pascal
>> <[hidden email]> wrote:
>>> Am 16.07.2018 um 19:55 schrieb R0b0t1:
>>>>
>>>>> - Try except finally blocks
>>>> I can support this one, I am surprised it is not already
>>>> supported. Wasn't this mentioned in another recent thread as
>>>> existing? Does it exist in at least Delphi mode?
>>>
>>> This is not supported and the last time it was discussed here on
>>> the mailing lists it was shot down (though I can't find the
>>> thread currently...). Also why should it exist in Delphi mode
>>> when Delphi does not support it? (Yes, there are some features
>>> that work in Delphi mode that Delphi doesn't support, but in
>>> generic the purpose of mode Delphi is to support Delphi code)
>> From my searching it is in (newer?) Delphi. I can't admit to being
>> a huge fan of "finally" (I don't typically use it myself) but I am
>> interested in why it is not supported.
>
> At least Delphi Tokyo (10.2) does not support it.
>
> If I remember the discussion correctly it came to light that some
> users would need "try … finally … except … end" while others would
> need "try … except … finally … end" and even some "try … finally …
> except … finally … end" or the like. With differences in opinion like
> this the idea was dropped, cause this flexibility exists already,
> namely by using separate blocks.
>
> Regards, Sven

I just had an idea come to my head - what if Lazarus would handle
the tiers of try for us ? Maybe it should be a feature of the code editor,
to convert

try
  try
    try
      code block 1;
    except
      code block 2;
    end;
  finally
    code block 3;
  end;
except
  code block 4;
end;

into

try
  code block 1;
except
  code block 2;
finally
  code block 3;
except
  code block 4
end;

and variations thereof; Then no compiler changes are necessary.

Lazarus already has the 'collapsible code blocks', and this is not much
different. I'll post this idea to Lazarus list.

cheers,
el es

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Marco van de Voort
In reply to this post by Free Pascal - General mailing list
In our previous episode, Sven Barth via fpc-pascal said:

> > interested in why it is not supported.
>
> At least Delphi Tokyo (10.2) does not support it.
>
> If I remember the discussion correctly it came to light that some users
> would need "try ? finally ? except ? end" while others would need "try ?
> except ? finally ? end" and even some "try ? finally ? except ? finally
> ? end" or the like. With differences in opinion like this the idea was
> dropped, cause this flexibility exists already, namely by using separate
> blocks.

And since the feature is implementable as an IDE macro (generating a nested
try except/finally) it doesn't make Ooccam's razor of usefulness to begin
with.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Santiago A.
In reply to this post by Marco van de Voort
El 16/07/2018 a las 21:27, Marco van de Voort escribió:

> In our previous episode, Sven Barth via fpc-pascal said:
>>> function)
>>>
>>> In such cases, you don't declare it "auto". Just as you don't free a
>>> pointer in the function you declare it if you pass the instance to another
>>> code that stores it beyond the life time of the function
>>>
>> But you don't necessarily know that the function you call does that (think
>> third party code). And people *will* use this and don't think about the
>> consequences. So a system with automatic reference counting is safer and
>> that is what is planned, if at all.
> Moreover the use case, dynamically instantiated classes with very local
> scope is rare.
You must be kidding. You use local scope objects everywhere. The
TStreams family is a clear example.

source/rtl/objpas/classes/classes.inc

//----------------------------------------
function CollectionsEqual(C1, C2: TCollection; Owner1, Owner2:
TComponent): Boolean;

   procedure stream_collection(s : tstream;c : tcollection;o : tcomponent);
     var
       w : twriter;
     begin
       w:=twriter.create(s,4096);
       try
         w.root:=o;
         w.flookuproot:=o;
         w.writecollection(c);
       finally
         w.free;
       end;
     end;

   var
     s1,s2 : tmemorystream;
   begin
     result:=false;
     if (c1.classtype<>c2.classtype) or
       (c1.count<>c2.count) then
       exit;
     if c1.count = 0 then
       begin
       result:= true;
       exit;
       end;
     s1:=tmemorystream.create;
     try
       s2:=tmemorystream.create;
       try
         stream_collection(s1,c1,owner1);
         stream_collection(s2,c2,owner2);
         result:=(s1.size=s2.size) and
(CompareChar(s1.memory^,s2.memory^,s1.size)=0);
       finally
         s2.free;
       end;
     finally
       s1.free;
     end;
   end;


//----------------------------------------
// auto version
//----------------------------------------

function CollectionsEqual(C1, C2: TCollection; Owner1, Owner2:
TComponent): Boolean;

   procedure stream_collection(s : tstream;c : tcollection;o : tcomponent);
     var
       w : twriter;auto;
     begin
       w:=twriter.create(s,4096);
      w.flookuproot:=o;
       w.writecollection(c);
     end;

   var
     s1,s2 : tmemorystream; auto;
   begin
     result:=false;
     if (c1.classtype<>c2.classtype) or
       (c1.count<>c2.count) then
       exit;
     if c1.count = 0 then
       begin
       result:= true;
       exit;
       end;
     s1:=tmemorystream.create;
     s2:=tmemorystream.create;
    stream_collection(s1,c1,owner1);
     stream_collection(s2,c2,owner2);
     result:=(s1.size=s2.size) and
(CompareChar(s1.memory^,s2.memory^,s1.size)=0);
   end;
//----------------------------------------

With "Auto", you save a lot of "try finally free" that add nothing to
algorithm

You can argue against "auto" in the grounds of "Aesthetic symmetry ",
"it's not explicitness pascal way", "it's not worth", "confusion mixing
styles/paradigms" or other arguments I haven't thought. I asked
expecting those arguments I hadn't thought about.
There may be valid arguments against, but when I read "local scope for
classes is rare", I know I am in the grounds of a irrational
resistance.  In such cases, a "For the sake of brevity, my vote is
simply "no" to all your suggestions." is the best answer.

--
Saludos

Santiago A.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Santiago A.
In reply to this post by Marco van de Voort
El 17/07/2018 a las 10:11, Marco van de Voort escribió:

> In our previous episode, Sven Barth via fpc-pascal said:
>>> interested in why it is not supported.
>> At least Delphi Tokyo (10.2) does not support it.
>>
>> If I remember the discussion correctly it came to light that some users
>> would need "try ? finally ? except ? end" while others would need "try ?
>> except ? finally ? end" and even some "try ? finally ? except ? finally
>> ? end" or the like. With differences in opinion like this the idea was
>> dropped, cause this flexibility exists already, namely by using separate
>> blocks.
> And since the feature is implementable as an IDE macro (generating a nested
> try except/finally) it doesn't make Ooccam's razor of usefulness to begin
> with.
The Occam's razor is that if it is so usefull that a macro is used a
lot, why not make it part of the languages avoiding depending on
external tools?

--
Saludos

Santiago A.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Marco van de Voort
In our previous episode, Santiago A. said:
> > And since the feature is implementable as an IDE macro (generating a nested
> > try except/finally) it doesn't make Ooccam's razor of usefulness to begin
> > with.
> The Occam's razor is that if it is so usefull that a macro is used a
> lot, why not make it part of the languages avoiding depending on
> external tools?

Because, like Sven said, there is a lot of crosstalk and fallout with a
language feature, and the IDE macro is limited to the handful of people that
for some reason have a high occurance of the feature in their business code
architecture.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Henry Vermaak
In reply to this post by Free Pascal - General mailing list
On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> Santiago A. <[hidden email]> schrieb am Mo., 16. Juli 2018, 13:41:
>
> > I have some suggestions of change to freepascal syntax, just to debate
> >
> > (All are backward compatible)
> >
> > - Declaring variables inside blocks, and loop variables
> >
> -> reduces readability -> no interest

How can it reduce readability?  You move variables closer to where they
are used, therefore reducing clutter in the main "var" section.
Limiting variable scope is definitely a good thing, I sure hope you're
not arguing against that.  That's why almost all languages encourage it.

Henry
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Michael Van Canneyt


On Tue, 17 Jul 2018, Henry Vermaak wrote:

> On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
>> Santiago A. <[hidden email]> schrieb am Mo., 16. Juli 2018, 13:41:
>>
>> > I have some suggestions of change to freepascal syntax, just to debate
>> >
>> > (All are backward compatible)
>> >
>> > - Declaring variables inside blocks, and loop variables
>> >
>> -> reduces readability -> no interest
>
> How can it reduce readability?  You move variables closer to where they
> are used, therefore reducing clutter in the main "var" section.

Pascal separates declaration from implementation.
This proposal changes that, it mixes implementation with declaration.

When you look for a variable, you know it is in the declaration block.
If you need to start scanning the code, this is a major nuisance.
I can't count the misunderstandings in Javascript due to this 'feature'.

Given that the length a typical routine should not exceed 50 lines
- i.e. fits on a modern screen - you can :
a) not have too many variables anyway.
b) see them at the glance of an eye at the top of your screen.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Mark Morgan Lloyd-5
In reply to this post by Henry Vermaak
On 17/07/18 09:15, Henry Vermaak wrote:
> On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:> Santiago A. <[hidden email]> schrieb am Mo., 16. Juli 2018, 13:41:> > > I have some suggestions of change to freepascal syntax, just to debate> >> > (All are backward compatible)> >> > - Declaring variables inside blocks, and loop variables> >> -> reduces readability -> no interest
> How can it reduce readability?  You move variables closer to where theyare used, therefore reducing clutter in the main "var" section.Limiting variable scope is definitely a good thing, I sure hope you'renot arguing against that.  That's why almost all languages encourage it.

Agreed, and that's /particularly/ the case with something like a loop
control variable which should not be assumed to have a predictable value
out-of-scope.

Wirth moved variables outside blocks to make Pascal incompatible with
ALGOL, since after the disastrous ALGOL-68 fiasco he wanted to plough
his own furrow. That doesn't necessarily make the decision a wise one.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Henry Vermaak
In reply to this post by Michael Van Canneyt
On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:

> On Tue, 17 Jul 2018, Henry Vermaak wrote:
> >On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> >>Santiago A. <[hidden email]> schrieb am Mo., 16. Juli 2018, 13:41:
> >>
> >>> I have some suggestions of change to freepascal syntax, just to debate
> >>>
> >>> (All are backward compatible)
> >>>
> >>> - Declaring variables inside blocks, and loop variables
> >>>
> >>-> reduces readability -> no interest
> >
> >How can it reduce readability?  You move variables closer to where they
> >are used, therefore reducing clutter in the main "var" section.
>
> Pascal separates declaration from implementation. This proposal changes
> that, it mixes implementation with declaration.

No, it will still separate the declaration, but just on the block level.
For example:

for i := 0 to n - 1 do
var
  foo: integer = 0;
begin
  // ...
end;

> When you look for a variable, you know it is in the declaration block.
> If you need to start scanning the code, this is a major nuisance.

If you're in a block, you look at the "var" section of the block first,
then move up a block and repeat.  Calling it "a major nuisance" is
needless hyperbole.  In the above code, why do I want to see foo in the
main "var" block of the function?  It's just noise there, reducing
readability.

> I can't count the misunderstandings in Javascript due to this 'feature'.

This feature makes you properly reduce scope of variables, I seriously
haven't met anyone that thinks this is a bad idea.  It's standard
programming practise in every language I've worked.

Henry
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Henry Vermaak
In reply to this post by Mark Morgan Lloyd-5
On Tue, Jul 17, 2018 at 09:32:24AM +0000, Mark Morgan Lloyd wrote:
> On 17/07/18 09:15, Henry Vermaak wrote:
> >On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:> Santiago A. <[hidden email]> schrieb am Mo., 16. Juli 2018, 13:41:> > > I have some suggestions of change to freepascal syntax, just to debate> >> > (All are backward compatible)> >> > - Declaring variables inside blocks, and loop variables> >> -> reduces readability -> no interest
> >How can it reduce readability?  You move variables closer to where theyare used, therefore reducing clutter in the main "var" section.Limiting variable scope is definitely a good thing, I sure hope you'renot arguing against that.  That's why almost all languages encourage it.
>
> Agreed, and that's /particularly/ the case with something like a loop
> control variable which should not be assumed to have a predictable value
> out-of-scope.

Spot on, you can pretty much eliminate that class of bug with this.

Henry
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Free Pascal - General mailing list
In reply to this post by Henry Vermaak
Henry Vermaak <[hidden email]> schrieb am Di., 17. Juli 2018, 11:05:
On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> Santiago A. <[hidden email]> schrieb am Mo., 16. Juli 2018, 13:41:
>
> > I have some suggestions of change to freepascal syntax, just to debate
> >
> > (All are backward compatible)
> >
> > - Declaring variables inside blocks, and loop variables
> >
> -> reduces readability -> no interest

How can it reduce readability?  You move variables closer to where they
are used, therefore reducing clutter in the main "var" section.

*you* might do this, but there are enough developers that won't. I already don't like looking at such C code, so why would I want that in Pascal which avoided that problem? 

Limiting variable scope is definitely a good thing, I sure hope you're
not arguing against that.  That's why almost all languages encourage it.

I'm arguing against micromanaging the scope of a variable inside a function. 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Henry Vermaak
On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:

> Henry Vermaak <[hidden email]> schrieb am Di., 17. Juli 2018,
> 11:05:
>
> > On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> > > Santiago A. <[hidden email]> schrieb am Mo., 16. Juli 2018, 13:41:
> > >
> > > > I have some suggestions of change to freepascal syntax, just to debate
> > > >
> > > > (All are backward compatible)
> > > >
> > > > - Declaring variables inside blocks, and loop variables
> > > >
> > > -> reduces readability -> no interest
> >
> > How can it reduce readability?  You move variables closer to where they
> > are used, therefore reducing clutter in the main "var" section.
> >
>
> *you* might do this, but there are enough developers that won't. I already

By not having this feature you're not giving anyone a choice.

> don't like looking at such C code, so why would I want that in Pascal which
> avoided that problem?

What problem?  I'm not saying I want to mix declarations with code, the
var section should be at the top of the block/scope.  I don't even know
any C programmers that mix declarations with code.  This isn't the 80s.

Henry
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Martin Friebe
In reply to this post by Henry Vermaak
On 17/07/2018 11:05, Henry Vermaak wrote:

> On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
>> Santiago A. <[hidden email]> schrieb am Mo., 16. Juli 2018, 13:41:
>>
>>> I have some suggestions of change to freepascal syntax, just to debate
>>>
>>> (All are backward compatible)
>>>
>>> - Declaring variables inside blocks, and loop variables
>>>
>> -> reduces readability -> no interest
> How can it reduce readability?  You move variables closer to where they
> are used, therefore reducing clutter in the main "var" section.
> Limiting variable scope is definitely a good thing, I sure hope you're
> not arguing against that.  That's why almost all languages encourage it.
>
On the contra side:

You could then have 2 or more differnt "i" variables in one procedure.
That is hell to read.

Of course you could argue that you can only have a "nested" "i", if
there is no local var "i" (current style local). And no other nesting.
Still 2 issues:
You could have 2 consecutive loops, with different typed "i". That can
be confusing. (it may not be to you, but is still can be). Now you would
need 2 different named loop counters (which to me is good).

But more troubling:
You do no longer have a complete list of all local vars. That means, if
I want to add a (current style) local var "i", i may have to scan the
entire procedure (maybe hundreds of lines) to find if there already is a
nested "i" (or start the compiler to see if there is an error).
That would be a real burden added to pascal (and since I may have to
work on other peoples code, it is no good to say that I could simply not
use it....)

----------------------
Also lets make a distinction here:

What are we looking for:
A) Saving the (so called) work, of declaring the var on top? (Note: that
the work is pressing ctrl-shift-c)?
B) Introducing vars with more fine grained scoping?

As for (A) I already expressed that I am against it. (there also is a
recent thread on the forum where this was discussed, so look it up and
read the arguments)

As for (B):
I don't know of any good proposal, but if there was it would have to be
something like this: (I still dont like it, but if there was a good idea
to bring it in shape...)

procedure Foo;
var
    a: Integer; // normal vor
scoped var
    b: integer;
begin
   //b can not be used here / it will be as if it does not exist
   a := bar();
   if a > 1 then begin
     scope b;  // must be first after begin
     b := 1;
   end;
   // b out of scope
   // scope for one statement (the entire for, including the begin end
which as a compound statement is part of the for.
   with scope b do for b := 1 to 10 do ... ;
// alternatively
   using scope b do for b := 1 to 10 do ... ;
   scope b: for b := 1 to 10 do ... ;

So you still declare the var on top.

Again, this is to entertain an idea, which I personally do not like....

If you have a scoping problem in pascal, cut your code into smaller
procedures.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Michael Van Canneyt
In reply to this post by Henry Vermaak


On Tue, 17 Jul 2018, Henry Vermaak wrote:

> On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:
>> On Tue, 17 Jul 2018, Henry Vermaak wrote:
>> >On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
>> >>Santiago A. <[hidden email]> schrieb am Mo., 16. Juli 2018, 13:41:
>> >>
>> >>> I have some suggestions of change to freepascal syntax, just to debate
>> >>>
>> >>> (All are backward compatible)
>> >>>
>> >>> - Declaring variables inside blocks, and loop variables
>> >>>
>> >>-> reduces readability -> no interest
>> >
>> >How can it reduce readability?  You move variables closer to where they
>> >are used, therefore reducing clutter in the main "var" section.
>>
>> Pascal separates declaration from implementation. This proposal changes
>> that, it mixes implementation with declaration.
>
> No, it will still separate the declaration, but just on the block level.

You are still mixing code with declarations.

>> When you look for a variable, you know it is in the declaration block.
>> If you need to start scanning the code, this is a major nuisance.
>
> If you're in a block, you look at the "var" section of the block first,
> then move up a block and repeat.  Calling it "a major nuisance" is
> needless hyperbole.

I like hyperbole, one can never have too much hyperbole :)

> In the above code, why do I want to see foo in the
> main "var" block of the function?  It's just noise there, reducing
> readability.

Of course not, that's where it belongs.

>> I can't count the misunderstandings in Javascript due to this 'feature'.
>
> This feature makes you properly reduce scope of variables, I seriously
> haven't met anyone that thinks this is a bad idea.  It's standard
> programming practise in every language I've worked.

If you need to "reduce the scope of variables", your routines are too long to
begin with.

If of course you write routines of several hundreds of lines (or thousands),
then you probably would need to have such a feature.

But I would fire any programmer that writes such code anyway,
since it indicates he cannot think structured.

But probably this whole answer is again too hyperbole :-)

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Martin Friebe
In reply to this post by Henry Vermaak
On 17/07/2018 12:02, Henry Vermaak wrote:
> On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
>> *you* might do this, but there are enough developers that won't. I
>> already
> By not having this feature you're not giving anyone a choice.
>
By having this feature you are forcing everyone to use it.

(This has been explained plenty of times)
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Michael Van Canneyt


On Tue, 17 Jul 2018, Martin wrote:

> On 17/07/2018 12:02, Henry Vermaak wrote:
>> On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
>>> *you* might do this, but there are enough developers that won't. I
>>> already
>> By not having this feature you're not giving anyone a choice.
>>
> By having this feature you are forcing everyone to use it.
>
> (This has been explained plenty of times)

Exactly.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Henry Vermaak
In reply to this post by Martin Friebe
On Tue, Jul 17, 2018 at 12:07:42PM +0200, Martin wrote:
> On 17/07/2018 12:02, Henry Vermaak wrote:
> >On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
> >>*you* might do this, but there are enough developers that won't. I
> >>already
> >By not having this feature you're not giving anyone a choice.
> >
> By having this feature you are forcing everyone to use it.

No, why would you think that?  Nobody is forcing you to move your
variables into a block, just carry on as before if you don't like it.
Var sections for functions are optional, you can use global variables
for everything if you like.  No different to this.

Henry
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Michael Van Canneyt


On Tue, 17 Jul 2018, Henry Vermaak wrote:

> On Tue, Jul 17, 2018 at 12:07:42PM +0200, Martin wrote:
>> On 17/07/2018 12:02, Henry Vermaak wrote:
>> >On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
>> >>*you* might do this, but there are enough developers that won't. I
>> >>already
>> >By not having this feature you're not giving anyone a choice.
>> >
>> By having this feature you are forcing everyone to use it.
>
> No, why would you think that?  Nobody is forcing you to move your
> variables into a block, just carry on as before if you don't like it.
> Var sections for functions are optional, you can use global variables
> for everything if you like.  No different to this.

The point under discussion is readability of code.

So, if I need to read someone elses code and this person uses this feature heavily,
then I end up being confronted with it, the readability of his code for me
is reduced.

Pascal has always been lauded for being readable.
I would like to keep it that way.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Henry Vermaak
In reply to this post by Michael Van Canneyt
On Tue, Jul 17, 2018 at 12:07:10PM +0200, Michael Van Canneyt wrote:
> >On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:
> If you need to "reduce the scope of variables", your routines are too long to
> begin with.
>
> If of course you write routines of several hundreds of lines (or thousands),
> then you probably would need to have such a feature.
>
> But I would fire any programmer that writes such code anyway, since it
> indicates he cannot think structured.

And I'd fire any programmer that doesn't properly scope their variables,
just as you'd (hopefully) fire a programmer for using global instead of
function level variables.

> But probably this whole answer is again too hyperbole :-)

It's not the hyperbole that really worries me too much, I like a bit of
that myself.  I'm worried about the knee-jerk reactions to good ideas.
Badly written responses like "reduces readability" is extremely
uncharitable without proper motivation and projects the image that
everyone on this list will just shoot down any improvement to their
beloved Pascal.

Anyway, not much to add to the subject without repeating myself.

Henry
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Michael Van Canneyt
In reply to this post by Martin Friebe


On Tue, 17 Jul 2018, Martin wrote:

> On 17/07/2018 11:05, Henry Vermaak wrote:
>> On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
>>> Santiago A. <[hidden email]> schrieb am Mo., 16. Juli 2018, 13:41:
>>>
>>>> I have some suggestions of change to freepascal syntax, just to debate
>>>>
>>>> (All are backward compatible)
>>>>
>>>> - Declaring variables inside blocks, and loop variables
>>>>
>>> -> reduces readability -> no interest
>> How can it reduce readability?  You move variables closer to where they
>> are used, therefore reducing clutter in the main "var" section.
>> Limiting variable scope is definitely a good thing, I sure hope you're
>> not arguing against that.  That's why almost all languages encourage it.
>>

[snip]

>
> If you have a scoping problem in pascal, cut your code into smaller
> procedures.

Which is what I have been saying all along...

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
123456