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

[Daniël Mantione]

Op Thu, 2 Jun 2005, schreef Jamie McCracken:

> Daniël Mantione wrote:
> >
> > Op Thu, 2 Jun 2005, schreef Jamie McCracken:
> >
> >
> >>Daniël Mantione wrote:
>
> >
> >
> > Ok! We'll be happy to assist anyone doing interresting developments with
> > Free Pascal. Keep in mind though that implementing ideas can take "a lot"
> > more time that thinking out ideas.
> >
> > The Free Pascal parser is indeed manual craftmanship. Some experimenting
> > was done using yacc in the past but a handwritten parser turned out to be
> > the best choice. The parser units start with the letter p, for example
> > pexpr.pas is the expression parser.
>
> You've done it the hard way - no wonder developer's are reluctant to
> implement syntax changes!

Depends on your definition of "hard way". The parser is fast and
flexible. Ask Carl Eric Codere what the exact problems with Yacc were. But
it's "been there, done that, didn't work".

> > Yes... Because Java often turns out to be the wrong tool and its memory
> > management is one of the reasons. We need to be carefull to prevent Pascal
> > becoming a wrong tool. However, automated memory management does have some
> > advantages. Nobody can deny that.
>
> Ref counting does not use more memory! (well okay 32 bits extra to store
> the ref count for each object).

Yes, but it has its own problems. Think of an object having a reference to
itself (think of a ringbuffer with 1 object in the ring or so). Welcome in
the real world.

Perhaps (likely) there is a solution, perhaps (likely) there are more
problems. No expert here.

> would become under Rad Pascal:
>
> uses
>    Classes, SysUtils;
>
>   TMyObject = class (Tobject)
>      private
>          count : integer;
>      public
>          constructor create; override;
> 	    inherited Create(AnOwner);
> 	    inc (count);
>
>          destructor destroy; override;
> 	    inherited Destroy;
>
>
> Notice its at least 50% less code to write.

Yes. Too bad it is not possible. One of the problems you can expect is
with cyclic units. Normally the interfaces of the units form a tree, which
define how they get called. So the compiler can compile the interfaces in
the depth first order, then it can do the implementations in any order it
wants, cyclic uses in implementations are no longer a problem, as the
compiler known how to call the procedures in those units.

From the good taste department, it breaks the interface/implementation
principle. The unit principle guarantees that libraries are being written
so that one only needs to look at the interface, not the implementation to
know how a library works. It saves a few keystrokes, but makes it a lot
harder for the user of the library to understand it.

Daniël