Does FPC 2.8.0 can actually still be called Pascal ?

classic Classic list List threaded Threaded
63 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Does FPC 2.8.0 can actually still be called Pascal ?

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

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 ?

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

Re: Does FPC 2.8.0 can actually still be called Pascal ?

Graeme Geldenhuys-3
On 2013-02-27 22:40, ik wrote:
> For example 1000.to_string ?! I have it on Ruby and Java, but it's not
> Pascal syntax.
> Same goes for array constructors.


Both of those are just hideous to me. Very un-Pascal like. :-(


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

And to make matters worse... FPC isn't very Delphi [2009 and later]
compatible anyway. It copies some features but not all. Then the some it
does copy might not be fully functional yet, or has a different syntax.
I tried multiple times to make a Delphi 2009+ project of mine work with
FPC 2.7.1, and I just can't succeed. I fix or work around one issue,
just to be blocked by another.

I still believe FPC should leave the "delphi compatible" idea, or
clearly state that it means "compatible with Delphi 7 for legacy
purposes" and nothing newer. Then innovate the rest of the language on
its own in a Pascal-like manner.

FPC now definitely finds itself in the Jascal.NET territory. ;-)


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

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

Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?

Simon Kissel
> I still believe FPC should leave the "delphi compatible" idea, or
> clearly state that it means "compatible with Delphi 7 for legacy
> purposes" and nothing newer. Then innovate the rest of the language on
> its own in a Pascal-like manner.

This is a terrible idea. The business advantage of Object Pascal
has always been the component market, as it reduces development
costs and time to market. Language compatibility between FPC and
Delphi results in more components being available on both sides.

The Object Pascal language is too fragmented already, and depending
on your choice of the Delphi/FPC/Oxygene/whatever flavour, you are
locked out of a hell lot of available source code, documentation,
knowledge and components. Right now pretty much every commercial
component we have to patch inhouse to be compatibile to FPC.

(On a side note: It's one of the goals of CrossFPC to make it
easier for Delphi users and component vendors to also use/support
the FPC compiler.)

Sticking to D7 compatibility has been OK for now as this is what
the masses and component vendors mostly are doing, too, as they
still have to support D7 users.

We ourselves have to stick with D7 language level because we still
need CrossKylix for our Linux builds because the FPC compiled code
is prohibitively slower than Kylix' one.

FPCs goal to move towards D2009+ language compatibility is a right
goal - but of course that does not mean that everything needs to be
copied, but when things on the Delphi side are designed in an OK
manner, are actively used in the field, and FPC wished to do the same,
aiming for compatibility is a good thing. Should FPCs share of the
object Pascal ecosystem one day should be *significantly* larger than
Delphi's, sooner or later Delphi then will try to pick up FPC's
innovations instead.

In the long run, new object pascal language features optimally
should be discussed by those active in the field BEFORE they get
implemented. Sadly right now Embarcadero still are far too arrogant
and close-minded to understand that FPC actually benefits the
ecosystem they sell products in.

All this being said: I know that FPC is not after business goals.
But not damaging the ecosystem FPC works in helps everyone using
Object Pascal, no matter if they are after commercial goals or not.

Cheers,

Simon

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

Re: Does FPC 2.8.0 can actually still be called Pascal ?

Andrew Brunner-2
In reply to this post by Graeme Geldenhuys-3
On 02/27/2013 05:50 PM, Graeme Geldenhuys wrote:
> FPC now definitely finds itself in the Jascal.NET territory. ;-)
> Regards, - Graeme -

That's probably needed here.  I think it's a great idea to embrace a new
name for some future version that includes innovations.  Pascal has been
forced into a bracket it ought-not-be.

Jascal DOES look cool ;-)

--
Andrew Brunner

Aurawin LLC
15843 Garrison Circle
Austin, TX 78717

https://aurawin.com

Aurawin is a great new way to store, share, and explore all your content
featuring our innovative cloud social computing platform.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?

Graeme Geldenhuys-3
In reply to this post by Simon Kissel
On 2013-02-28 00:16, Simon Kissel wrote:
>
> This is a terrible idea. The business advantage of Object Pascal
> has always been the component market, as it reduces development


Component vendors simply aren't interested in FPC, and those that are,
are bought about by EMBT and made Delphi only.


> We ourselves have to stick with D7 language level because we still
> need CrossKylix for our Linux builds because the FPC compiled code
> is prohibitively slower than Kylix' one.

I stumbled across this last week too. On the same OS, I compiled the
exact same unit testing test suite using FPC 2.6.0 and Delphi 7. Running
those tests, again on the same system, the Delphi executable completes
the 180 tests in 2 seconds. The FPC binary took 18 seconds for the same
180 tests!!!


> FPCs goal to move towards D2009+ language compatibility is a right
> goal - but of course that does not mean that everything needs to be
> copied, but when things on the Delphi side are designed in an OK

If you want to say "delphi compatible", it must be all or nothing. EMBT
is butchering the Delphi name to hell and gone. I don't think FPC should
follow just because.

A few issues aside, I honestly believe FPC is a much better product than
Delphi. FPC should build on its strengths - it doesn't need Delphi.

eg: In a recent discussion in the Google+ Delphi Community, they asked
what new language features would Delphi developers like. After about
15-20 replies I had to post a message saying that FPC actually supports
most of the things they had on their wishlist.

As I said, FPC doesn't need Delphi. Innovate on your own and don't
follow Delphi into the grave. Plus, stay true to the Pascal language as
much as possible.


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

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

Re: Does FPC 2.8.0 can actually still be called Pascal ?

Graeme Geldenhuys-3
In reply to this post by Andrew Brunner-2
On 2013-02-28 00:18, Andrew Brunner wrote:
>
> Jascal DOES look cool ;-)

That will probably rid us from some of the Pascal Language stereotyping. :)

RemObjects (with their Oxygene language) tagline says it best:

  "This is not your daddy's pascal"


I love that tagline.


Regards,
  - Graeme -

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

Re: Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?

Craig Peterson-4
In reply to this post by Graeme Geldenhuys-3
On 2/27/2013 6:41 PM, Graeme Geldenhuys wrote:
> Component vendors simply aren't interested in FPC, and those that are,
> are bought about by EMBT and made Delphi only.

Eldos added support for Free Pascal to SecureBlackBox within the last
couple of years.  Indy supports it in their main repository.  I added
FPC support to Abbrevia in late 2011.

I know we're not the only commercial software vendor to give up on
Delphi for cross platform work, and Free Pascal's Delphi compatibility
is the only thing that has made that possible.

> If you want to say "delphi compatible", it must be all or nothing.

Why?  It should be driven by user needs and developer interest, just
like it always has.  I'd like to see anonymous methods because it would
make porting the OmniThreadLibrary possible.  The fact that they aren't
supported doesn't make the existing generics and class helper support
unusable.

--
Craig Peterson
Scooter Software

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

Re: Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?

Simon Kissel
In reply to this post by Graeme Geldenhuys-3
>> This is a terrible idea. The business advantage of Object Pascal
>> has always been the component market, as it reduces development
>
> Component vendors simply aren't interested in FPC, and those that are,
> are bought about by EMBT and made Delphi only.

Component vendors are interested in selling components.

The honest loyality of component vendors to
Borland/CodeGear/DevCo/Embarcadero is next to non-existant. The reason
Delphi is the focus
is that they invested into that, and that Embarcadero is using
anti-competitive tactics.

I've been a Borland Technology Partner. Besides my personal experience,
I sure know how component vendors are treated.

Supporting FPC just has be to be attractive enough so that the
component vendors are willing to take the risk of not getting
any more "love" from Embarcadero.

Removing technical obstacles therefore helps. Language compatibility
is something that helps a lot.

>> We ourselves have to stick with D7 language level because we still
>> need CrossKylix for our Linux builds because the FPC compiled code
>> is prohibitively slower than Kylix' one.
>
> I stumbled across this last week too. On the same OS, I compiled the
> exact same unit testing test suite using FPC 2.6.0 and Delphi 7. Running
> those tests, again on the same system, the Delphi executable completes
> the 180 tests in 2 seconds. The FPC binary took 18 seconds for the same
> 180 tests!!!

 From our measures the Delphi and Kylix compilers in most cases
on x86 produces code that is about in the order of 50% faster than FPC.
So probably there is some issue specific to your test suite that is
triggering this huge difference, it should not be that big. For some
applications (like ours), still the difference is too big, so we only
use FPC on platforms where there is no compiler from Embarcadero, and
keep all of our source code compatible to Delphi 7 + Kylix + FPC.
Language compatibility enables us to have a choice. Without this choice,
we would have needed to move to a different programming language.
Choice is good, competition is good, compatibility amongst competitors
is good.

Cheers,

Simon



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

Re: Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?

Michael Van Canneyt


On Thu, 28 Feb 2013, Simon Kissel wrote:

>> exact same unit testing test suite using FPC 2.6.0 and Delphi 7. Running
>> those tests, again on the same system, the Delphi executable completes
>> the 180 tests in 2 seconds. The FPC binary took 18 seconds for the same
>> 180 tests!!!
>
> From our measures the Delphi and Kylix compilers in most cases
> on x86 produces code that is about in the order of 50% faster than FPC.

You mentioned that you would like to contribute to FPC.
Maybe this is an area where you can contribute: more aggressive optimizations.

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

Re: Does FPC 2.8.0 can actually still be called Pascal ?

Mark Morgan Lloyd-5
In reply to this post by ik-6
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.
>
> 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 long as it has the dangling-else flaw, it's Pascal.

--
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/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Does FPC 2.8.0 can actually still be called Pascal ?

Marco van de Voort
In reply to this post by ik-6
In our previous episode, ik said:
> 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.

We already have had this discussion for VB (D4/COM extensions), .NET etc.

Yes Delphi will copy everything what is popular in a desperate attempt
to increase its appeal.

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

FPC is not clean either. Constructs like case string of remind of basic and
the proposed tuple support is not exactly hardcore imperative languges (let
alone Pascal) either.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Does FPC 2.8.0 can actually still be called Pascal ?

Marco van de Voort
In reply to this post by Graeme Geldenhuys-3
In our previous episode, Graeme Geldenhuys said:
> That will probably rid us from some of the Pascal Language stereotyping. :)
>
> RemObjects (with their Oxygene language) tagline says it best:
>
>   "This is not your daddy's pascal"
>
>
> I love that tagline.

So "Sulphur" then? It is the next element in the same group of the periodic
table and twice as heavy as Oxygen? Moreover hints at being a bit evil and
vile.

The idea behind hinting on that last bit is if we simply admit we are dirty, we won't
have any useless cleanness discussions anymore?

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

Re: Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?

Marc Pertron-4
In reply to this post by Simon Kissel
2013/2/28 Simon Kissel <[hidden email]>:
> In the long run, new object pascal language features optimally
> should be discussed by those active in the field BEFORE they get
> implemented. Sadly right now Embarcadero still are far too arrogant
> and close-minded to understand that FPC actually benefits the
> ecosystem they sell products in.

So let's call the Delphi-compatible version "Rascal" ? ;)

> All this being said: I know that FPC is not after business goals.
> But not damaging the ecosystem FPC works in helps everyone using
> Object Pascal, no matter if they are after commercial goals or not.

I agree. We need better optimisations at least as much as fancy 123.tostring.
Is there other companies here interested in Linux 64 bits target optimisations ?
--
Marc Pertron
CTO at Mailjet.com
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Does FPC 2.8.0 can actually still be called Pascal ?

ik-6
In reply to this post by Marco van de Voort
On Thu, Feb 28, 2013 at 11:21 AM, Marco van de Voort <[hidden email]> wrote:

> In our previous episode, ik said:
>> 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.
>
> We already have had this discussion for VB (D4/COM extensions), .NET etc.
>
> Yes Delphi will copy everything what is popular in a desperate attempt
> to increase its appeal.
>
>> 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 ?
>>
>
> FPC is not clean either. Constructs like case string of remind of basic and
> the proposed tuple support is not exactly hardcore imperative languges (let
> alone Pascal) either.

But the syntax is Pascal-ish, case did not changed, only expanded, and
it actually have a good use.
I don't know the tuple part well, so I can't comment on it.

The for in with FPC is nice, and it's a syntactic sugar, but still it
did not break Pascal syntax.
The ability to have mixin for "primitive" types, or arrays is
something completely different here.

to_string is syntactic sugar to val or IntToStr, but it's not Pascal,
it's Object based syntax, something we do not have in Pascal at the
moment.
And if you do want to have it, then first start to make everything
like it, and then add the mixin, or it's actually make the code less
readable, and much harder to maintain, unlike the other "unclean"
features, such as case for strings.

Ido

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

Re: Does FPC 2.8.0 can actually still be called Pascal ?

Sven Barth-2
In reply to this post by ik-6
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
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Does FPC 2.8.0 can actually still be called Pascal ?

Michael Fuchs-5
Am 28.02.2013 10:56, schrieb Sven Barth:
> [...] 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.

But there should be a line that nobody will cross.
Otherwise someday someone try to attract PHP developers with removing
the type safety from Free Pascal. *shudder*

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

Re: Does FPC 2.8.0 can actually still be called Pascal ?

Sven Barth-2
On 28.02.2013 11:18, Michael Fuchs wrote:
> Am 28.02.2013 10:56, schrieb Sven Barth:
>> [...] 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.
>
> But there should be a line that nobody will cross.
> Otherwise someday someone try to attract PHP developers with removing
> the type safety from Free Pascal. *shudder*

I can guarantee you that *I* won't be the one who will cross that line ;)
Type safety is one of the main features of Pascal based languages and
without that it would definitely not be Pascal any longer ^^

Regards,
Sven

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

Re: Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?

Graeme Geldenhuys-3
In reply to this post by Marc Pertron-4
On 2013-02-28 09:28, Marc Pertron wrote:
>
> We need better optimisations at least as much as fancy 123.tostring.


Bottom line.... optimisation work is just not as sexy and exciting as
adding the latest Delphi/Java/C#/C language features. I guess we can't
blame them for that.


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

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

Re: Does FPC 2.8.0 can actually still be called Pascal ?

Graeme Geldenhuys-3
In reply to this post by ik-6
On 2013-02-28 09:31, ik wrote:
> But the syntax is Pascal-ish, case did not changed, only expanded, and
> it actually have a good use.

+1



Regards,
  - Graeme -

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

Re: Does FPC 2.8.0 can actually still be called Pascal ?

Graeme Geldenhuys-3
In reply to this post by Sven Barth-2
On 2013-02-28 09:56, Sven Barth wrote:
>  Which is why I want to implement no language
> features in an as Pascal way as possible


I very much appreciate your efforts, and do like the fact that you try
and keep new language features more pascal-like. Kudos for that.


Regards,
  - Graeme -

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