[fpc-devel] Proof of Concept ARC implementation

[Boian Mitov]

In general the C/C++ notion of doing as little in the language as possible, 
and as much in library has worked very well for it over the years.
Yes, pluggable languages concept has existed at least since C ;-) . I agree, 
and as I said has worked well.
I think OP can learn a lot from those languages, and prosper from such 
features.
The advantage of doing it this way, is that we can all customize the 
language to our liking, while keeping it all compatible.
It also will allow for blossoming of new programming concepts as developers 
can expand the language themselves without the need to rewrite the compiler. 
Even more so it will make the language very attractive for universities and 
students (so they will not need to use Scheme any more as example ;-) ).
This has the potential of making FPC the premier, and leading language in 
the world of computing, not merely just another language in the crowd ;-) 
IMHO .


With best regards,
Boian Mitov

-------------------------------------------------------
Mitov Software
www.mitov.com
-------------------------------------------------------
-----Original Message----- 
From: Marco van de Voort
Sent: Monday, October 27, 2014 2:23 PM
To: FPC developers' list
Subject: Re: [fpc-devel] Proof of Concept ARC implementation

In our previous episode, Boian Mitov said:
> Well... since attributes can be implemented in compiler extending library,

And tell me again why directives couldn't? A switch or whatever trigger 
could
also plug additional directives into the parser. (and then I'm not even
discussing the actual use of plugging).

As said the only *difference* is to skip and ignore unknown attributes since
they are a defined list. But then one must have the actual luxury of
skipping them and the program still working.

And e.g. in the case refcounts skipping that will leave some pretty big
memory leaks :_)

> I think library extension of the compiler is a better option that having a
> bunch of switch directives.

You made that clear. I just don't understand really why. The extra
interfaces only make the result harder to control. A pluggable program is
much harder to maintain than the same functionality monolithically.

> This also allows users easily to customize the compiler for their needs.

That's the only reason to do so. But that is for third party uses, usually
for one application or framework or platform dependent. Not for core
language features that hit both code generation and library.

> Now I know the concept for compiler being expanded/modified via library is
> probably a new one, but .NET already has introduced elements of this years
> ago, and seems to work well for them ;-) .

.NET afaik mostly uses it to give hints to the fringes of the system, like 
the ASP.NET
containerized instances of the .NET framework for safety and load balancing
etc, and to interop to communicate to the outside of its walled garden.

There was life in languages before .NET, don't worry ;-) Trying to make
pluggable languages is almost as old as the road to Rome.

_______________________________________________
fpc-devel maillist  -  fpc-devel at lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel