Some new features_(re)

Wed, 2 Jul 1997 09:34:21 +0200

Peter Gerwinski wrote:

> > - Commandline options to specify the directory(ies)
> >   a) to search for units/modules (source or compiled)
>
> My current plan is to use the `-L' path/s for this purpose.

Yes, why not! (What I'd like best is if it (with "--automake") would look for
a source file in the current directory and the "-L" path, and for a compiled
module in the "-L" path and the b) path (see below), and if it finds both,
compare the dates, regardless where it found them. I think that's how BP does
it -- or even a little bit better... :-)

> >   b) to put compiled modules (.o, .gpi, .gpm)
> >   c) to put compiled programs (executables).
>
> \begin{sigh}
>   Even more options!
> \end{sigh}

But those are more useful than average, I think... ;-)

I, personally, can't stand other files put between my sources, and for
executables, there usually exists a separate directory, anyway...

> What about extending (*$executable-file-name="foo"*) to accept
> a directory?  Or else (*$executable-path-name="/foo"*) and
> (*$object-path-name="/bar"*)?

I don't agree. The *name* of the executable can be considered part of the
program. The *path* where it will be stored will be system dependent, so the
path, IMHO, does not belong into the source, but on the commandline (or into
a (system or user or project specific) config file, of course).

> > - Passing the actual size for untyped (resp. void) parameters, so it can
> >   be access with sizeof.
>
> This would spoil compatibility to other languages such as C.

What about:

var x:void  -> like C
var/const x -> like BP

> So perhaps make "Procedure Foo ( Var x )" pass the size, and keep
> "Procedure Foo ( Var x: Void )" as it is (i.e. without passing the size)?

I was typing too soon before reading this... :-)

> Or introduce another data type?

Only if necessary. (But I don't see why it would be, since there are already
two types and two purposes -- if existing programs with "var x" do rely on C
compatibility, those (few, probably) programs should be changed rather than
the compiler...)

> Okay; I have put it on my list.

Fine! :-)

And another one:

For procedural variables, BP uses "@ProcVar" to cast them into a pointer(!!!).
gpc does not understand this, but the (more logical, IMHO) "Pointer(ProcVar)".
Unfortunately, BP doesn't accept the latter, so AFAICS there's yet no way that
works on both. :-( Since we can't change BP, we should make gpc recognize
"@ProcVar", perhaps also only in "--borland-pascal".
-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
http://www.mi.uni-erlangen.de/~heckenb/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)