New modern Pascal dialect is subject of this topic.

Is any way to get branch for new pascal dialect and for generics.collections improvements? For me ObjFPC is too much conservative and Delphi after XE2 version, really sucks, so $MODE Delphi is not option.

I think is good idea to discuss new dialect. I really like some elements from ObjFPC, also from Delphi and from Oxygene (we can't implement pure $MODE Oxygene but some ideas are good). To combine best of mentioned dialects elements we need to create new $MODE. I call my new dialect "Sparta" (yes it is related to freesparta.com) but I can change this name.

I have some concerns, that all my effort for new dialect even if I done some work will be useless.

If you wish, I can prepare some "manifest document" related to new language dialect details.

Let me know if there is no option for that initiative.

Best Regards,
Maciej Izak

I think you better choose some more neutral name: GenPas or so.

You are free to do so, no-one will stop you. Your work will surely be integrated.

But I advise against it: The Pascal community is splintered as it is: FPC, Delphi, Oxygene. Creating another dialect will not help, because your code will only be usable in that dialect. We could rather use the help to improve the Delphi mode, to make sure it is on par with Delphi.

IMHO Adding more language features is not going to save pascal. Adding more libraries will be of more help.

Listening to all these arguments, I cannot help but think: Poor C devs. They are really backwards.
One wonders how the Linux kernel and Windows OS got where they are today.

Michael.

2015-07-17 9:10 GMT+02:00 Michael Van Canneyt:

I think you better choose some more neutral name: GenPas or so.

IMO GenPas is good name.

I don't want to introduce too many new syntax elements, only best possible combination of existing dialects elements. In the new dialect we can clean up few things. The main ideas of new dialect -> less is more and KISS.

Listening to all these arguments, I cannot help but think: Poor C devs. They are really backwards. One wonders how the Linux kernel and Windows OS got where they are today.

We have different opinions but thanks that, we can achieve good result. :)

best regards,
Maciej Izak

I have my moments of inspiration ;)

Many, if not most, language constructs in the compiler are enabled/disabled through some modeswitch:
{$MODESWITCH XYZ}

I think that the best that can be done is make sure all dialect elements can be enabled/disabled using a modeswitch. The {$MODE XYZ} directive then just needs to set a pre-defined set of modeswitches.

IMHO It will save you work if you go about it this way...

Michael.

Maciej Izak wrote

I think is good idea to discuss new dialect.

The Code-aware String implementation could be much better than as well in Delphi as in fpc, but this only makes sense when the TStrings type (and it's descendents) and the interface to many libraries are done appropriately to that paradigm (and hence rather differently than right now). Nonetheless the user could would (in close to all instances) not need to be modified, nor would the performance be degraded in a noticeable amount.

You might want to read details here:

http://wiki.freepascal.org/not_Delphi_compatible_enhancement_for_Unicode_Support

-Michael

In our previous episode, Maciej Izak said:

New modern Pascal dialect is subject of this topic.

Modern is a very vague term, and more a matter of taste.

Is any way to get branch for new pascal dialect and for generics.collections improvements? For me ObjFPC is too much conservative and Delphi after XE2 version, really sucks, so $MODE Delphi is not option.

But what does it actually prohibit ? Not agreeing with Delphi design choices is as old as Delphi itself.

{$mode YAMPD} - Yet Another Modern Pascal Dialect ?

I have some concerns, that all my effort for new dialect even if I done some work will be useless.

I would focus more on the feature themselves, and worry about grouping them into dialects later. There are escapes using {$modeswitch } anyway, and making your changes compatible with multiple modes should take precedence about creating a new dialect mode.

Maciej Izak wrote

New modern Pascal dialect is subject of this topic.

Do you mean your Generics.Collections would compile only with the new mode? Sounds very bad to me.

Juha

mode?

Sounds very bad to me.

Modes are per-unit anyway. So even if the Generics.Collection would only in this proposed mode you would still be able to use it in other modes (at least if generics are supported, e.g. for ISO or Delphi7 they would need to be disabled (not yet possible) and thus you couldn't use those units of course).
So I see no inherent problem with that.

Regards,
Sven

@Michal, @Marco

Right, I will start from set of MODESWITCHs.

2015-07-17 9:59 GMT+02:00 Marco van de Voort:

Modern is a very vague term, and more a matter of taste.

But what does it actually prohibit ? Not agreeing with Delphi design

choices is as old as Delphi itself.

Subjective matter. Modern maybe is not proper definition. I mean more functional programming with less syntax. Evolution for better usage of Generics.Collections.

IMO ObjFPC is more classic, Oxygene is modern, Delphi after XE2 is crap :)

{$mode YAMPD} - Yet Another Modern Pascal Dialect ?

Not bad, but I really like {$MODE GenPas} proposed by Michael. Acronym from Generic Pascal ^^ sounds good. Eventually {$mode YAMMGPDWSP} - Yet Another More Modern Generic Pascal Dialect With Smart Pointers.

best regards,
Maciej Izak

2015-07-17 11:33 GMT+02:00 Juha Manninen:

Do you mean your Generics.Collections would compile only with the new mode? Sounds very bad to me.

Using the Generics.Collections does not impose the use of {$MODE GenPas}.

I am working on set of MODESWITCHs. As mentioned above in my previous e-mail I mean more functional programming with less syntax. Evolution for better usage of Generics.Collections (like smart pointers).

Even smart pointers will be available in any other mode. In {$MODE GenPas} will be available additional syntax inspired by Oxygene dialect, dedicated for smart pointers:
http://docs.elementscompiler.com/Platforms/Cocoa/StorageModifiers/ .

best regards,
Maciej Izak

In our previous episode, Maciej Izak said:

IMHO the whole point of generics.collections is that its usage is Delphi compatible.

2015-07-17 15:03 GMT+02:00 Marco van de Voort:

IMHO the whole point of generics.collections is that its usage is Delphi compatible.

part of interface is compatible. It's good designed. FPC Generics.Collections implementation is very different and extended.

Delphi "Generics.Collections" is inspired by C# namespace "System.Collections.Generic" and by "C5 Generic Collection Library" ( http://www.itu.dk/research/c5/ ).

IMO it's like non formal standard/pattern of using of collections.

best regards
Maciej Izak

If delphi has a unit called "generics.collections" and then we introduce a unit with the same name, it should have the same interface and functionality (except where not possible due to cross-platform concerns etc).

Extensions are possible, but they should be put in separate units so that if Delphi extends its unit later in a different way, you can't get conflicts.

Jonas

Same interface and functionality is priority of the library. But it's not that easy. It depends on many low level compiler details. In few cases fully compatibility is impossible. You can check how compatible it is:

https://github.com/dathox/generics.collections/raw/master/GenericsCompatibilityMatrix.pdf

Extensions are possible, but they should be put in separate units so that if Delphi extends its unit later in a different way, you can't get conflicts.

That can be improved.

Best regards,
Maciej Izak

I don't know if a new dialect would be widely accepted by all developers (specially veteran pascal programmers), but if it could become things more practical and more productive, I would be in favor of just "{$ mode ObjPas}". =)

Veteran Pascal programmer here...

I haven't really started using it yet, but I read through the whole Oxygene documentation the other day. (Didn't take long ;-) )

The Oxygene dialect is absolutely beautiful in my opinion. Lots of things in there that I've been wanting for decades and many stupid things dropped completely. Silly example: var declarations when you need them like C. Practical example: parallel programming built into the language as opposed to Delphi XE7/8's really ugly solutions with their "parallel library". (I can go on with examples with the OP's permission).

I agree with the OP that the Delphi language had become uglier and uglier. I want a programming language that looks good when I write it. This is why I am still using Object Pascal and not Java or C#. If FPC's only goal is Delphi compatibility, then perhaps I won't be on this list anymore some years from now.

The world is looking for a new language. That is why we recently got Google's Go and Apple's Swift. I believe a modern and clean dialect of Object Pascal has a "leg-up" on both of these.

Now, this is related but OT: CPU-native compilation is becoming outdated just like Assembly programming did. I always used to _hate_ .NET and Java, but using a platform's own stack must surely be the future. Example: Delphi XE8 cannot produce a binary for Android on Intel Atom. With Java you would never have encountered this problem. (There are a lot of tablets currently being produced with Atom processors).

So will FPC "embrace the future"? Or is the project only geared toward "veteran pascal programmers" that don't share my vision?

Best regards,

Paul van Helden.

Since some work is already done in this direktion and since somone, who likes another flavor better, is able to also benifit from such changes I would rekommend to work in that direction.

Greets Steve

What's the point of waiting FPC update then?
Isn't it better just to stop using FPC, convert the source code to Oxygen and use Oxygene instead?

When all new syntax features are added to default pascal mode, I'll have to patch the compiler introducing {$mode retro} :)

Wider variety of libraries is the solution to the language popularity. The better libraries api is the solution to "syntax limitation" problem.

thanks,
Dmitry

2015-07-17 19:32 GMT+02:00 Dmitry Boyarintsev :

What's the point of waiting FPC update then?

Isn't it better just to stop using FPC, convert the source code to Oxygen

Proposed mode is not proposed as default pascal mode. You are safe :P. You will be able to using classic pascal forever. So what is the problem?

Best Regards,
Maciej Izak

2015-07-17 17:44 GMT+02:00 Paul van Helden

Nice to hear that. You are probably unique "Veteran Pascal programmer" ;)

I agree with the OP that the Delphi language had become uglier and uglier.

The Truly Truest Truth :) , especially part about Delphi

Best regards,
Maciej Izak

Maciej Izak wrote

Proposed mode is not proposed as default pascal mode. You are safe :P. You will be able to using classic pascal forever. So what is the problem?

Is it better to spend compiler-development time to such staff as improving compiler speed, generating faster code , better debugging info generation, rather than adding more syntax features?

thanks,
Dmitry

I'm newbie in pascal language, but I know for sure, that Open Source community driven by "technical" ideas shouldn't copy commercial moves. The fact that Google introduced Go and Apple introduced Swift, doesn't mean that Java or Objective-C are bad/outdated languages/frameworks.

Also the fact that Google and Apple were able to inspire some interest to the new languages, adding some extra money to promoting them. Yet, it doesn't mean that FPC would be able to do the same.

thanks,
Dmitry

2015-07-17 9:00 GMT+02:00 Maciej Izak :

New modern Pascal dialect is subject of this topic.

Btw. More 2009-XE2 compatibility level is minimum (best times for Delphi language when Barry Kelly was on the Embarcadero board). This is start point, and solid base to introducing new important improvements (with small exception for example for TValue from RTTI module - to perform best performance on all platforms without hacks I need to finish small MODESWITCH). Without this compatibility level I am not able to do many syntax related to new mode. That is why I am working on Generics.* and RTTI.pas and some low level patches for RTL/compiler.

Anyway during working on compiler if some language elements "oxygene flavored" are not so complex and can be added "ad hoc", IMO they should be added.

Providing compatible syntax with Delphi for versions later than XE2 is worst thing that we can do ever (especially compatibility with NEXTGEN crap compiler). When Barry Kelly left company, AFAIK somewhere after XE2 times they hired NEW compiler team in Romania to cut costs...

Best regards
Maciej Izak

Am Friday 17 July 2015 21:23:58 schrieb Maciej Izak: litle OT:

. When Barry Kelly left company, AFAIK somewhere after XE2 times they hired NEW compiler team in Romania to cut costs...

Rudi and Nick are still active in the Newsgroups there so no hope is lost ;) They will tell us all the time that Delphi is the greatest tool on earth.

In our previous episode, Maciej Izak said:

Anyway during working on compiler if some language elements "oxygene flavored" are not so complex and can be added "ad hoc", IMO they should be added.

I think you'll find the need for ARC or GC on every feature you implement.

Hi all,

There's been recent talk about adding a new dialect and such, and I just wanna weigh in that I don't think it's a very good call to split Free Pascal even more.. I believe Free Pascal had such potential.. And the reason I mention 'had' is the fact that makes Free Pascal 'strong' also makes it it's biggest weakness and downfall; The fact that there is no direction and lead, and everyone can add whatever they want. The difference between Free Pascal and successful big languages are *leadership*, *roadmap*, *community*, *support*. Now I know the usuals will start immediately thinking 'yes but it's all volunteer, we don't have the man power' .. Why is many other languages believed to be more popular?

*Standards**.*

If we had a group of people that designed standards (/a group document??/), people like me can see the new standard and say 'oh, nice I like that feature, I'm gonna implement it'. Let's say someone else makes a completely LLVM compiler based on that standard? So what if it's not one program, at least Pascal would 'survive'. Just like ECMAScript, C++, PHP, most languages now have a 'standards' document behind it. That's their *roadmap*. Their *leadership*. Design it and the *community* will show *support*. I know I would actually feel like working towards it, because then I know when they are approved I'm not wasting my time creating features and such, just to have them rejected and never implemented. ;)

I would personally love to add to such standards, and we can add some of the collective wisdom of ours. :) (/I have 22+ years of experience with Pascal, and I'm sure Florian, Sven, Marco, and Jonas all have similar if not much more; and would be excellent at adding to the standard/)

- Dennis Fehr

Why do you say there is no support ?
There is. Mailing lists, forums, and even a company that offers paid support.

What stops you from starting such an effort ?
You can start e.g. by adding the tuples idea which was discussed on the mailing list several years ago. I have 28 years of Pascal experience which is completely at your disposal...

Michael.

Den wrote

Just like ECMAScript, C++, PHP, most languages now have a 'standards' document behind it. That's their *roadmap*. Their *leadership*. Design it and the *community* will show *support*.

ISO Pascal and ISO Extended Pascal were like that in the early 90s:
1) there was an official ISO standard and standards committee for it
2) there were a number commercial compilers supporting it such as HP Pascal and IBM's compiler for its System/370
3) later on (in 1996) a GCC-based implementation arrived for it (the equivalent of the LLVM of the moment)

And still almost no one uses ISO/Extended Pascal anymore. Why? Possibly because the de facto Pascal standards had already become Think Pascal on the Mac and Turbo Pascal on the PC by then, and none of those programmers wanted to rewrite all of their code (although Think Pascal was a bit closer to ISO Pascal). Or maybe because in general, many people just preferred those language dialects for one reason or another. In any case, introducing one new standard to rule them all seldom (if ever) works (and you can bet someone will be unable to resist to add a link to the related xkcd comic).

Standards do not magically make a language more popular. They only work if they follow from a desire of an entire community to design one and to adhere to it. "Design it and the community will show support" is exactly the opposite of what happens in practice.

Jonas

It doesn't even work for magical rings. Although it took 3000 years to find that out.

Nevertheless, I must agree a roadmap for FPC with some detailed proposals would be nice.

Michael.

In our previous episode, Jonas Maebe said:

That's my opinion too. The succesful standards are either concerted efforts of the major stakeholders/vendors or simply legatimize the de facto situation.

Standarization efforts that start out as "Let's invent a language" rarely pay off (as in: having multiple implementers).

I was selling and supporting development tools in the late 80s. From memory, there was one compiler (in the PC arena) that prided itself on robust ISO Pascal support and expressed little interest in extending towards any of the de-facto standards: nobody bought it. Their Wp page still claims "It is the only compiler in existence that fully implements the ISO 10206 standard for Extended Pascal."

I still have occasional problems with an "old hand" on a private conferencing system I use. He worked for Olivetti in the 80s, and found that he and his colleagues were mandated to write an operating system and support software in unextended ISO Pascal. In retrospect, that is universally recognised as being an inappropriate combination, but almost everybody at the time could see it as well... he still misses no opportunity to denigrate pascal as being grossly incomplete for "real work".

This one? https://xkcd.com/927/

Standards do not magically make a language more popular. They only work if they follow from a desire of an entire community to design one and to adhere to it. "Design it and the community will show support" is exactly the opposite of what happens in practice.

Which in practice means that we'd need to get all of the major "post-Borland" compilers pulling in the same direction, starting off with Gnu Pascal, and would need to get Embarcadero committing themselves to long-term language stability.

Formal standards only work if they have the support of a major standards body from day one. And informal industry standards normally take the form of openly-published documentation, and we've got that in abundance (but if Den wants to help with the indexing, I'm sure we'd all appreciate it).

Michael Van Canneyt wrote

Nevertheless, I must agree a roadmap for FPC with some detailed proposals would be nice.

I've created a page with what I know is under development at http://wiki.freepascal.org/FPC_Roadmap

Just arbitrary proposals of what some people think would a be a good idea doesn't seem very useful to me, because in general the problem is not so much lack of ideas as it is lack of time, the ability to implement them and keeping the language and compiler clean and maintainable.

Jonas

Hence the 'with some detailed proposals'.

Michael.

maintainable.

Especially the "maintainable" is important. The more I work around in the parser the more I have the feeling that sooner or later we'll have to rework it. Analogous to how the backend was reworked for 2.0.0.

Regards,
Sven

Sven Barth wrote

Modes are per-unit anyway. So even if the Generics.Collection would only in this proposed mode you would still be able to use it in other modes (at least if generics are supported, e.g. for ISO

In ISO mode the uses keyword is turned off, so you even cannot use units :)

ISO Pascal was a born a dead horse. Borland, itself taking pieces of USCD Pascal (Units, Strings) became the "de-facto"standard and that is what the initial goal was when Florian started the compiler way back when. Later, Free Pascal followed what was set by Delphi, making the most sense.
Now today, I do not necessarily agree with the direction Embarcadero heading these days with Delphi and most importantly (for me), I do not agree with all those attempts to add "features" of other languages to Free Pascal. I appreciate the efforts of the folks involved in Free Pascal for a long time, as this provides me with the opportunity to keep working in the programming language/environment that for me makes the most sense and that I am used to for 38 years. And I honestly loath to see that people argue that there should be new language constructs and such, just because it is what more popular programming languages provide. I am not in to participate in a popularity contest, I am trying to get work done...

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

I am quite aware of ISO Pascal.. Though, to be fair it wasn't well known and the tools for adding 'rfc' style proposals must not have been great? I've proposed a few new properties to the CSS documents standard, and you know what? It felt great. They're discussing it now and I can track it. If it succeeds, it will be implemented. It's things like that, having a group effort with the documents and the actual 'technical engineers' work on it. You won't have to worry about big heads and businesses taking over the document, as it will be an open effort, just like FPC is. When someone looks at a roadmap, that's the 'output' people look to and see on what to expect in the future. What we'd be doing is discussing proposals and such to make Free Pascal a standard. Who knows? Maybe Delphi would start trying to implement our standards?

Is there any such online software anyone is aware of, that is an easy 'proposal'/'rfc' style interface? Where you can make suggestions, comments and votes on each proposal? If there is enough votes on a particular proposal someone could see the potential and add it without fear of it not being accepted.

- Dennis Fehr

"Ralf Quint" wrote

Now today, I do not necessarily agree with the direction Embarcadero

heading these days with Delphi and most importantly (for me), I do not agree with all those attempts to add "features" of other languages to Free Pascal. I appreciate the efforts of the folks involved in Free Pascal for a long time, as this provides me with the opportunity to keep working in the programming language/environment that for me makes the most sense and that I am used to for 38 years. And I honestly loath to see that people argue that there should be new language constructs and such, just because it is what more popular programming languages provide. I am not in to participate in a popularity contest, I am trying to get work done...

The way we write software evolves however. Things that were thought as state of the art 25 years ago aren't necessarily nowadays (for example procedural programming that has been mostly superseded by object oriented programming). And in this regards programming languages are like natural languages: they evolve, they change. If a language doesn't evolve anymore it can be considered dead (e.g. Latin, Ancient Greek). So I personally support the addition of new features to FPC as long as they don't interfere with backwards compatibility and fit into the language as a whole.

Regards,
Sven

In our previous episode, Sven Barth said:

The question though if a few haphazardly copied features make a 20+ year old project suddenly state of the art. Some of the "old" stuff goes deep.

Translation "modern" comic books to Latin didn't really have a lasting affect on Latin uptake.

oriented

> programming). And in this regards programming languages are like natural > languages: they evolve, they change. If a language doesn't evolve

anymore

> it can be considered dead (e.g. Latin, Ancient Greek). > So I personally support the addition of new features to FPC as long as

they

> don't interfere with backwards compatibility and fit into the language

as a

> whole. The question though if a few haphazardly copied features make a 20+ year

old

project suddenly state of the art. Some of the "old" stuff goes deep.

Of course. But there aren't only "20+ year old project[s]". While it might be not always worthwhile to use new features in an old project they can nevertheless be useful when you're working on a new project from the ground up.

Regards,
Sven

+1

Regards,
Marcos Douglas

But evolving doesn't mean you have to turn (Free)Pascal in another incarnation of Python, Ruby, Haskell or whatever. And a lot of basic programming paradigms that existed 25 years ago are just as valid today. There is nothing wrong with procedural programming, just as there is nothing inherently wrong with object oriented programming. You can abuse and misuse both approaches. And quite frankly, what I have seen in object oriented code in recent years, I would rather take as a negative example of evolution, of ways/things not to go/do...

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Ralf Quint wrote

[...] And quite frankly, what I have seen in object oriented code in recent years, I would rather take as a negative example of evolution, of ways/things not to go/do...

That is true.
Many programmers think that coding using object orientation only because they use an object-oriented language. They also think that using a more "cool" syntax makes your code more "professional".

But some evolutions in a language could be a good thing, as Sven have said.

Regards,
Marcos Douglas

if not (X is TSomeClass) then ..
if not (5 in [1,2,3]) then ..

What is wrong with a language evolving to allow (in addition to the above)?:

if X is not TSomeClass then ..
if 5 not in [1,2,3] then ..

I'm not a compiler programmer, but it almost seems like laziness that the second case is not possible already? Maybe something is really hard with multi-word operators?

I like Pascal because it is more readable than Java, C#, Ruby, Haskell, etc. IMO the design philosophy should be: "if it is more readable it should be allowed".

Convenience should be added to this. Take for example type inference. If the compiler can easily figure out the type of a result, why should I have to declare a variable first with the appropriate type? Of course that means to allow var declarations inside the code block. Something I've always wanted to see in Pascal since my brief stint with C++ in the early 90s. The standard argument against is probably "that is unPascallish" or that it is moving away from strong typing. I disagree: if the compiler can figure things out before runtime you still have strong typing. So, for example, I would like to declare something like this anywhere inside a begin..end block:

var A := SomeClassInstance.SomeFunction;

It *looks* like JavaScript's (etc) weak typing but it is not. The compiler will catch any mischief that may follow with the variable A. We've eliminated a line of code that needs to be changed if the type of the function result changes. And to me it still looks very Pascallish..

I can carry on.. tuples can save lots of lines of code while at the same time making it more readable. How as that not "cool"? :-) (or functional for that matter!)

If the "not" operator is overloaded in TSomeClass, "not TSomeClass" can be a valid expression in itself. "not in" could never be anything else, but consistency is also very important.

Additionally, keeping the compiler fast and maintainable (and able to produce sensible error messages when syntax errors are found) conflicts with arbitrary word orders. Calling that laziness is a bit blunt.

IMO the design philosophy should be: "if it is more readable it should be allowed".

Allowing multiple ways to say the same thing generally does not increase readability, even if in isolation it can look fine.

Jonas

evolution, of

said.

above)?:

second case is not possible already? Maybe something is really hard with multi-word operators?

The compiler is geared towards single word operators (combined with their precedence).

Convenience should be added to this. Take for example type inference. If

the compiler can easily figure out the type of a result, why should I have to declare a variable first with the appropriate type? Of course that means to allow var declarations inside the code block. Something I've always wanted to see in Pascal since my brief stint with C++ in the early 90s. The standard argument against is probably "that is unPascallish" or that it is moving away from strong typing. I disagree: if the compiler can figure things out before runtime you still have strong typing. So, for example, I would like to declare something like this anywhere inside a begin..end block:

var A := SomeClassInstance.SomeFunction;

While I agree that type inference /might/ be useful I don't agree with inline variable declarations. One of the main points of Pascal is declare before use. While this is somewhat violated with Delphi compatible generics there one could at least argue that the specialized type is implicitly declared by the generic declaration...

Regards,
Sven

Well, apologies for using the word "laziness". I simply meant that to someone who doesn't understand the complexities of compiler programming it seems as (almost) such. I still believe (in my ignorance) that it shouldn't be all that hard to have multi word operators like in SQL, but what do I know. I have personally found little use for operator overloading and I would be happy to have such restricted to things other than "not" or "not is".

There are always multiple ways to say the same thing, and especially in programming, so I don't understand your point. Perhaps I can try to explain myself: The only reason I have stuck with Pascal for more than two decades is because of the way the written language *looks*. I find it pleasing compared to other languages. So please understand my arguments as coming from that perspective. I may be wrong technically or practically, but this is how I feel and I am sure there are others that feel the same.

In our previous episode, Paul van Helden said:

Evolution in languages is like the evolution in organisms. Those who evolve wrong or expend energy on features that are not contributing to survival eventually perish.

So basically it all boils down to benefit/cost tradeoff, with cost both implementation AND maintenance.

Is it technically infeasible to expand this to two-word operators? SQL did it..

I have never managed to understand why "declare before use" is so important to Pascal. I get the bit about strong typing and doing everything possible to eliminate errors at compile time, but I still don't get why. If this is central to what makes something "Pascal", I would love to be pointed to a good explanation. I'm not trying to be a pain here. I've been programming in Pascal, full time, for most of my life. It has always puzzled me why everything has to be declared first.

just trying to add to the conversation about improving the language which I love. And I'm not even suggesting anything new: these are concepts already embraced by main-stream languages. For new projects Object Pascal seems to be going the way of the dinosaur and I would like to see my favourite compiler (FPC) compete with more than Delphi. Oxygene, for example. If FPC+Lazarus is simply the anti-Delphi (to clarify: the open source alternative to / clone of Delphi), then I guess I am barking up the wrong tree. It just seems that this group is the only hope for an open source modern Pascal right now... :-)

+100

Things like this is just because people are trying to be lazy, not because this does improve code (human readable or otherwise). Someone who is trying to use a construct like the one mentioned above is nothing but lazy, is not properly designing his/her software. And that is against what Pascal should stand for.
Humans miss a lot of times a third hand, but this isn't likely to happen that we grow one anytime soon. So get used to properly using what you have...

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Consider the following code:

procedure Test;
var i : integer;
begin
   for J := 1 to 25 do
     writeln;
end;

With "Declare before use", this is plainly incorrect. J has not been declared; You can't type; You are an idiot!

In your world, it may be an error (see above), it may be a warning; I has been declared and not used. You may have warnings switched off and never even see it!

I like my compilers to find as many errors in my code as possible

Ralf, I guess I'm talking about losing the third hand and join all the other languages with two hands (so, minus the var block before begin :-) ). This is not about being lazy, but about being less verbose. Or in other words shorter text which is more expressive and more readable.

Not without reworking quite some parts of the parser.

Because with that you have specific locations where variables are declared. You can see with one look (yes, I'm simplifying here) what variables are used in the function even if you don't have a fancy IDE that highlights it.

Regards,
Sven

That's sounds like the guy from Symbolics 30 years ago, when he tried to convince me that Lisp is the most expressive and readable programming language... ;-)

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2015-07-22 19:47 GMT+02:00 Sven Barth :

Sorry Sven but I do agree with inline variable declarations. You don't have exclusive rights to dictate what is main point of Pascal (there is also Oxygene, SmartPascal). This is your opinion and this is not ultimate truth. There is also community with experienced users and big part of this community (especially around Delphi and Oxygene, not around FPC core development team :P) needs modern open source Pascal.

Some people love Oxygene, and you can't tell that the Oxygene is not the Pascal. Any new construction will be "non pascalish" at first glance.

Best Regards,
Maciej Izak

In our previous episode, Maciej Izak said:

By that reasoning I can't tell that C++ isn't the new Pascal either.

2015-07-22 20:20 GMT+02:00 Paul van Helden :

Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes.

But declare before use is also part of the Pascal philosophy. Pascal tries to prevent you from programming by just throwing in some straws, some nails and a bit of wire when needed. Pascal was designed so that you have to plan first and code only when your plans are ready. If you want to do quick and dirty programming (I agree doing complete plans before would sometimes be overkill), then use a scripting language. Of course, other 3rd gen languages also allow you to do completely structured programming, but Pascal was created to push users to do it. There is a joke about Pascal that Pascal is so coercive about "good programming" that you could program in Pascal for years and still not learn how to program correctly. Hmm, maybe this is not entirely a joke :-)

2015-07-22 23:16 GMT+02:00 Marco van de Voort :

By that reasoning I can't tell that C++ isn't the new Pascal either.

Everything is relative. Languages derived from each other and that's ok.

best regards,
Maciej Izak

Since the value of J is undefined at the normal exit of a for loop, one might be tempted to allow implicit definition. But what about this case:

for j := 0 to 24 do
   if j = 12 then
     break
   else
     WriteLn;

What is j here, and what would it be if an implicit j were defined which only had the scope of the loop?

The whole issue of variable declarations appearing before begin is central to the distinction between ALGOL (and derivatives including C) and Pascal (and derivatives including Modula). A related issue is whether a variable's type appears before (ALGOL, C) or after (Pascal, Modula) its name.

Another issue is whether if...then is followed by a single statement (ALGOL 60, Pascal) or by multiple statements followed by fi or end (ALGOL 68, Modula). And then there's x := if...then...else...; which exists in ALGOL and (in a more compact form) in C, but not in Pascal and its derivatives.

And those are the shibboleths by which Pascal are recognised.

"Maciej Izak" wrote

2015-07-22 19:47 GMT+02:00 Sven Barth : > > While I agree that type inference /might/ be useful I don't agree with

inline variable declarations. One of the main points of Pascal is declare before use. While this is somewhat violated with Delphi compatible generics there one could at least argue that the specialized type is implicitly declared by the generic declaration...

have exclusive rights to dictate what is main point of Pascal (there is also Oxygene, SmartPascal). This is your opinion and this is not ultimate truth. There is also community with experienced users and big part of this community (especially around Delphi and Oxygene, not around FPC core development team :P) needs modern open source Pascal.

This is not merely my opinion.

Some people love Oxygene, and you can't tell that the Oxygene is not the

Pascal. Any new construction will be "non pascalish" at first glance.

No, that depends heavily on the specific construction. Mostly whether it was obviously just "ripped" from other languages like C# without giving a second thought about the way how things should be done in Pascal (for example attributes or Delphi's generics) or not (for example tuples in Oxygene).

Regards,
Sven

2015-07-23 8:04 GMT+02:00 Sven Barth :

The same on my side. There is a great opposition. So again : this is not ultimate truth.

IMO Delphi/Oxygene generics are better for real life development. FPC specialize keyword is nightmare and not intuitive construction. Generics should be short in usage. They exist for clear and reusable constructions. I need to cite you: "Prefixed modifiers are the /worst/ you can do for Pascal.". By introducing "specialize" keyword, you deny yourself.

So when some crap construction is introduced by FPC team, all is ok, but any proposed solution that is clear/clever, it becomes /non pascalish/, /not main point of Pascal/ and /worst/ thing ever.

Ripping smart and productive constructions is good thing. They don't need to be pascalish as hell.

best regards
Maciej Izak

Oxygene is no longer pascal. It's just C# with pascal keywords. a pityful copy. If you want the features of C#, you should use C#, full stop.

Regarding inline declarations:
Pascal is about bringing clear structure in your code. Plan first, code then.

From this point of view there is no need for inline variable declarations.

Also, the location of variables is entirely irrelevant with an IDE like Lazarus. Press ctrl-c on a variable and Lazarus inserts it in the correct location, *as required by the language*. It is exactly because the Pascal language is so structured that Lazarus *can* do it.

So: People who think they *need* inline variable declarations need in the first place to use another language than pascal or use a better IDE.

Given that other languages have inline variable declarations since more than 30 years, the statement that having inline variable declarations makes a language "more modern" is pure nonsense.

It is just a wish of people who think that 'anything goes', it has nothing to do with being more productive or being modern.

The 'anything goes' dictum may be nice in modern arts (also often a load of male cow droppings) but has IMO no place in computer programming, where structure is central.

Why do you think Google, MS and some others are trying to add structure to a language like Javascript ? exactly so they can do things in a JS IDE like Lazarus already does. As JS is now, they simply cannot, because the language has no structure.

But then, all that is just my truth. Yours may be entirely different.

Michael.

Yes, they do.

Michael.

2015-07-23 9:22 GMT+02:00 Michael Van Canneyt :

Not completely :)

best regards,
Maciej Izak

2015-07-23 9:21 GMT+02:00 Michael Van Canneyt :

But then, all that is just my truth. Yours may be entirely different.

That is why we have $MODESWITCH and $MODE :). We can all be happy. Please do not destroy the enthusiasm of others.

Best regards,
Maciej Izak ()

I don't mean to, but my bullshit detector is going in the red these days.

For example, the term 'modern' is bullshit and has no place in a technical environment. That's for fashion, where it can change every 6 months.

There have been NO fundamental changes in IT in the last 20 years (probably longer). It has *not* become more modern. It is, however, increasingly hype sensitive
- unfortunately. Terms like 'modern' only add to the hype.

If you want to increase productivity, and think this must be done by changing the language, you are very IMHO very much mistaken, and as a consequence you will have to present stronger arguments to introduce changes.

I don't mind changes to the language, but please use correct and compelling arguments.

This is not perl. Perl also incorporated a lot of elements from all kinds of tools, it became utterly unreadable and is in free fall ever since.

Michael.

2015-07-23 9:21 GMT+02:00 Michael Van Canneyt :

Oxygene is no longer pascal. It's just C# with pascal keywords. a pityful copy. If you want the features of C#, you should use C#, full stop.

C# is in some way "new Pascal" so there is nothing wrong with porting back some features from C# to Pascal ^^. I can't use C#. I want to adopt new FPC dialect for that purpose (Oxygene flavored) :). Damn, probably you must hate me. ;)

Best regards,
Maciej Izak

? simply don't understand why people want to introduce concepts of other languages. Just use the other language, spare yourself the agony.

What confuses me even more: C has been around since as long as pascal. It does not seem plagued by this need to be "modern".

Michael.

Michael Van Canneyt wrote

If you want the features of C#, you should use C#, full stop.

True for syntax variant features.

But *some* syntax candy for common multi thread usage cases (e.g. a "parallel loop") nowadays is a necessity.

-Michael

Support for a parallel loop is more than syntax candy, it is a fundamental language change and hence falls under 'compelling arguments'.

Michael.

2015-07-23 10:12 GMT+02:00 Michael Van Canneyt :

If you want the features of pure pascal, you should use $MODE OBJFPC or TP or FPC, full stop. You can't stop me and others from introducing Oxygene flavored mode.Or if inside FPC team is will to block changes related to Oxygene flavored syntax, let me know and I will try to create fork of FPC compiler.

I suppose that happily such syntax supposedly will be a pure extension and not interfere with the traditional Pascal syntax in any $MODE.

-Michael

Just a couple of reactions:

Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes.

Not really. TCC does a single pass with no intermediate representation. It leaves a gap in the procedure prologue for the code that moves the stack pointer and fills it in when it gets to the end of the function and knows how much space is required for the local variables and temporaries.

There have been NO fundamental changes in IT in the last 20 years (probably longer).

One could argue that multi-core and concern about security are fairly fundamental changes. Both have lead to people trying to do sophisticated static analysis of code whose use of pointers makes that analysis, in general, rather difficult.

Edmund

I think you are mistaken about my motivation:

I have no intention of stopping anyone. Go ahead.
On the contrary: in the end, you do introduce changes, I will even document them.

I don't believe generics are the nec-plus-ultra of pascal (or any language). I documented them nonetheless (Sven: Ping ?)

But I do happen to think many of your arguments are pure bullshit and hype, and of no value whatsoever. I just point that out. I would much prefer that you give REAL technological arguments for your changes.

I also explicitly said that these statements are my personal opinion. So, we can at least agree to disagree, no ?

Michael.

No. It is just more of the same.

I think that, currently, Quantum computing has the potential of introducing a real change. The advent of SSD may have some effect in that in theory you don't need file operations any more, since everyting is in essence RAM.

But that's it.

Michael.

2015-07-23 10:56 GMT+02:00 Michael Van Canneyt :

The most convenient technological argument is compatibility with Oxygene. The rest is in many cases a matter of taste. We can endlessly debate what is more readable :)

Well, that's a political argument, I think: we can choose to be not compatible with Oxygene :) (whether or not this would constitute suicide or not, is up for debate)

The rest is in many cases a matter of taste. We can endlessly debate what is more readable :)

Good. Now you're talking sense :)

I look forward to your contributions!

Michael.

"Maciej Izak" wrote

> > Some people love Oxygene, and you can't tell that the Oxygene is not

the Pascal. Any new construction will be "non pascalish" at first glance.

> > No, that depends heavily on the specific construction. Mostly whether it

was obviously just "ripped" from other languages like C# without giving a second thought about the way how things should be done in Pascal (for example attributes or Delphi's generics) or not (for example tuples in Oxygene).

IMO Delphi/Oxygene generics are better for real life development. FPC

specialize keyword is nightmare and not intuitive construction. Generics should be short in usage. They exist for clear and reusable constructions. I need to cite you: "Prefixed modifiers are the /worst/ you can do for Pascal.". By introducing "specialize" keyword, you deny yourself.

I should have written this in the other thread where you mentioned this, but I forgot, so: I agree that "specialize" falls into the same "prefixed modifiers are the worst" category. The cleanest way for specializations would be something like "TMyGeneric with (Longint, String)" or so, this way there would be no potential disambiguity.
Nevertheless "specialize" had been introduced before my time, so I'm merely working with what already /is/ part of the Free Pascal dialect (generics were first introduced in 2.2 and I started working on the compiler with 2.6).
That said: I /am/ working on Delphi compatible generics (in fact 3.0 is a big improvement compared to 2.6 in that regard, but it's still quite a way to go) and thus you /will/ be able to work with them in mode Delphi. So just use that mode and be happy.

Regards,
Sven

"Maciej Izak" wrote

2015-07-23 10:12 GMT+02:00 Michael Van Canneyt : > > I simply don't understand why people want to introduce concepts of other

languages.

> Just use the other language, spare yourself the agony. > > What confuses me even more: C has been around since as long as pascal.

It does not seem plagued by this need to be "modern".

or TP or FPC, full stop. You can't stop me and others from introducing Oxygene flavored mode.Or if inside FPC team is will to block changes related to Oxygene flavored syntax, let me know and I will try to create fork of FPC compiler.

It will depend on the changes. For example your proposed "strong" and "weak" changes would he rather mediate (I'm not talking about the syntax now, but other changes in the compiler and RTL to implement it), so that is more likely to be accepted then let's say inline variable declarations which might lead to quite massive changes in the compiler. [Note: I'm not saying that those /will/ lead to massive changes, I'm just cautioning you that massive changes will be looked at more sceptically than small ones]

Sidenote/warning should you decide to work on the compiler now that you have a branch directory: adhere to the coding style used in the compiler even if you don't like it (I don't either ;) ), because that will definitely be a reason to refuse your code (you wouldn't be the first).

Regards,
Sven

In our previous episode, Michael Van Canneyt said:

? Not at all. I simply don't understand why people want to introduce concepts of other languages. Just use the other language, spare yourself the agony.

Just look at the forum. What is talked there? Languagewise only more Delphi compatibility, unless it is from the people who are actually adding syntax.

Overall? Things like fpspreadsheet get more responsed than any language feature combined.

What confuses me even more: C has been around since as long as pascal. It does not seem plagued by this need to be "modern".

That's because basic syntax is inherited by all other languages. It is so pervasive that most accept it as a given without thinking, and want to change everything to it.

What worries me most is that language debate is again driven by shortness of notation and other very local typing optimizations (like the var block).

Typing was never the limiting factor in programming, and carving up the language for typing's sake will not have a noticable effect on any production use of the (FP-)pascal language.

If, and only if you want to do language extensions, it should be about making new aspects doable, not reducing typing and increasing superficial language syntax.

(moreover can you borrow C syntax without accepting C's everything is an int expression mantra? Can you randomly borrow from C# (and its slightly Wirthianized cousin Oxygene) without changing into a GCed language and a Java/C# typesystem?)

Frederic Da Vitoria wrote

Declare before use has at least one technical advantage: it allows to make much faster compliers. Declare before use allows to compile in one pass, while compilers for languages like C need at least 2 passes.

???

ANSI C is a "Declare before use" language, too.

-Michael

Which fully supports my point that we need more libraries, and not language features.

Michael.

2015-07-23 11:45 GMT+02:00 Michael Schnell :

Ah yes, I was referring to old C syntax. I so much hated it that I never looked back into it since.

In our previous episode, Michael Van Canneyt said:

That, and IF there are language support enhancements, they need to be as minimal as possible and in support of some major library concept. Not just syntax for syntax' sake talked up because of some perceived typing advantages.

In our previous episode, Maciej Izak said:

> technological arguments for your changes. > The most convenient technological argument is compatibility with Oxygene.

If oxygene is what you want, I recommend you start at the basis, and not superficial details.

Maybe there is some overlap with the JVM work you can build on.

But IMHO it is nuts for the native modes.

"Michael Van Canneyt" wrote

I don't believe generics are the nec-plus-ultra of pascal (or any

language). I documented them nonetheless (Sven: Ping ?)

What? Who? Me?! Can't be!
(My free time management is really screwed up since I've joined Tumblr -.- *sigh*)

Regards,
Sven

What is tumblr and how can I shut it down ? :)

Michael.

Marco van de Voort wrote

Typing was never the limiting factor in programming,

Surely you're joking. Do you really claim that there has ever been any excuse for this sort of terseness, except for minimising keyboard work?

A0: R := INSYMBOL;
A1: IF F[S[I]] > G[R] THEN GO TO A2;
  IF R = MARK THEN GO TO A9;
  I := J := I+1; S[I] := R; MOVE(NAME, V[I]); GO TO A0;
A2: IF F[S[J-1]] = G[S[J]] THEN BEGIN J := J-1; GO TO A2 END;
  M := MTB[S[J]];
A3: IF PRTB[M] = 0 THEN BEGIN ERROR(5); GO TO EXIT END;
  N := J;

And that's Wirth's code, by the way.

In our previous episode, Mark Morgan Lloyd said:

> Typing was never the limiting factor in programming, Surely you're joking.

No. Note that I mean notations that are mostly shorthand, not removal of primal language constructs.

Do you really claim that there has ever been any excuse for this sort of terseness, except for minimising keyboard work?

I'm not sure how this illustrates anything relating to shorthand language constructs.

-.-

> *sigh*) What is tumblr and how can I shut it down ? :)

It's a social networking site. A look at Wikipedia will help you further ;)

Regards,
Sven

Michael Van Canneyt wrote

Oxygene is no longer pascal. It's just C# with pascal keywords. a pityful copy. If you want the features of C#, you should use C#, full stop.

Exactly! I was first wondering if this would be a "proper" Pascal implementation to be used on top of .NET, but there is likely a reason why it isn't any longer part of Embarcadero's RAD Studio suite.

+1
That is what a lot of people that never really learned Pascal don't understand. And a lot of folks in "the industry" don't care about properly planned/designed software, just get "something" out fast, and deal with the problems later (aka "constant delivery")

+1
Pascal is much better in properly handling the scope of variables, giving you much better separation of local and global variables that most other programming languages. Just do it properly, without taking a "temporary" shortcut and you can eliminate a lot of potential problems in the future..

It is just a wish of people who think that 'anything goes', it has nothing to do with being more productive or being modern.

+1

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Good luck to you!

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

No, not really. You can happily use variables and have them automatically assumed to be int, just as with any non-ANSI C compiler, just matter of pragma warning to be set.
And you can define procedure/functions just about anywhere, with all the disadvantages of a clear schema as in Pascal (like changing the parameters in the .c file and forgetting to change the .h file).

Ralf

---
This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2015-07-23 11:22 GMT+02:00 Michael Van Canneyt :

To start any work on this I need to provide a few more patches related to Delphi compatibility. I would like to return to the subject in near future.

Nice to hear that. So I guess I don't need any fork ;) phew!

2015-07-23 11:30 GMT+02:00 Sven Barth :

I pointed this out before. For the greater good, we must to sacrifice oneself. ;) I'll start work at the end of August. I need to complete some work on sparta/lazarus branch. There is also wedding on my roadmap.

Congrats, and that should be top priority :)

Michael.

Looks like I sparked quite a bit of interest! Perhaps we could work on a Standard instead of just on the Compiler itself? This gives people more of a look on what 'could' happen, instead of a Wiki where everyone can just edit. A system where voting is necessary, just like Standards from W3C, Khronos, etc, etc. A mailing list where people debate endlessly is not productive; we could have had a # of votes to see what should/should not be implemented, instead of a few key members deeming what's 'pascalish' or not. You may create that fork/branch now, but who knows who will actually end up merging it in? If they ever do. This is why we need a standard, so that there is NO wasted work, and people can get experience implementing things that are well documented first and know how they should act.

*Plan first, Then Code*: I believe was said? ;)

Then let us plan a standard, and what each feature should do, *then code*. I hope there is enough rally for this to happen!

- Dennis Fehr

Den wrote

*Plan first, Then Code*: I believe was said? ;)

Tee or beer / cupboard or fridge :-) :-) :-)

-Michael

Definitely. It will be good to have a working document.

But an open source project is not a democracy; it is a meritocracy. If someone feels like doing one of your standards, it will happen, otherwise not. if you think otherwise, I think you are dreaming :) So a voting system is in my opinion redundant and probably counterproductive.

Michael.

2015-07-24 12:13 GMT+02:00 Den :

Simple/light voting system for that purpose integrated with "proposal documents" is also in my roadmap (something like
https://gcc.gnu.org/projects/cxx1y.html but with users accounts/simple comments/voting system). Anyway I don't have any timeline for that. Maybe I'll do it sooner than any compiler change.

Den wrote

Perhaps we could work on a Standard instead of just on the Compiler itself?

.... the normal RFC process ...

-Michael

In our previous episode, Den said:

Neither is voting by uninformed people. People admitted to W3C and Kronos are a preselected group, not every internet user can vote directly on proposals.

And even so, they mess up.
XML was nice in theory, till namespaces came along. SOAP was nice in theory, till large companies messed with it. OAuth used to be simple, till version 2.0 come along. Just to name a few I came into contact with.
Design by committee is rarely a good plan.

I just keep hoping they will leave JSON and JSON-RPC and JSONSchema alone :(

Michael.

Actually, I recently proposed several changes to CSS, and I'm not a part of their working group. I can even track the status of it.

- Dennis Fehr

Den wrote

Actually, I recently proposed several changes to CSS, and I'm not a part of their working group. I can even track the status of it.

Sure. Everyone can submit, why not ?
Marco said "vote" :)

Michael.

In our previous episode, Den said:

Actually, I recently proposed several changes to CSS, and I'm not a part of their working group. I can even track the status of it.

You don't need to become part of FPC core to post bugs or requests either.

Yes, and why does an email/submission not in itself count as a vote? This isn't a 'threat' to the Free Pascal eco system, I'm trying to help! I hope the 'usuals' aren't thinking that I'm trying to stand up, go against, or similar? A standard can only help Free Pascal. It is up to us to have no bigger company take over the Standard. An Open Standard. I just want to raise Pascal to a level I think it deserves, and think this would be a great way for people to come together and voice their opinions/votes on specific features. I'm not asking for things like inline variables, etc. But I am asking that we stay up to date with coding functionality, and expect a certain result. It's the worst when someone comes up with an idea, adds it in FPC, and turns out people have issues against how it works, or the result wasn't as expected, etc.

- Dennis

Then just go ahead on working on a standard?