Re: fpc-pascal Digest, Vol 9, Issue 39

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: fpc-pascal Digest, Vol 9, Issue 39

Angelo Bertolli

> Let's now briefly touch the statement that 'Pascal is a
> well-established language'...
>
> The Pascal I used first did not know a thing about objects,
> dynamic arrays; operator overloading, nor did it know how to
> treat strings, among a number of other things..
>
Sure, but we have to accept that no matter how well-established it was
before Borland, it was the Borland compilers which usurped the throne
for the sake of a "universal" standard.

> And, on the topic of 'adherance to certain rules and philosophies'..
>
> Luckily, people then were not so adamanat about --so called---
> Wirthian nature of Pascal... including Wirth himself; just look
> at the things Wirth altered in Modula/Oberon series.
>
> So... Not only the 'strict adherance to certain rules' thing
> is not cast in stone, but also --it seems-- can change from
> one version of the same compiler to the other...
>
> Finally, about 'Pascal is the philosophy, not the syntax'..
>
> As far as I gather, the only philosophy behind Pascal was
> to remove ambiguity in written code. And, that's it.
>
> If there is no ambiguity, why worry about whether it
> conforms to some mystical/celestial strictness..
>
Ok, I'll be more specific for those of you who don't see the value in
keeping a type declaration as one unit.  I think it greatly reduces
readability to not enforce this type rule.  This type rule allows
programmers to expect certain things when reading someone elses or their
own programs.  Don't get me wrong--I won't be too broken hearted if this
is changed in an appropriate way, but I'd rather not see code like this:

type

var

procedure

type

And especially if var or procedure uses something defined in the second
type--that breaks top-down design which I think IS an essential
philosophy of Pascal.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Re: fpc-pascal Digest, Vol 9, Issue 39

Adem
>> If there is no ambiguity, why worry about whether it
>> conforms to some mystical/celestial strictness..
>>
> Ok, I'll be more specific for those of you who don't see the value in
> keeping a type declaration as one unit.  I think it greatly reduces
> readability to not enforce this type rule.  This type rule allows
> programmers to expect certain things when reading someone elses or their
> own programs.  

Heck, I am still trying to come to terms with operator overloading;
let's talk about Pascal purism and operator overloading, all in
the same breath in FPC :-)

> Don't get me wrong--I won't be too broken hearted if this
> is changed in an appropriate way, but I'd rather not see code
 > like this:

>
> type
>
> var
>
> procedure
>
> type
>
> And especially if var or procedure uses something defined in the second
> type--that breaks top-down design which I think IS an essential
> philosophy of Pascal.

I am not out to demand that people write code like above either. It's
in everyone's interest to write as clearly as possible.

Yet, there must (or, should) be the flexibility to do it when the
need arises; after all, it is not adding (or, as long as it does
not add) ambiguity.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal