[fpc-pascal] Does FPC 2.8.0 can actually still be called Pascal ?
pascaldragon at googlemail.com
Thu Feb 28 10:56:42 CET 2013
On 27.02.2013 23:40, ik wrote:
> 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
> 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 "[...]"
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.
More information about the fpc-pascal