[fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?

[Sven Barth]

On 27.02.2013 23:40, ik wrote:
> Hello,
>
> I was going over the wiki and looked at
> http://wiki.freepascal.org/FPC_New_Features_Trunk .
> It looks like some of the features here, actually breaks Pascal, and
> create something like Jascal or something, but it's not Pascal in
> spirit.
> For example 1000.to_string ?! I have it on Ruby and Java, but it's not
> Pascal syntax.
> Same goes for array constructors.
>

The main language dialect used with FPC (though its not the default one) 
is Object Pascal, not Pascal. If you want Pascal, then stop using 
classes immediately! Object Pascal unlike Pascal is not defined anywhere 
as the driving force behind it is Delphi.

I personally don't agree with some syntaxes as well, but I'm mostly all 
for the feature they represent.

For example anonymous functions: ugly as hell, but this concept of 
closures is awesome. When the anonymous methods from Blais' branch will 
be ready for merging I'll extend the so far that we can also pass nested 
functions to them (which isn't allowed in Delphi), so that one can use 
it's power without cluttering the code. Also I'll think about adding a 
less verbose syntax for simple cases (more lambda syntax like, but more 
Pascal like than the variation from Oxygene).

Another example: Attributes. The idea that you can tag attributes to 
classes, their fields and methods is a wonderful one. This way you can 
group additional information (e.g. DB field, HTTP Parameter, etc.) 
together with the element it represents. It also opens the possiblity 
for automatic Dependency Injection which can reduce code coupling (which 
is good except for performance "critical" systems like the compiler) and 
thus also simplyfy testing. Yet I find the syntax absolutely 
un-Pascal-like. Those prefixed attributes are simply copied from C#. My 
plan is currently before Joost's branch with attributes is merged that I 
extend the syntax in mode ObjFPC to be a suffix instead like "virtual" 
and "deprecated" modifiers behind which the attributes in a "[...]" 
block follow.

And for array constructors: I would prefer "somearray := [ element1, 
element2, element3 ];" instead and maybe I'll implement that somewhen in 
the future :)

For the type helpers I've also done something more consequential: in 
Delphi helpers for primitive types are declared as "record helper" while 
in ObjFPC they are declared by "type helper". It's very likely that I'll 
allow the usage of records in "type helper" as well and "deprecate" the 
record helper syntax in ObjFPC (it will be kept of course for backwards 
compatibility to 2.6.x).

> I actually starting to ask the same questions of Graeme, do we really
> want to follow Delphi instead of creating a more Pascal like dialect ?

As others already said: There are components or frameworks out there 
that use modern Delphi features or frameworks of other languages that 
make use of such features. Example: DSpring, which is a Delphi 
dependency injection framework. Another example I'd like to see is 
.NET's Reactive Extensions which allow you to work with asynchronous 
data streams (which requires interface helpers and closures).

Maintaining a language is not only about satisfying users that are happy 
with the current state. Languages evolves and so should do Pascal. While 
we currently do follow Delphi's lead my plan is to also research (not 
necessarily implement in trunk!) language features that aren't found in 
Delphi, but in other languages. Features like type inference, duck 
typing, aspect oriented programming and traits. By implementing them we 
can attract developers which got used to such features and swear that 
they can simplyfy work. Yet I'm also aware about the heritage we have 
and that we must honor it. Which is why I want to implement no language 
features in an as Pascal way as possible and which is also why I was 
opposed to the tuple feature as suggested by Alexander.

Regards,
Sven