Board index » delphi » Pascal evaluation order: how does Borland do it and what says the standard

Pascal evaluation order: how does Borland do it and what says the standard

In article <39f46032.2972...@mamenchi.zrz.tu-berlin.de>,

Quote
W.Riedel <Rie...@ptb.de> wrote:

>It's not so easy:
>I often use functions like that :

> Function SetAt( i : integer ) : Str1;    { TYPE Str1 = String[1]; }
> Begin
>   Write;                   { == "flush" }
>   TextAttr := i;        { some own range checking for i omitted }
>   SetAt := '';           { =: empty String }
> End;{SetAt}

>in statements like

>Write(  SetAt(1),  ' TextAttribute is 1 ',  
>           SetAt(2), ' TextAttribute is 2 ' );

I advice you to stop immediately.  That is simply plain ugly. Instead
write for example a parser to which you can pass for example

WriteAttr('{A=1}R Textattribute is 1 {A=2} TextAttribute is 2 ');

Quote
>to change the textcolor  within one Write-Stmt.
>The order of execution follows the order of
>SetAt's in Write(..);
>It works as long you have the {empty} Write;  
>statement in the function.
>The function  is not required to be an empty string.
>If you write
>  SetAt := 'Something';
>instead of
>  SetAt := '';
>"Something" will be written also.
>{Function's Type has to be a longer
>string then}.
>This works in TP3, TP5.5 and later, but
>not in _one_ of TP4 or TP5.

A good reason why not to use such undocumented features.

Osmo

 

Re:Pascal evaluation order: how does Borland do it and what says the standard


Hi,

Quote
gdem...@my-deja.com wrote:
>> Actually, IIRC the point that what we now know as Borland dialects
>> started to deviate from ISO pascal is with UCLA pascal, on which the
>> original dialect of Borland was based.

> Don't you mean UCSD Pascal rather ?

It was San Diego, not Los Angeles.

Quote
> Anyway Borland didn't follow
> any standard since there were maybe no real standard before 1990
> (7185 ISO standard).

Pascal was standardized by ANSI in 1981, by ISO in 1983. 1990 is the
date of the latest revision of ISO 7185. Borland had reasons not to
restrict Turbo Pascal to the standard, some good and some bad.

 - Sebastian

Re:Pascal evaluation order: how does Borland do it and what says the standard


On 23 Oct 2000 19:22:38 GMT, ronka...@cc.helsinki.fi (Osmo Ronkanen)
wrote:

Quote
>In article <39f46032.2972...@mamenchi.zrz.tu-berlin.de>,
>W.Riedel <Rie...@ptb.de> wrote:
[...]
>I advice you to stop immediately.  That is simply plain ugly. Instead
>write for example a parser to which you can pass for example

>WriteAttr('{A=1}R Textattribute is 1 {A=2} TextAttribute is 2 ');
[...]
>>This works in TP3, TP5.5 and later, but
>>not in _one_ of TP4 or TP5.

>A good reason why not to use such undocumented features.

Dear Osmo,
you are totally right to insist in standards. I wrote parsers
for e.g.  highlighting initial letters in single-stroke dialogue
legends. And I never _recommend_  using that technique
above. It is dirty indeed.
But I write mostly real-time programs with very fast timing.
(On an old 386-20MHz, the interrupt jitter was less than
2 microseconds). For debugging this kind of software
I have normally a fast scrolling text screen running
_one_  line numerical output from selected
real-time variables (e.g. interrupt count).
Most var's change seldom, so all 25 lines have
the same value in this columns.  Only such numbers
are readable at normal scrolling speed.  
To highlight changes, I use changing colors. e.g.
depending of polarity or thresholds of real-time values.
Even that could be made with a parser, but easier with
functions containing write statements.
Why easier ?
Only the write statement can have variable number and
variable types of params:
Write( 5 );   Write( 5.0:0:0 );  Write( '5' );            and
i := 5; Write( i );         Strg := '5'; Write( Strg );
Chr := '5'; Write( Chr );
all give the same output.
Parsing would require lots of
Str();      Concatenate();   {or}  Str1+Str2 ...
to generate a string to be parsed then.

Wolfgang

Re:Pascal evaluation order: how does Borland do it and what says the standard


"W.Riedel" <Rie...@ptb.de> schrieb im Newsbeitrag
news:39f59f6d.8855174@Mamenchi.ZRZ.TU-Berlin.De...

Quote
> On 23 Oct 2000 19:22:38 GMT, ronka...@cc.helsinki.fi (Osmo Ronkanen)
> wrote:

> >In article <39f46032.2972...@mamenchi.zrz.tu-berlin.de>,
> >W.Riedel <Rie...@ptb.de> wrote:
> [...]
> >I advice you to stop immediately.  That is simply plain ugly. Instead
> >write for example a parser to which you can pass for example

> >WriteAttr('{A=1}R Textattribute is 1 {A=2} TextAttribute is 2 ');
> [...]
> >>This works in TP3, TP5.5 and later, but
> >>not in _one_ of TP4 or TP5.

> >A good reason why not to use such undocumented features.

> Dear Osmo,
> you are totally right to insist in standards. I wrote parsers
> for e.g.  highlighting initial letters in single-stroke dialogue
> legends. And I never _recommend_  using that technique
> above. It is dirty indeed.
> But I write mostly real-time programs with very fast timing.
> (On an old 386-20MHz, the interrupt jitter was less than
> 2 microseconds). For debugging this kind of software
> I have normally a fast scrolling text screen running
> _one_  line numerical output from selected
> real-time variables (e.g. interrupt count).
> Most var's change seldom, so all 25 lines have
> the same value in this columns.  Only such numbers
> are readable at normal scrolling speed.
> To highlight changes, I use changing colors. e.g.
> depending of polarity or thresholds of real-time values.
> Even that could be made with a parser, but easier with
> functions containing write statements.
> Why easier ?
> Only the write statement can have variable number and
> variable types of params:
> Write( 5 );   Write( 5.0:0:0 );  Write( '5' );            and
> i := 5; Write( i );         Strg := '5'; Write( Strg );
> Chr := '5'; Write( Chr );
> all give the same output.
> Parsing would require lots of
> Str();      Concatenate();   {or}  Str1+Str2 ...
> to generate a string to be parsed then.

> Wolfgang

But why dont you just use ANSI.SYS and write functions that output ANSI
Escape sequences (->DOS 5.0 manual or DOS 6.2 online-help) instead of using
such compiler-dependent tricks? What you have done could be done easier
using ANSI.SYS, and more reliably. But then you have to set Crt.DirectVideo
to false, but I think you know.

--
Rudolf Polzer
REBOUNCE - http://www.mycgiserver.com/~rebounce
I wish I was what I was when I wished I was what I am now.

Re:Pascal evaluation order: how does Borland do it and what says the standard


In article <8t4a30$ed...@riker.addcom.de>,

Quote
Rudolf Polzer <rpol...@web.de> wrote:

>But why dont you just use ANSI.SYS and write functions that output ANSI
>Escape sequences (->DOS 5.0 manual or DOS 6.2 online-help) instead of using
>such compiler-dependent tricks? What you have done could be done easier
>using ANSI.SYS, and more reliably. But then you have to set Crt.DirectVideo
>to false, but I think you know.

Why don't you learn the basics of programming PC screen. First the
issue was speed. In that case DOS calls are NOT the way to go. Second
Crt.Directvideo just affects whether the program uses BIOS calls or
direct writes. Neither setting allow the use of ANSI codes.

The simplest way to allow ANSI codes is not to use CRT at all.

Osmo

Re:Pascal evaluation order: how does Borland do it and what says the standard


Quote
In article <8t4a30$ed...@riker.addcom.de>, Rudolf Polzer wrote:
>"W.Riedel" <Rie...@ptb.de> schrieb im Newsbeitrag
>news:39f59f6d.8855174@Mamenchi.ZRZ.TU-Berlin.De...
>> On 23 Oct 2000 19:22:38 GMT, ronka...@cc.helsinki.fi (Osmo Ronkanen)

>But why dont you just use ANSI.SYS and write functions that output ANSI
>Escape sequences (->DOS 5.0 manual or DOS 6.2 online-help) instead of using
>such compiler-dependent tricks?

Because ANSI is dog-slow on a 386SX for real time applications.
 People didn't revert to direct screen
writes for no reason.

Re:Pascal evaluation order: how does Borland do it and what says the standard


"Osmo Ronkanen" <ronka...@cc.helsinki.fi> schrieb im Newsbeitrag
news:8t4c2f$pt2$1@oravannahka.helsinki.fi...

Quote
> In article <8t4a30$ed...@riker.addcom.de>,
> Rudolf Polzer <rpol...@web.de> wrote:

> >But why dont you just use ANSI.SYS and write functions that output ANSI
> >Escape sequences (->DOS 5.0 manual or DOS 6.2 online-help) instead of
using
> >such compiler-dependent tricks? What you have done could be done easier
> >using ANSI.SYS, and more reliably. But then you have to set
Crt.DirectVideo
> >to false, but I think you know.

> Why don't you learn the basics of programming PC screen. First the
> issue was speed. In that case DOS calls are NOT the way to go. Second
> Crt.Directvideo just affects whether the program uses BIOS calls or
> direct writes. Neither setting allow the use of ANSI codes.

> The simplest way to allow ANSI codes is not to use CRT at all.

> Osmo

If speed is the issue - do not use TP, use asm. If not, if you want to write
slow but working and bugfree programs - use TP.

--
Rudolf Polzer
REBOUNCE - http://www.mycgiserver.com/~rebounce
I wish I was what I was when I wished I was what I am now.

Re:Pascal evaluation order: how does Borland do it and what says the standard


On 24 Oct 2000 17:08:41 GMT (Marco van de Voort) wrote:

Quote
>In article <8t4a30$ed...@riker.addcom.de>, Rudolf Polzer wrote:
>>"W.Riedel" <Rie...@ptb.de> schrieb im Newsbeitrag
>>news:39f59f6d.8855174@Mamenchi.ZRZ.TU-Berlin.De...
>>> On 23 Oct 2000 19:22:38 GMT, ronka...@cc.helsinki.fi (Osmo Ronkanen)

>>But why dont you just use ANSI.SYS and write functions that output ANSI
>>Escape sequences (->DOS 5.0 manual or DOS 6.2 online-help) instead of using
>>such compiler-dependent tricks?

>Because ANSI is dog-slow on a 386SX for real time applications.
> People didn't revert to direct screen
>writes for no reason.

Direct screen is my standard mode. I didn't even know it, until
I wanted to "print screen" from keyboard once.
I used ANSI in the late 80s and stopped as soon as possible
mainly for reasons of low speed (I forgot it, you reminded me).
ANSI is AFAIK not able to handle run-time dependent
variables directly in the Write()-statement.

A question in context of dirty tricks (dirty in BP, not in
Standard Pascl):
I never use
   writeLN;        {but always}      Write( ^M^J );  
e.g.
   Write( ^m^j^M^J' two empty lines above'^m^j' next line ' );
Do you consider this a trick in BP ?

Wolfgang

Re:Pascal evaluation order: how does Borland do it and what says the standard


Quote
In article <39f6ad3f.3829...@Mamenchi.ZRZ.TU-Berlin.De>, W.Riedel wrote:
>On 24 Oct 2000 17:08:41 GMT (Marco van de Voort) wrote:

>>>But why dont you just use ANSI.SYS and write functions that output ANSI
>>>Escape sequences (->DOS 5.0 manual or DOS 6.2 online-help) instead of using
>>>such compiler-dependent tricks?

>>Because ANSI is dog-slow on a 386SX for real time applications.
>> People didn't revert to direct screen
>>writes for no reason.
>Direct screen is my standard mode. I didn't even know it, until
>I wanted to "print screen" from keyboard once.
>I used ANSI in the late 80s and stopped as soon as possible
>mainly for reasons of low speed (I forgot it, you reminded me).
>ANSI is AFAIK not able to handle run-time dependent
>variables directly in the Write()-statement.

>A question in context of dirty tricks (dirty in BP, not in
>Standard Pascl):
>I never use
>   writeLN;        {but always}      Write( ^M^J );  
>e.g.
>   Write( ^m^j^M^J' two empty lines above'^m^j' next line ' );
>Do you consider this a trick in BP ?

I work in (BP/Delphi compatible) FPC mainly, and there that is simply awfull.

Writeln should write the natural lineseparator, and yours always writes the
DOS one, which would confuse/mess up piping and screen on Linux/FreeBSD.

Re:Pascal evaluation order: how does Borland do it and what says the standard


In article <8t6uiq$jf...@riker.addcom.de>,

Quote
Rudolf Polzer <rpol...@web.de> wrote:
>"Osmo Ronkanen" <ronka...@cc.helsinki.fi> schrieb im Newsbeitrag

>If speed is the issue - do not use TP, use asm. If not, if you want to write
>slow but working and bugfree programs - use TP.

Come on, the penalty for using Pascal is nothing compared to that of
using ANSI.SYS. When  you use Ansi.sys there will be two BIOS calls for
each character that one outputs. It is perfectly possible to write fast
programs with Turbo Pascal, using ASM only where truly needed.

Osmo

Go to page: [1] [2]

Other Threads