Re: Compiler issues... (was Re: New Book: The School of Niklaus Wirth)

        To keep from posting billions of pages, I'm going to combine several
responses into one. For the record, I've used Free Pascal, GNU Pascal, TMT
Pascal, Borland Delphi, CodeWarrior Pascal (briefly), and Borland Pascal.
        I just want to say that what I post here is relevant to all of you
making compilers, and any of you on a standards committee, because there are
some things that just don't make any sense at all. I promise that this is my
final comment on the subject.


==========================
From: "jsvendsen" <jsvendsen@bergen.frisurf.no>
> In 16-Bit Turbo Pascal 7.0 The Unsigned Int Was Called Word.


        That's my point, in _Turbo Pascal_ an unsigned int is defined. But also
in Turbo Pascal, an unsigned long is not defined. And in the Standard Pascal
standard, neither one is defined. I doubt that Extended Pascal defines an
unsigned int or long either.




> (After A Short Trip Into The Freepascal Documentation It Appears That
> 32bit Unsigned Ints Are Called "Cardinal" And 64bit "QWord")


        Cardinal is defined in GNU Pascal, Free Pascal, TMT Pascal, and Borland
Delphi. I don't remember if it's defined in CodeWarrior. The problem is that
while $FFFFFFFF is equal to 4294967295 in GPC, FPK, and TMT, Borland Delphi
reports it as 2147483647. Why? Borland Delphi masks off the 31st bit. My
point here is that an unsigned int, or unsigned long is left to the compiler
maker, rather than being defined as part of the standard like C and C++.




==========================
"Jean Pariseau" <jparis11@home.com> wrote in message
news:00-11-062@comp.compilers...
> facility. Let's say that I create a class to read disc files
> ...
> on varying types of data, and the best part is,


        Your example does not show the need for multiple constructors, you can
accomplish the same thing with just one constructor, and an overloaded
function. Pascal does not allow overloading a function (especially
constructors) with the same name, unless you're using a Borland Delphi
compatible compiler.




==========================
From: "jt" <gkt37@dial.pipex.com>
> I have to disagree. Pascal more clearly distinguishes between
> ...
> without getting confused.


        That's not true, Pascal changes the way you think. IMO Pascal represents
logic while C represents freedom. I know from experience, and I know people
who would agree with me. I know of someone who learned BASIC that said it
made C hard to understand. You can't take what you learn in Pascal and apply
it to C without having more difficulty than if you simply jumped straight
into C. I suppose the learning curve depends on the way you think, but my
opinion here stands.




> Prime example: an array is NOT a pointer, nor a contiguous range of
> ...
> "hello world" + '!'
> ...
> different purposes.


        I have not thought of the above and I agree with you on this point.




> (NB I take your 'OO Pascal' to mean Delphi pascal)


        Correct, but I also mean Delphi pascal compatible compilers.




> // terrible, but for illustration
> ...
> How else would you cleanly do this?


        You can do it by setting an integer to represent a type code. This way
the programmer checks the variable and determines which variable holds a
valid value. In the case of using a function, the class knows its own data
and can return the appropriate variable, or can return a value that is known
to be invalid but can be used safely. Such as "" for the string, or 0 for
the integer. Another thing that can be done is to allow the programmer to
specify a default value (which is what I do). You don't need multiple
constructors in this case.




> More difficult. Doesn't C++ require a placement delete corresponding to
> each placement new?


        Yes, C++ does require a delete for every new. My point is that in C++
you can instantiate a class by declaring a variable (not a pointer to the
class, but an actual class), and you can call any of its members counting on
the fact that they're present and ready to use because the constructor was
called automatically. In Pascal your program will crash, raise an exception,
or cause a run-time error if you use a virtual function without first
calling the constructor. In other words, C++ automatically sets up the
class, but you have to do it yourself in Pascal. Not only that, but if you
have to manually run the constructor, it's one more line of code that the
programmer has to know about.




> More than likely there is. Look around first. Off the top of my head
> there, javascript, TCL, curl, python, perl, rexx, awk & sed. There's
> surely something right for you in existence. Hope you find it.


        I have looked around, but none of them suits my needs. Whether it be
because of memory usage, API complexity, or the language itself, I have yet
to find a script language that I personally like. JavaScript is limited in
what it can do, although it is good for algorithms (I just wish it had a
unary not operator, but xor -1 followed by ++ works the same). TCL is too
bulky. I have not tried Curl, but if it's the web site building/etc script
language it's far from what I need. Python eats up a lot of memory and it's
DLL based. Perl is too bulky. I've not tried Rexx but I've glanced at its
syntax and didn't like what I saw. I don't like Awk's and Sed's syntax.
        I'm creating a script language which has the ability to allow several
instances in memory without hogging up all the computer's memory. One in
which most table and list sizes are not hard coded (the only ones so far
whose sizes are hard coded are the VM opcode function pointer table, and the
scanner character code table). It also has to parse and run with an
extremely limited amount of memory. I made some rough calculations, while
preliminary my language will be able to compile a script with as little as
16k of RAM, and the compiled script will take up much less than that. The
compiled script will be able to run with as little as about 2k of RAM in
addition to the size of the compiled script itself. I have specs drafted
that I will e-mail to those who are interested (e-mail me if you're
interested), I can assure you that I will get about 95% of those features
implemented if not all of them...


See ya!
Orlando

Return to the comp.compilers page.
Search the comp.compilers archives again.