[fpc-devel] Re: [fpc-l] type discussion

[Jamie McCracken]

Daniël Mantione wrote:

> 
> Granting all those wishes would turn the language in an enourmous
> monster. That doesn't look like a good idea. We've also a limit amount of
> developers whos time needs to be spent well, or we'll get behind.
> 
> So, we're very convervative. Good ideas though, that will really benefit
> people, will be read with great interrest.
> 


okay but my idea was to have a new dialect (i'll call it RAD-Pascal) as 
FPC supports multiple dialects it can slip in without affecting existing 
code so if people dont like it they dont have to use it. Im quite happy 
to write it myself but I will need help on where to look and what to 
modify in the compiler as im not familliar with the compiler source (I 
cant even find the grammar for the language so I take it you dont use a 
table driven or auto generated parser like yacc)

> 
>>Forward declarations are redundant - they exist purely for the benefit
>>of the compiler.
> 
> 
> Here I disagree. I like that I only need to look upward to search a
> procedure. Even when I program C I order the procedures like I to in
> Pascal, since it'll save time in the long term.

I understand that but its enforced for the convienience of the compiler. 
A developer should have a choice for how he arranges things especially 
if hes in a hurry to develop something quick. Such constraints reduce 
the RAD factor.


> 
> 
>>Begin..End is redundant - you have to indent them to make em readable
>>anyways.
> 
> 
> Here I agree, however, Pascal was designed this way. If I would design the
> language I would have likely chosen something shorter. On the other hand,
> I only need to type alt+B and I have a begin/end combo. Even without it,
> the begin/end doesn't irritate me.
> 
> 
>>manual memory management of tobjects is redundant as you can get good
>>performance with ref counting tobjects.
> 
> 
> I agree that automatic memory management eases the programming job.
> However, Pascal is a manual memory management language. That has
> advantages, software written in Pascal is fast, perceived fast by people,
> and uses very little memory.

same is true for Delphi but it uses ref counting and parent/child owner 
for managing memory for most things. However they forgot to do something 
about tobjects - its just inconsistent to manage some things and not others.

With C++ exception handling the try..finally construct has negligible 
overhead so simple ref counting is fast. In the majority use case where 
objects are kept local the overhead will be negligible too. I really 
doubt you will see any significant performance hit this way and memory 
use is of course hardly affected at all by ref counting (unlike GCs). I 
do hope the FPC developers will look at this once we have C++ exceptions 
  and see just exactly what is the overhead and if its worth ref 
counting some more stuff.

> 
> Users like software written in Pascal. They dislike software requiring
> JDK's and .NET runtimes.
> 
> So, lets turn the disadvantage in an advantage. Pascal is no replacement
> for Java and C#. It is a replacement for C and C++.

It is a replacement for java and c# for *desktop* apps. I have rewritten 
several java apps into delphi in my previous jobs.

> 
> Now, the majority of software is written in C and C++. Isn't that a great
> potential "market"?
> 
> 
>>All in all the changes would mean you spend more of your time
>>implementing your application rather than typing loads of redundant
>>code. Maintenance is easier as their is less redundancy.
> 
> 
> As has already been said, typing is not the problem, maintenance is.
> Pascal does a good job here, saving people a lot of time.

except were the source is bloated by forward declarations :)

None of my proposed changes should be detrimental to pascal's 
maintainability or clarity as I too value that feature.

jamie.