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

Michael Van Canneyt


On Tue, 17 Jul 2018, Henry Vermaak wrote:

> 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.

Exactly: I do scope them. I make small routines.

Reducing scope to 5 lines in a routine of 20 lines is a waste of time.

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

vojtech.cihak
In reply to this post by Henry Vermaak

Hi,

 

Lazarus has option "Show Class/Proc Hint" which displays method name (with light-green background) as the top line in source editor, only if the method's body is longer than number of lines in source editor.

Maybe new option "Show Proc var block" for permanent displaying var block in long methods would be enough? Jumps between code and declaration would not be needed.

 

V.

______________________________________________________________
> Od: Michael Van Canneyt <[hidden email]>
> Komu: FPC-Pascal users discussions <[hidden email]>
> Datum: 17.07.2018 12:30
> Předmět: Re: [fpc-pascal] Syntax changes suggestions
>


Exactly: I do scope them. I make small routines.

Reducing scope to 5 lines in a routine of 20 lines is a waste of time.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
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
>> don't like looking at such C code, so why would I want that in Pascal

This is not my fight because TBH I'm inclined to avoid novel language
features until I know that using them won't impact on some of the older
kit I try to keep stuff compiled for.

However, I do wish that people wouldn't resort to that same old
chestnut. There ought to be a Pascal discussion equivalent of Godwin's
Law: "sooner or later in any debate about a language feature somebody
will complain that it's too much like C".

Frankly, who cares? are we really all so insecure that we can't
accommodate even the suggestion that "our opponents" occasionally have a
good idea?

Besides which, in-block declarations predate C: it's the way that
ALGOL-60 did it. And ALGOL-60 put the type before the variable in a
declaration, had in-expression conditionals and so on: all things I've
seen rejected offhand as "too much like C".

So come on chaps, at least get your history right and say that you
prefer the Pascal way and won't have any ALGOL crap messing it up.

Pax vobiscum.

--
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

Michael Van Canneyt
In reply to this post by vojtech.cihak


On Tue, 17 Jul 2018, Vojtěch Čihák wrote:

> Hi,
>  
> Lazarus has option "Show Class/Proc Hint" which displays method name (with
> light-green background) as the top line in source editor, only if the
> method's body is longer than number of lines in source editor.
> Maybe new option "Show Proc var block" for permanent displaying var block in
> long methods would be enough? Jumps between code and declaration would not be
> needed.

If such a thing is implemented, then why not make it as the 'local variables' debug
dialog, a separate floating window, maybe stay-on-top  ?

If you put it at the top of the source editor, it risks to take a lot of space out
of the source editor window, which kind of defeats the purpose, I suppose.

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

vojtech.cihak
In reply to this post by vojtech.cihak

Maybe it should be extension of Code Explorer.

 

I did a quick calculation, I have 1680x1050 laptop display and I can see 40 lines of code in Source Editor, i.e. 39+1 method name for long methods.

If the var block has ~8 lines, then it would remain 31 lines for code, it is still accepatable. And I guess programmers have usually bigger displays.

 

V.

 

______________________________________________________________
> Od: Michael Van Canneyt <[hidden email]>
> Komu: FPC-Pascal users discussions <[hidden email]>
> Datum: 17.07.2018 15:34
> Předmět: Re: [fpc-pascal] Syntax changes suggestions
>



On Tue, 17 Jul 2018, Vojtěch Čihák wrote:


If such a thing is implemented, then why not make it as the 'local variables' debug
dialog, a separate floating window, maybe stay-on-top  ?

If you put it at the top of the source editor, it risks to take a lot of space out
of the source editor window, which kind of defeats the purpose, I suppose.

Michael.

----------

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
_______________________________________________
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

Reimar Grabowski
In reply to this post by Martin Friebe
On Tue, 17 Jul 2018 12:04:19 +0200
Martin <[hidden email]> wrote:

> 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"
Wouldn't you need to refactor this procedure anyway into 20 line chunks and nuke the guy that wrote it? ;)

Btw I don't support the proposed changes as I don't see the need to get all and every language on feature parity.
Languages do have different design philosophies which manifest in different feature sets. So there is always more to a feature than pure functionality.
I write nowadays mostly in languages which do have "block scope" and I really don't prefer one "scoping" over the other. Both make sense in the context of their respective language.
And Delphi for example introduced features in a vain attempt to stay relevant which where not in the spirit of pascal. Freepascal has no need to do this.

R.
_______________________________________________
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 Mark Morgan Lloyd-5
In our previous episode, Mark Morgan Lloyd said:
> However, I do wish that people wouldn't resort to that same old
> chestnut. There ought to be a Pascal discussion equivalent of Godwin's
> Law: "sooner or later in any debate about a language feature somebody
> will complain that it's too much like C".

That sounds very negative, but one must not forget that this only is a
response to a halfassed copy syntax-from-language-x request. And everything
is always demonstrated with 4 line examples, no analysis how it fits in the
parsing structure nothing.

To be honest, I'm wondering why Sven actually bothers to answer this
nonsense.
 
> Frankly, who cares? are we really all so insecure that we can't
> accommodate even the suggestion that "our opponents" occasionally have a
> good idea?

"Good idea" is terribly subjective as already made clear in this discussion,
opinions vary wildly.

Are we so insecure that we must copy every alien bit of syntax? No.

Worse, IMHO creeping unnecessary dialect change is worse than remaining
different. The spread of codebases over the various subdialects is worse than any
benefits these half assed extensions can ever have. It is spreading language
development thin instead of deep

P.s. people that disagree should start arguing for an unit/module concept
on C groups, and use the exact same reasoning. Please post the URL, and I'll
follow the thread with a bucket of popcorn.
_______________________________________________
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
Marco van de Voort <[hidden email]> schrieb am Di., 17. Juli 2018, 16:50:
To be honest, I'm wondering why Sven actually bothers to answer this
nonsense.

Trust me, I wonder the same 🙄

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

Ryan Joseph
In reply to this post by Free Pascal - General mailing list


> On Jul 16, 2018, at 11:20 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> Because they are programmers. They simply do it their way. And I'm especially talking about code written by two different programmers, one storing the instance somewhere and the other passing in an "auto" instance without knowing that the other programmer is storing it somewhere.
>> Auto is a good idea. Allocating the “auto” classes the memory backend on the stack (my “stack alias” idea) is even better because you don’t need the memory manager too be involved.
> No, it's not. And we don't *want* to change the paradigm of TObject.

The reason we propose these things is because of a manifest observable need that we experience daily. We’re not proposing things like making Pascal garbage collected or ARC for all objects like new languages are. These are practical and optional solutions that programmers can use depending on their needs.

Firs off, yes I know this isn’t Pascal objects but look at this entirely predictable block of code that I found after searching for 10 seconds. Dynamically allocating memory which I *know* beyond a shadow of a doubt will only survive this function. There’s not going to be any passing around. I know this.

Predictably at the end of the function I review all the memory I allocated and free it. Why couldn’t I just tell the compiler I want this freed at the time I declare the variable? I know then and I don’t want to think about it again. This is such an obvious pattern to optimize in the language. This is not that crazy guys.

        colorSpace := CGColorSpaceCreateDeviceRGB;
        bitmapInfo := kCGImageAlphaFirst or kCGBitmapByteOrder32Little;
        provider := CGDataProviderCreateWithData(nil, bytes, bytesCount, nil);
        imageRef := CGImageCreate(width, height, 8, 32, bytesPerRow, colorSpace, bitmapInfo, provider, nil, 1, kCGRenderingIntentDefault);

        finalImage := NSImage.alloc.initWithCGImage_size(imageRef, NSMakeSize(width, height));
        imageData := finalImage.TIFFRepresentation;
        imageRep := NSBitmapImageRep.imageRepWithData(imageData);
        //imageProps := NSDictionary.dictionaryWithObject_forKey(NSNumber.numberWithFloat(1), NSImageCompressionFactor);
        imageData := imageRep.representationUsingType_properties(fileType, imageProps);
        imageData.writeToFile_atomically(NSSTR(path), false);
       
        // <——————————————— freeing stuff ———————————————>
        CFRelease(provider);
        CFRelease(imageRef);
        CFRelease(colorSpace);
        finalImage.release;

var
  colorSpace: CGColorSpaceRef;
  provider: CGDataProviderRef;
  imageRef: CGImageRef;
  finalImage: NSImage;


Regards,
        Ryan Joseph

_______________________________________________
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

Jim Lee
In reply to this post by Marco van de Voort


On 07/17/18 07:49, Marco van de Voort wrote:
>
> Worse, IMHO creeping unnecessary dialect change is worse than remaining
> different. The spread of codebases over the various subdialects is worse than any
> benefits these half assed extensions can ever have. It is spreading language
> development thin instead of deep
>
>

Agreed.

This can be likened to the spread of globalization among cultures.
Uniqueness and charm suffer at the hand of cross-pollination.

You can go almost anywhere in the world today and find icons of Western
culture.  Starbucks in Sri Lanka.  McDonalds in Shanghai.

Likewise, "modern" programming languages are all converging on a common
feature set, like cultural cross-pollination.

I prefer to have a variety of dialects and paradigms to choose from (and
a variety of cultures) over a global sameness.

-Jim


_______________________________________________
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

Ryan Joseph


> On Jul 17, 2018, at 11:27 AM, Jim Lee <[hidden email]> 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.

Regards,
        Ryan Joseph

_______________________________________________
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

Jim Lee


On 07/17/18 11:00, Ryan Joseph wrote:

>
>> On Jul 17, 2018, at 11:27 AM, Jim Lee <[hidden email]> 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.
>
> Regards,
> Ryan Joseph
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Well, if we keep with the cultural parallel, in all cultures people must
eat, sleep, drink, be born and die, etc.  There are a number of
commonalities simply because all involve humans.  My point is that a
language should not adopt a feature simply because it is useful in
another language.  It has to fit the spirit of the language as well.

Be careful of thinking that "useful" means "I can do the same thing in
language X in the same way I do it in language Y".  Eventually, X == Y.

-Jim

_______________________________________________
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

Ryan Joseph


> On Jul 17, 2018, at 12:24 PM, Jim Lee <[hidden email]> wrote:
>
> It has to fit the spirit of the language as well.

I don’t propose new features to copy other languages but I’ll mention other languages as evidence that more people than just myself have discovered some merit to the concept (i.e. a form of validation). When I say c++ does ___  too I take that as a good indication many other programers who work in a similar language had the same problem I did.

If lots of programmers using main stream languages like c++ are having a similar problem we are I think it’s incumbent for Pascal to at least consider if there is merit to the concern.

Regards,
        Ryan Joseph

_______________________________________________
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 Michael Van Canneyt
On 17/07/2018 15:34, Michael Van Canneyt wrote:

>
>
> On Tue, 17 Jul 2018, Vojtěch Čihák wrote:
>
>> Hi,
>>
>> Lazarus has option "Show Class/Proc Hint" which displays method name
>> (with light-green background) as the top line in source editor, only
>> if the method's body is longer than number of lines in source editor.
>> Maybe new option "Show Proc var block" for permanent displaying var
>> block in long methods would be enough? Jumps between code and
>> declaration would not be needed.
>
> If such a thing is implemented, then why not make it as the 'local
> variables' debug dialog, a separate floating window, maybe stay-on-top  ?
>
> If you put it at the top of the source editor, it risks to take a lot
> of space out
> of the source editor window, which kind of defeats the purpose, I
> suppose.
- Clone the current source editor, so you get another window.
- Scroll it to the block you want
- Resize it as needed
- Select "Lock Page" from the tabs popup menu
   (This will prevent, codetools from scrolling this window, if you
navigate in the unit)

The result:
- you keep the variables in view
- if you "jump to declaration" of a variable (that is not visible in the
current window), it will jump to it in the "locked" window
- if you jump back to previous location, you will be back in the
unlocked window

_______________________________________________
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

Jim Lee
In reply to this post by Ryan Joseph


On 07/17/18 11:50, Ryan Joseph wrote:
>
>> On Jul 17, 2018, at 12:24 PM, Jim Lee <[hidden email]> wrote:
>>
>> It has to fit the spirit of the language as well.
> I don’t propose new features to copy other languages but I’ll mention other languages as evidence that more people than just myself have discovered some merit to the concept (i.e. a form of validation). When I say c++ does ___  too I take that as a good indication many other programers who work in a similar language had the same problem I did.
>
> If lots of programmers using main stream languages like c++ are having a similar problem we are I think it’s incumbent for Pascal to at least consider if there is merit to the concern.
>

I disagree.

Pascal is a language (originally) intended to be used to teach
structured programming concepts, and also to be a practical production
language *in that same domain*.

When Mr. Wirth saw the merits of modular programming, he did not try to
retrofit that functionality into Pascal - he instead created a new
language, Modula-2, and later, Modula-3.

When Mr. Wirth later saw the merits of object oriented programming, he
did not try to retrofit that functionality into Pascal or Modula - he
instead created a new language, Oberon.

On the other hand, both Apple and Borland chose to extend their versions
of Pascal with these newer concepts (and several others), turning Pascal
into a multi-paradigm language.  That was in the day and time when
commercial interests were more important than language design.  It was
also a time when products were judged by the number of features
included, not by their quality.

Now, I happen to think that both structured and modular programming
belong together, and that Wirth could have added modular extensions to
Pascal without destroying the spirit of the language.  However, what is
known as "Object Pascal", to me, should be a separate language, with a
different name.   Not better, not worse, just different.  And that's why
I hesitate whenever someone comes along and says we should add <feature
of the day> to Pascal.

-Jim

_______________________________________________
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 Ryan Joseph
Am 17.07.2018 um 20:00 schrieb Ryan Joseph:
>
>> On Jul 17, 2018, at 11:27 AM, Jim Lee <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Syntax changes suggestions

Ryan Joseph
In reply to this post by Jim Lee


> On Jul 17, 2018, at 2:07 PM, Jim Lee <[hidden email]> wrote:
>
> And that's why I hesitate whenever someone comes along and says we should add <feature of the day> to Pascal

I just want my life to be easier and to enjoy programming in Pascal as much as possible. If I’m doing work I don’t have to, merely knowing that Pascal has remained pure to the original specification is not very much comfort to me.

Regards,
        Ryan Joseph

_______________________________________________
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

Ryan Joseph
In reply to this post by Free Pascal - General mailing list


> On Jul 17, 2018, at 2:15 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>
> 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.

Maybe FPC needs a fork or something that keeps the original specification, or going the other way an experimental branch? Florian amongst others must be really annoyed with how this is all going and I sympathize with them.

FPC appears to have group of users who are purists (or something like that), Delphi users, and utilitarians (if that’s accurate a description) that want the language to evolve to meet current trends/demands of the industry, e.g. if there’s a good idea floating around out there I want to use it also.

Going forward how is this going to be resolved?

Regards,
        Ryan Joseph

_______________________________________________
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
Am 17.07.2018 um 22:32 schrieb Ryan Joseph:
>
>> On Jul 17, 2018, at 2:15 PM, Sven Barth via fpc-pascal <[hidden email]> wrote:
>>
>> 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.
> Maybe FPC needs a fork or something that keeps the original specification, or going the other way an experimental branch? Florian amongst others must be really annoyed with how this is all going and I sympathize with them.
>
> FPC appears to have group of users who are purists (or something like that), Delphi users, and utilitarians (if that’s accurate a description) that want the language to evolve to meet current trends/demands of the industry, e.g. if there’s a good idea floating around out there I want to use it also.
>
> Going forward how is this going to be resolved?
There is a more important difference: the developers and the users. Only
because the latters think an idea is good or probable the former do not
necessarily need to agree. And don't forget that we, the developers work
on this in our free time and thus don't have any interest on spending
time on features that we don't believe in.

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

Martin Friebe
In reply to this post by Jim Lee

On 07/17/18 11:50, Ryan Joseph wrote:

If lots of programmers using main stream languages like c++ are having a similar problem we are I think it’s incumbent for Pascal to at least consider if there is merit to the concern.



So if a lot of programmers find it bad to have to much freedom, then it is good if it is restricted?

Because take JavaScript, well there freedom of declaring variables is even less restricted, than was asked for in this thread.
But it seems that many JavaScript developers got frustrated with that. So much that the now have external tools to restrict that freedom

http://www.adequatelygood.com/JavaScript-Scoping-and-Hoisting.html
https://eslint.org/docs/rules/vars-on-top

This is not directly related to the original post/request.
But it shows that the statement quoted on top is severely dangerous.

Just because another language has a feature, or even because many use it (where it is not know what expertise those have, nor how many do not use it)...
Just because any of this, does by no means indicate that such a feature is any good at all.

Just because c++ has the feature does not mean that it solves any problem that c++ programmers would otherwise have. It can same as good mean the opposite.

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