Extended Pascal
Sean Palmer
> >>PORT [$60], part of the built in port array. Check the value - it
> >>tell you the key currently being pressed (in a numeric code, of cou
> >>It will also, unlike inkey$, tell you about non-letter keys such as
> >>and cursor keys. Here's a demo program to show you how it works:
> readkey is not part of standard pascal but is part of the crt unit wi
> os dependant.
Br>Well, if it comes to that neither is any sort of port access a part of
Br>standard Pascal either. (or at least it wasn't the last time I looked!
Br>To use a "port" must assume certain things about the CPU or hardware to
Br>that's as dependant as using the CRT unit.
This is a real problem. Hopefully they address this and the video/file
system problems in standardizing Extended Pascal.
Need standard Modules or procedures for:
Keyboard
Mouse Input
Joystick Input
Graphics
Windowing System
Memory Access
and a standard way of including machine-specific assembly language in the
file. Borland's ASM .. END would work.
These standard modules they decide on should not be a 'spec' but full
source code that someone writing their own port of the standard can look at
and make sure what the routine is supposed to do. Specifications have a
habit of not being full and complete and/or having parts overlooked when
people flesh them out. A specification that has source to back it up is
needed.
Hopefully they'll provide some new operators too, like := returning the
value of the right-hand-side, ++/-- like C, +=,-= etc like C, and inline
procedures being part of the language spec so people can write macros in
pascal that don't turn into procedure calls. You know, things to help
people optimize their code.
Something else badly needed in the spec is a way to declare an array type
that doesn't have any particular upper bound, and can be bound to any other
compatible array.
Many of Borland's extensions to Pascal are extremely useful also. The stuff
they've done with Delphi (in beta) is just beautiful... I wish something
like their class/property mechanism would get included...
In other words, I want a definite improvement over Pascal, not just a
standardized version.
---
* WR # 380 * Eating on the Toilet: Pipelined Multitasking.
John R. Reagan
In article <ac.194...@delta.com>, sean....@delta.com (Sean Palmer) writes...
>This is a real problem. Hopefully they address this and the video/file
>system problems in standardizing Extended Pascal.
Well, Extended Pascal was completed in 1989.
>Need standard Modules or procedures for:
>
>Keyboard
>Mouse Input
>Joystick Input
>Graphics
>Windowing System
>Memory Access
The committee discussed having "standard" [read "required"] interfaces for
certain things but concepts like "joystick" don't make much sense on a Cray
for instance.
We then said "well, lets standardise them and say 'if provided by a vendor,
the required interface must look like...'". I was happy with that language
but alas most everybody else was not (also we didn't have any expertise
as to what interfaces to define much less what the looked like). So in the
end there are no required interfaces in the Extended Pascal standard.
We can certainly discuss making some defacto interfaces ourselves here
in this newsgroup for Extended Pascal. I'd be glad to help.
>and a standard way of including machine-specific assembly language in the
>file. Borland's ASM .. END would work.
You want a standard way of do non-standard work? Besides, as a writer
of a highly-optimizing compiler, letting you plop machine instructions
down in the middle of routine is highly unlikely to work.
>These standard modules they decide on should not be a 'spec' but full
>source code that someone writing their own port of the standard can look at
>and make sure what the routine is supposed to do. Specifications have a
>habit of not being full and complete and/or having parts overlooked when
>people flesh them out. A specification that has source to back it up is
>needed.
Again, almost be definition, most of the implementations of these
interfaces have to be machine specific! Accessing I/O ports on an
Intel DOS machine would certainly look different than accessing ports
on a Sun Unix machine!
>Hopefully they'll provide some new operators too, like := returning the
>value of the right-hand-side, ++/-- like C, +=,-= etc like C, and inline
>procedures being part of the language spec so people can write macros in
>pascal that don't turn into procedure calls. You know, things to help
>people optimize their code.
Well, Pascal has ":=" so I don't know what you want.
Extended Pascal does not include ++, --, +=, or -=. That is just syntacic
suger that didn't seem worth the cost. Just look at how many C programmers
get caught up with "foo(a++,++a,a--,--a)" and hope for a result?
As for INLINE, a good optimizer will automatically inline routines in the
best places for performance. Forcing the user to pick inlining would be
to force you to pick registers. Keep this up and Pascal will just be
a high-level assembly language!
>Something else badly needed in the spec is a way to declare an array type
>that doesn't have any particular upper bound, and can be bound to any other
>compatible array.
Extended Pascal's schema types do what you want (if I understand your
question).
>Many of Borland's extensions to Pascal are extremely useful also. The stuff
>they've done with Delphi (in beta) is just beautiful... I wish something
>like their class/property mechanism would get included...
Since the completion of Extended Pascal, the committee has gone on to
define Object Oriented features on top of Extended Pascal.
---
John Reagan
Application Compilers and Environments
Digital Equipment Corporation
rea...@hiyall.enet.dec.com
Disclaimer: The opinions and statements expressed by me are not
necessarily those of Digital Equipment Corporation.
---
Peter Benie
John R. Reagan <rea...@hiyall.enet.dec.com> wrote:
>
>In article <ac.194...@delta.com>, sean....@delta.com (Sean Palmer) writes...
>>This is a real problem. Hopefully they address this and the video/file
>>system problems in standardizing Extended Pascal.
>
>
>>Hopefully they'll provide some new operators too, like := returning the
>>value of the right-hand-side, ++/-- like C, +=,-= etc like C, and inline
>>procedures being part of the language spec so people can write macros in
>>pascal that don't turn into procedure calls. You know, things to help
>>people optimize their code.
>
>Well, Pascal has ":=" so I don't know what you want.
What he wants is to be able to say a:=b:=c to set a and b equal to the
value of c. Being able to do that means that you encourage programmers to
write if (a:=b=c) then ....
>Extended Pascal does not include ++, --, +=, or -=. That is just syntacic
>suger that didn't seem worth the cost. Just look at how many C programmers
>get caught up with "foo(a++,++a,a--,--a)" and hope for a result?
Since the compiler knows which variable is being incremented/decremented
on a particular line, it is possible to detect ambiguous instructions and
give an error.
Peter Benie
John Howard
: In article <ac.194...@delta.com>, sean....@delta.com (Sean Palmer) writes...
: >This is a real problem. Hopefully they address this and the video/file
: >system problems in standardizing Extended Pascal.
: Well, Extended Pascal was completed in 1989.
: >Need standard Modules or procedures for:
: >
: >Keyboard
: >Mouse Input
: >Joystick Input
: >Graphics
: >Windowing System
: >Memory Access
: The committee discussed having "standard" [read "required"] interfaces for
: certain things but concepts like "joystick" don't make much sense on a Cray
: for instance.
: We then said "well, lets standardise them and say 'if provided by a vendor,
: the required interface must look like...'". I was happy with that language
: but alas most everybody else was not (also we didn't have any expertise
: as to what interfaces to define much less what the looked like). So in the
: end there are no required interfaces in the Extended Pascal standard.
: We can certainly discuss making some defacto interfaces ourselves here
: in this newsgroup for Extended Pascal. I'd be glad to help.
What about if we wrote some EP modules that interface directly with the
ACCESS.bus protocol standards? We could then be assured of I/O support
for future devices. The A.b has been slow to catch on but support is
falling into place. By having Extended Pascal modules ready in advance
there will just be that one last hurdle of getting the A.b port built
into the PC or available cheaply as a card. (I looked into adding an A.b
port onto the PC gameport last October for a contest; but I stopped. It was
feasible but I had other things to do which kept me from making the
deadline).
The A.b was designed to handle slow I/O devices. Philips-Signetics
inter-integrated-circuit (IIC) chips provide the hardware compatibility
and they can cost under a $1 in volume. Digital Equipment Corporation
supports the ACCESS.bus standards and so do several third-party device
manufacturers.
If EP modules were written to support A.b protocols then programmers would
have a generic way to perform device I/O over the ACCESS.bus local area
network. There is a Base protocol specification, a Device Driver
Interface specification, a Locator device protocol specification, a Keyboard
device protocol specification, and a Text device protocol specification.
These specifications encompass devices such as mouse, 2-d/3-d joysticks and
touchscreens.
I got the ACCESS.bus specifications for version 2.2 dated February 1994 for
free in October. Contact:
ACCESS.bus Industry Group
370 Altair Way, Suite 215
Sunnyvale, California 94086
Tel: 1-408-991-3517
Fax: 1-408-991-3773
Duncan Murdoch
>>Extended Pascal does not include ++, --, +=, or -=. That is just syntacic
>>suger that didn't seem worth the cost. Just look at how many C programmers
>>get caught up with "foo(a++,++a,a--,--a)" and hope for a result?
>Since the compiler knows which variable is being incremented/decremented
>on a particular line, it is possible to detect ambiguous instructions and
>give an error.
I wouldn't want the compiler to give errors on ambiguous instructions. There
are occasions when ambiguity doesn't matter. For example, the following
expression is ambiguous:
variable := func1 ( func2 (v1), func3(v2) );
because it's conceivable that the functions have side effects and the order of
evaluation matters. I wouldn't want to use a compiler that rejected this line
because of ambiguity. I wouldn't expect a compiler to be able to figure out
that for these particular functions order of evaluation doesn't matter.
I agree with John Reagan's initial statement that these operators are just
syntactic sugar (you can write functions PreInc(x), PostInc(x), etc.).
Duncan Murdoch
Janos Szamosfalvi
: Hopefully they'll provide some new operators too, like := returning the
: value of the right-hand-side, ++/-- like C, +=,-= etc like C,
I hope not. If you want those operators -- use C.
Berend de Boer
SP> Many of Borland's extensions to Pascal are extremely useful
SP> also.
Well, most of them just maked the language more like C.... How longer I
tinker with Extended Pascal how more I love it. It really has some
things people have thought about (schema's for example).
Groetjes,
Berend (-:
fido: 2:281/527.23
email: ber...@beard.nest.nl
SEEN-BY: 1/1 60/0
Prakash G Kadam
Would anybody take pains to post EBNF for this extended Pascal.
It will help many of us to compare it with Borland Pascal.
Sean Palmer
>This is a real problem. Hopefully they address this and the video/file
>system problems in standardizing Extended Pascal.
JR>Well, Extended Pascal was completed in 1989.
Alas.
>Need standard Modules or procedures for:
>Keyboard
>Mouse Input
>Joystick Input
>Graphics
>Windowing System
>Memory Access
JR>The committee discussed having "standard" [read "required"] interfaces
JR>certain things but concepts like "joystick" don't make much sense on a
JR>for instance.
Ahhh. Yes that makes sense. And I suppose certain systems wouldn't have a
keyboard either (a Super Nintendo for instance...8)
JR>We then said "well, lets standardise them and say 'if provided by a ven
JR>the required interface must look like...'". I was happy with that lang
JR>but alas most everybody else was not (also we didn't have any expertise
JR>as to what interfaces to define much less what the looked like). So in
JR>end there are no required interfaces in the Extended Pascal standard.
JR>We can certainly discuss making some defacto interfaces ourselves here
JR>in this newsgroup for Extended Pascal. I'd be glad to help.
Ok, let's start with something simple: the keyboard.
Generic Keyboards can do three things:
1) Pop a character off the input queue. If none available, return error
Function GetKey:Integer;
Returns ord(char) if available, else -1
This would handle foreign character sets.
I still think char should be compatible with integer.
2) Query as to whether there are any characters to be received
Function KeyAvail:Boolean;
Returns true if a key is waiting, otherwise false.
3) 'Peek' at the next character without popping it off
This would allow primitive realtime parsing.
Function PeekKey:Integer;
Returns ord(char) if available, else -1
From these can be constructed the following:
4) Wait until a character is available. Then Pop the character.
Function WaitKey:Char; begin
while not KeyAvail do
{GiveUpTimeSlice};
WaitKey:=char(getKey);
end;
Some keyboards can provide additional information about scan codes
and whether the keys are up or down. They may be able to return the states
of the modifier keys. This should be addressed as well, although some
implementations may define the function to generate an error message
("unimplemented function" or some such)
>and a standard way of including machine-specific assembly language in
>file. Borland's ASM .. END would work.
JR>You want a standard way of do non-standard work? Besides, as a writer
JR>of a highly-optimizing compiler, letting you plop machine instructions
JR>down in the middle of routine is highly unlikely to work.
An approach where inlined assembly causes all registers to be invalidated
automatically, so that your optimizer knows that the values in the
registers must be refreshed after the inline code is done, or saved first
and reloaded afterwards, is how Borland handles it. I'm just saying that if
you are going to allow inline assembly, there should be a standard way of
introducing and terminating the assembly block (so that generic extended
pascal pretty printers will be able to safely skip such blocks, for
instance). Of course everything inside the block would be machine-specific
and completely non-portable, but let's leave the gateway open.
>These standard modules they decide on should not be a 'spec' but full
>source code that someone writing their own port of the standard can lo
>and make sure what the routine is supposed to do. Specifications have
>habit of not being full and complete and/or having parts overlooked wh
>people flesh them out. A specification that has source to back it up i
>needed.
JR>Again, almost be definition, most of the implementations of these
JR>interfaces have to be machine specific! Accessing I/O ports on an
JR>Intel DOS machine would certainly look different than accessing ports
JR>on a Sun Unix machine!
This is not what I meant. I merely wanted to define the ASM and END as the
introducer and terminator for a block that is machine-specific and
therefore non-standardized. It should be defined to be undefined in the
spec.
>Hopefully they'll provide some new operators too, like := returning th
>value of the right-hand-side, ++/-- like C, +=,-= etc like C, and inli
>procedures being part of the language spec so people can write macros
>pascal that don't turn into procedure calls. You know, things to help
>people optimize their code.
JR>Well, Pascal has ":=" so I don't know what you want.
I want := to produce a value, like this:
writeln(A:=B); {writes value of B after assigning B to A}
JR>Extended Pascal does not include ++, --, +=, or -=. That is just synta
JR>suger that didn't seem worth the cost. Just look at how many C program
JR>get caught up with "foo(a++,++a,a--,--a)" and hope for a result?
There would be no problem if the mechanism for compiling the expressions
was set in the spec. As long as you are sure the a++ above would get done
before the ++a (parameters evaluated and pushed from left to right), and
that all that would get done before foo() was called, you would know that
foo would get the parameter list (a,a+2,a+2,a) and that a would be
unchanged overall (barring overflows).
You have the same sort of problems with passing VAR parameters to functions
now, and using the functions' results as parameters to something else. If
more than one function is passed the same variable...???
function funcA(var v:integer):integer;
procedure procB(a,b:integer);
var C:integer;
begin
procB(funcA(C),funcA(C)); {this result is undefined in standard pascal}
end;
Certain platforms may be able to get more speed if they compile in a
different order. Fine. Those platforms' implementations can define a
directive that changes how parameter passing works that supercedes the
norm. But the end user should have to specify it, so he/she will know
what's going on and will know that it's no longer portable. C does this
with this kind of declaration:
int pascal aFunct(int a,int b) {}
In any case, with the order of execution defined for the above cases and
for expressions, you would be able to tell exactly what a statement will do
on any platform.
Another good example is the variable used for control in a FOR statement
being modified inside the loop. People do it all the time, but since nobody
bothered to define at what point in the loop the variable will be executed,
you can never be sure...
I think the For statement should be directly equivalent to this:
For A:=1 to 3 do statement;
A:=1;
While (A<=3) do begin
statement;
a:=a+1;
end;
Which brings up another point, people really hate writing things like:
bigArray[this,that]^.rec1.x:=bigArray[this,that]^.rec1.x+1;
And compilers generally have a hard time optimizing that. Much easier to
say:
++(bigArray[this,that]^.rec1.x);
or even
inc(bigArray[this,that]^.rec1.x);
or whatever. It's mainly a convenience for the programmer. Lets the
programmer optimize it so the compiler doesn't have to worry about it, as
well. But convenience is one of the things that makes or breaks a language.
When people are inconvenienced too much they move on to something else that
isn't as inconvenient. You do want this language to get used, don't you?
JR>As for INLINE, a good optimizer will automatically inline routines in t
JR>best places for performance. Forcing the user to pick inlining would b
JR>to force you to pick registers. Keep this up and Pascal will just be
JR>a high-level assembly language!
You will NEVER write a Pascal compiler that optimizes well enough to do
everything you need to do. Some people will want to write libraries in
Assembler and link them in. This needs to be addressed. Others will expect
their compiler to let them have access to assembly language if they want
it. *I* want it, and I know many many others who enjoy this liberty in
Borland Pascal 6.0 and above. Not every implementation needs to allow it,
but for those that do... it gives you a lot of power. Something
machine-optimized code lacks much of the time.
As I said before, people DO put inline assembly into their compilers, so
why not provide a standard place for them to put it?
The machine doesn't always know WHEN you want your routines inlined either,
and a way to suggest that it inline a particular routine would be nice.
>Many of Borland's extensions to Pascal are extremely useful also. The
>they've done with Delphi (in beta) is just beautiful... I wish someth
>like their class/property mechanism would get included...
JR>Since the completion of Extended Pascal, the committee has gone on to
JR>define Object Oriented features on top of Extended Pascal.
I must not have all the info I need yet. I will go hunting. I doubt very
much they have included something like their Property types... which are
probably the biggest breakthrough in fail-safe programming ever.
Transparent user-defined error/range checking. Nice.
Why do messages to me get posted as being to 'ALL' once they get here, I
wonder? I'm not used to the newsGroups yet.
---
* WR # 380 * Sex is nobody's business but the three involved
Sean Palmer
>>Extended Pascal does not include ++, --, +=, or -=. That is just syn
>Since the compiler knows which variable is being incremented/decrement
>on a particular line, it is possible to detect ambiguous instructions
>give an error.
DM>I agree with John Reagan's initial statement that these operators are j
DM>syntactic sugar (you can write functions PreInc(x), PostInc(x), etc.).
Not until the compiler can take any integer type as a parameter, you can't.
Only the compiler has access to enough type information to make it
feasible.
You people all seem to think of it as merely a shortcut, and maybe it is,
but without it I find that the compiler doesn't seem to be able to tell
what I want sometimes. And yes, it forces you to write multiline
workarounds in order to do something simple. The difference between an
Inlined optimized function to increment an integer variable and a dedicated
increment operator is that the compiler can optimize the ++ operator in
ways that using a function would make infeasible.
Incrementing by one is such a COMMON operation in computer programs, it's a
shame it doesn't have a dedicated operator anyway.
---
* WR # 380 * Safe sex used to mean to put the car in "Park"
Sean Palmer
JS>: Hopefully they'll provide some new operators too, like := returning t
JS>: value of the right-hand-side, ++/-- like C, +=,-= etc like C,
JS>I hope not. If you want those operators -- use C.
Bite me. Including them in the language wouldn't hurt you one bit.
And I'll push for more features in the language that I DO use as much as I
want, thank-you-very-much.
---
* WR # 380 * C program run. C program crash. C programmer drink.
Janos Szamosfalvi
: Incrementing by one is such a COMMON operation in computer programs, it's a
: shame it doesn't have a dedicated operator anyway.
Then what's Inc() for?
Janos Szamosfalvi
: JS>: Hopefully they'll provide some new operators too, like := returning t
: JS>: value of the right-hand-side, ++/-- like C, +=,-= etc like C,
: JS>I hope not. If you want those operators -- use C.
: Bite me. Including them in the language wouldn't hurt you one bit.
: And I'll push for more features in the language that I DO use as much as I
: want, thank-you-very-much.
I like to spend my about thinking algorithms and problemsolving
instead of deciphering cryptic code. Once those operators
(++ -- **, etc.) become available some people will combine them
in non-obvious ways.
Deutscher
: Sean Palmer (sean....@delta.com) wrote:
: : Incrementing by one is such a COMMON operation in computer programs, it's a
^^^^^^^^^^^^
No Fortran, please! <grins>
: : shame it doesn't have a dedicated operator anyway.
: Then what's Inc() for?
^^^^^^^^^ I knew someone would say that. Thank you. Eventhough for the
people out there who feel deprived when they can't increment a pointer
that may not be enough, but C is always there. For them.
Scott Moore
>Sean Palmer (sean....@delta.com) wrote:
Pascal is not a terse language. There are very opposed camps advocate
terse languages (like APL and C), and those that avocate "verbose"
languages. Similarly, there are "secure" (where the compiler
tries to prevent array/pointer misreferences, etc) and "free"
languages.
Since these lines of thought are so basic, you could say there are
four basic language layouts:
1. Terse/uncontrolled (C, BCPL)
2. Verbose/uncontrolled (Assembly ?)
3. Terse/controlled (APL)
4. Verbose/controlled (Pascal, Cobol)
The fact that each side has it's avocates is ample proof
in my opinion that a "grand unified" language is not really
a good idea. Just my two cents.
sam
--
------------------------------------------------------------------------
I have moved ! My new address is s...@ccnet.com
------------------------------------------------------------------------
Janos Szamosfalvi
: : Then what's Inc() for?
: ^^^^^^^^^ I knew someone would say that. Thank you. Eventhough for the
: people out there who feel deprived when they can't increment a pointer
: that may not be enough, but C is always there. For them.
Awright, here's one for ya: Ptr(Seg(pointer),Inc(Ofs(pointer))); ;-)
Of course, it's a bit more complicated than ++, but heck, it does
increment your pointer, even if it's not very useful and have a
subtle bug in it.
Deutscher
: Deutscher (s...@martha.utcc.utk.edu) wrote:
: : : Then what's Inc() for?
: : ^^^^^^^^^ I knew someone would say that. Thank you. Eventhough for the
: : people out there who feel deprived when they can't increment a pointer
: : that may not be enough, but C is always there. For them.
: Awright, here's one for ya: Ptr(Seg(pointer),Inc(Ofs(pointer))); ;-)
But I do *not* even want to increment pointers ...
However, instead of the Bor(ing)land Inc and Dec which are nonstandard
one could work with Pred() and Succ() which works on scalar arguments
(if that's the right translation), i.e. ordinal types and returns
the next in the row. On integers that would be n-1 or n+1, on self-defined
types it depends on the type, and on reals --- no luck. There is no unique
successor for a given real number. Anyway.
: Of course, it's a bit more complicated than ++, but heck, it does
: increment your pointer, even if it's not very useful and have a
: subtle bug in it.
^^^^^^^
Yup. THe obvious one is it uses Seg() and Ofs() which is really non-standard
and Borland and PC typical and such. Try that on my Sun 4/690 or on an
IBM/3090 mainframe or on the AXP-7000/620 I am using, or ...
Stefan
Janos Szamosfalvi
: : : ^^^^^^^^^ I knew someone would say that. Thank you. Eventhough for the
: : : people out there who feel deprived when they can't increment a pointer
: : : that may not be enough, but C is always there. For them.
: : Awright, here's one for ya: Ptr(Seg(pointer),Inc(Ofs(pointer))); ;-)
: But I do *not* even want to increment pointers ...
Then why mention it ?
: However, instead of the Bor(ing)land Inc and Dec which are nonstandard
: one could work with Pred() and Succ() which works on scalar arguments
: (if that's the right translation), i.e. ordinal types and returns
: the next in the row.
There are some differences between Inc(), Dec() and Succ() Pred().
: : Of course, it's a bit more complicated than ++, but heck, it does
: : increment your pointer, even if it's not very useful and have a
: : subtle bug in it.
: ^^^^^^^
: Yup. THe obvious one is it uses Seg() and Ofs() which is really non-standard
: and Borland and PC typical and such.
No, that's not a bug. The bug I was in my mind is the possible
overflow during Inc(Ofs(pointer)).
Duncan Murdoch
>DM>I agree with John Reagan's initial statement that these operators are j
>DM>syntactic sugar (you can write functions PreInc(x), PostInc(x), etc.).
>Not until the compiler can take any integer type as a parameter, you can't.
>Only the compiler has access to enough type information to make it
>feasible.
There aren't that many integer types. Writing a PreInc and PostInc for each
will take you about 10 minutes, or half an hour if you optimize. This will
have a side benefit: it makes you aware of the type of x. How many bugs are
caused by forgetting the exact type of x? The trouble with Borland's Inc()
and C's ++ is that they work on anything, even if the result isn't what you
had in mind.
Duncan Murdoch
Duncan Murdoch
>No, that's not a bug. The bug I was in my mind is the possible
>overflow during Inc(Ofs(pointer)).
That has at least two other bugs in it, one not so subtle:
1. You can't Inc a value, you can only Inc a variable.
2. You should be working on the value stored in the pointer, not on the
address of the pointer, i.e. pointer^ instead of pointer.
Duncan Murdoch
Janos Szamosfalvi
The pointer^ thing was obviously an oversight on my side; I know I have
used similar pointer mangling before and it worked fine. I may have
used my own Inc, though.
Iain McK Gibson CS91
> I like to spend my about thinking algorithms and problemsolving
> instead of deciphering cryptic code. Once those operators
> (++ -- **, etc.) become available some people will combine them
> in non-obvious ways.
I agree with what you are saying. Basically the more ways you allow a programmer
to say somthing the more ways you will provide to make what you are intending
look arcane. I think the extensions to Pascal should give the programmer more
opportunites do do different things rather than more relaxed, sloppy ways to
write the same thing.
Sean Palmer
D >: : shame it doesn't have a dedicated operator anyway.
D >: Then what's Inc() for?
D >^^^^^^^^^ I knew someone would say that. Thank you. Eventhough for the
D > people out there who feel deprived when they can't increment a pointe
D > that may not be enough, but C is always there. For them.
Inc is not part of any standardized pascal that I know of.
And if I have to write my own language to get the operators I want without
resorting to using the C monster, I will.
I abhor C not because of its operators and control structures, but for its
header files and libraries. It was designed in a manner that makes it hard
to read, ALL of it, not just the expressions. But the operators it has are
quite useful in actual practice.
I'll put it this way... If I wanted to write in English I'd use COBOL. ICK!
If I wanted to write in Gibberish I'd use C and never get anything done.
If I wanted to optimize every little thing I'd use ASM, but I don't, I only
use ASM for things that need ASM.
The rest of the time I use Pascal. And I'd use Pascal a whole lot MORE if I
DIDN'T have to resort to assembly to make halfway tight code!
Oh well I don't expect anybody to listen anyway so I suppose I'll continue
working on my own language.
---
* WR # 380 * I am solidly behind whichever side eventually wins.
Sean Palmer
JS>: ^^^^^^^^^ I knew someone would say that. Thank you. Eventhough for th
JS>: people out there who feel deprived when they can't increment a poin
JS>: that may not be enough, but C is always there. For them.
JS>Awright, here's one for ya: Ptr(Seg(pointer),Inc(Ofs(pointer))); ;-)
JS>Of course, it's a bit more complicated than ++, but heck, it does
JS>increment your pointer, even if it's not very useful and have a
JS>subtle bug in it.
Try Succ instead of Inc and that might work...
---
* WR # 380 * There must be a demand for useless software.
Sean Palmer
>Not until the compiler can take any integer type as a parameter, you c
>Only the compiler has access to enough type information to make it
>feasible.
DM>There aren't that many integer types. Writing a PreInc and PostInc for
DM>will take you about 10 minutes, or half an hour if you optimize. This
DM>have a side benefit: it makes you aware of the type of x. How many bu
DM>caused by forgetting the exact type of x? The trouble with Borland's I
DM>and C's ++ is that they work on anything, even if the result isn't what
DM>had in mind.
function PreIncInteger(var v:integer):integer;begin
inc(v);
preIncInteger:=v;
end;
function PreIncWord(var v:word):word;begin
inc(v);
preIncWord:=v;
end;
function PreIncShortInt(var v:ShortInt):shortInt;begin
inc(v);
preIncShortInt:=v;
end;
function PreIncByte(var v:Byte):byte;begin
inc(v);
preIncByte:=v;
end;
function PreIncLongint(var v:longint):longint;begin
inc(v);
preIncLongint:=v;
end;
function PreIncChar(var v:char):char;begin
inc(v);
preIncChar:=v;
end;
function PreIncMyOwnType(var v:myOwnType):myOwnType;begin
inc(v);
preIncMyOwnType:=v;
end;
Ok, Duncan, thats only the PreInc() operator.
Now show me a 80xxx extended pascal compiler that can optimize a call to
preIncInteger(a) to the following two machine language instructions:
inc word ptr [a]
mov ax,[a]
I highly doubt it, but this is the very kind of jumping through hoops that
I'm sick and tired of having to do all the time.
Give the damned language a ++ operator and poof the compiler (even a
non-optimizing one) can do that!! WOW! And you don't have to write ten
thousand different routines to do it!
You really don't understand how ridiculous you're sounding to me, do you
DJ?
I REITERATE, you don't have to USE them if you don't WANT to.
*I* WANT to.
Hell I'd even be a little happy if Inc() was standardized, and made into a
preInc function... postInc can always be rewritten to use PreInc, so is
not really needed.
---
* WR # 380 * Milkbone underwear for a dog eat dog world
John Howard
Date: 28 Jan 1995 03:06:03 GMT
Message-Id: <3gccar$d...@solar.sky.net>
John R. Reagan (rea...@hiyall.enet.dec.com) wrote:
: In article <ac.194...@delta.com>, sean....@delta.com (Sean Palmer)
writes...
: >This is a real problem. Hopefully they address this and the video/file
: >system problems in standardizing Extended Pascal.
: Well, Extended Pascal was completed in 1989.
: >Need standard Modules or procedures for:
: >
: >Keyboard
: >Mouse Input
: >Joystick Input
: >Graphics
: >Windowing System
: >Memory Access
: The committee discussed having "standard" [read "required"] interfaces for
Duncan Murdoch
>Ok, Duncan, thats only the PreInc() operator.
How long did it take you? I bet it didn't even take the 10 minutes that I
estimated, and now it's done, forever, never needing to be done again.
>Now show me a 80xxx extended pascal compiler that can optimize a call to
>preIncInteger(a) to the following two machine language instructions:
> inc word ptr [a]
> mov ax,[a]
Any compiler that claims to be an optimizing compiler should do that. It's a
simple, obvious optimization. I can't offer you an example of one that does
because I don't use Extended Pascal, but I bet someone else will.
Just because some compilers (e.g. Borland's) claim to be optimizing compilers
when they hardly do any optimization at all doesn't mean all optimization is
so limited.
>Give the damned language a ++ operator and poof the compiler (even a
>non-optimizing one) can do that!! WOW! And you don't have to write ten
>thousand different routines to do it!
Sorry, I didn't see ten thousand routines. You must have left some out of
your message. But if you don't write the ten thousand routines, then the
compiler writer will have to do it. And if you don't like their choice of
semantics (e.g. does a PreInc overflow trigger an overflow error?),
then you'll have to do it yourself anyways.
Duncan Murdoch
Janos Szamosfalvi
: Inc is not part of any standardized pascal that I know of.
You're right. Pred and Succ are, however, standardized, although
they are a bit different from Inc and Dec.
: I abhor C not because of its operators and control structures, but for its
: header files and libraries. It was designed in a manner that makes it hard
: to read, ALL of it, not just the expressions. But the operators it has are
: quite useful in actual practice.
I had to write quite a few things in C and C++ , and in average I spent
about 2 - 3 times as much time debugging stupid little errors than in Pascal.
It's a pain.
: Oh well I don't expect anybody to listen anyway so I suppose I'll continue
: working on my own language.
Since Borland doesn't seem to release BP 8.0 anytime soon, someone
could fill the void. :-)
Janos Szamosfalvi
: JS>Awright, here's one for ya: Ptr(Seg(pointer),Inc(Ofs(pointer))); ;-)
: JS>Of course, it's a bit more complicated than ++, but heck, it does
: JS>increment your pointer, even if it's not very useful and have a
: JS>subtle bug in it.
: Try Succ instead of Inc and that might work...
I know the code had just way too many bugs in it. :-)
Anyway, I looked up the actual code, and find the following:
(overflow check omitted here)
Ptr(Seg(pointer^),MyInc(Ofs(pointer^), Sizeof(pointer^)));
I'm not sure what Succ does on pointers -- I think it will
barf, or Inc as if it were an Integer.
s...@ccnet.com
>The rest of the time I use Pascal. And I'd use Pascal a whole lot MORE if I
>DIDN'T have to resort to assembly to make halfway tight code!
Although this comment usually starts an argument, Pascal and Pascal like
languages can generate smaller and faster code than C in most cases. The
reason why is that with all the tight typing rules, subranges and other clues
that you give the compiler to operate with allow it to do a much more through
job of optimization.
Having said that, however, the existing Pascal compilers, at least for PCs,
are universally bad. But this is because the current lack of Pascal usage
does not foster the compiler competition that would force more efficient
compilers (in fact, the majority of Pascal users buy from a single software
source, Borland).
------------------------------------------------------------------------------
| JUST SAY NO -- TO THE GIF (Greed Is Fundamental) FORMAT. |
| SEND "STEALTH STANDARDS" BACK TO HELL WHERE THEY CAME FROM. |
------------------------------------------------------------------------------
| Get slip access for shell prices with TIA ! |
| Microwave: Def: Device used in the manufacture of rubber goods. |
| Fuzzy logic: Def: Method of engineering taught by several universities. |
| Segmentation: Def: A small box used to keep programmers in. |
| Get a life ! Now available for very reasonable terms and prices. |
| |
| SAM is s...@ccnet.com |
------------------------------------------------------------------------------
Peter Benie
Date: 27 Jan 1995 23:52:36 GMT
Message-Id: <3gc104$l...@lyra.csx.cam.ac.uk>
In article <3gb69g$s...@jac.zko.dec.com>,
John R. Reagan <rea...@hiyall.enet.dec.com> wrote:
>
>In article <ac.194...@delta.com>, sean....@delta.com (Sean Palmer)
writes...
>>This is a real problem. Hopefully they address this and the video/file
>>system problems in standardizing Extended Pascal.
>
>>[snip - pjb]
>
>>Hopefully they'll provide some new operators too, like := returning the
>>value of the right-hand-side, ++/-- like C, +=,-= etc like C, and inline
>>procedures being part of the language spec so people can write macros in
>>pascal that don't turn into procedure calls. You know, things to help
>>people optimize their code.
>
>Well, Pascal has ":=" so I don't know what you want.
What he wants is to be able to say a:=b:=c to set a and b equal to the
value of c. Being able to do that means that you encourage programmers to
write if (a:=b=c) then ....
>Extended Pascal does not include ++, --, +=, or -=. That is just syntacic
>suger that didn't seem worth the cost. Just look at how many C programmers
>get caught up with "foo(a++,++a,a--,--a)" and hope for a result?
Since the compiler knows which variable is being incremented/decremented
on a particular line, it is possible to detect ambiguous instructions and
give an error.
Peter Benie
Chamal PANDITHARATNE
Does anyone out there know where I might find a standard pascal compiler for the PC.
Failing that does anyone know how to export user defined types from a function, e.g:
program blah;
type
store = array[1..10] of char;
function thingy:store;
begin
end;
When I tried to do this in Turbo Pascal 7 I just got returned the error: Illegal return type.
With thanks in anticipation,
Chamal......
Janos Szamosfalvi
: Dear All,
: Does anyone out there know where I might find a standard pascal compiler for the PC.
: Failing that does anyone know how to export user defined types from a function, e.g:
: program blah;
: type
: store = array[1..10] of char;
: function thingy:store;
: begin
: end;
: When I tried to do this in Turbo Pascal 7 I just got returned the error: Illegal return type.
Functions can't return composite types. As someone else suggested,
you can use VAR to "return" composite types, you can also return a
a string that allows to return (after casting!) anything up to 255 bytes
long, or you can return a pointer that can point to something up
to 64kb big.
Bob Schor
>program blah;
Dear Chamal,
The reason for your problem is that functions can only return simple data
types and pointer data types. In particular, a function cannot return a
record type, a file type, an array type, or a set type.
There is, however, a standard work-around. Recall that a formal
parameter of either a function or a procedure which is declared as a VAR
parameter can be used to pass results back out of the sub-routine. You can
thus replace the declaration
FUNCTION thingy : store;
and the call
mystore := thingy
with the procedural form
PROCEDURE thingy (VAR result : store);
and call
thingy (mystore);
The only other difference is within "thingy". For the function, you
assign the result to "thingy" itself; with the procedure, you would assign to
the VAR parameter "result".
Bob Schor
Pascal Enthusiast
Holger Friedrich
In article <3jpjrh$k...@yama.mcc.ac.uk>, Chamal PANDITHARATNE (se...@sna.co.umist.ac.uk) writes:
>type
> store = array[1..10] of char;
>function thingy:store;
>
As was already pointed out, you are always free to return a pointer
to anything of any type that you may care to define.
In this particular example, though, array of char isn't even a
user-defined type. If you let the standard TP/BP7 string functions
handle all the operations on an array of char, you can just use
the standard type pChar for the return value of the function. Like
this:
function Thingy: pChar;
const Temp: array[0..10] of Char = '';
begin
{ do some stuff with Temp }
Thingy := StrNew(Temp);
end;
And if Temp were not just a local variable of that function, you
could also do Thingy := @Temp.
Of course, if you put individual characters in your array yourself
and don't make sure that the terminating zero is there, the StrNew
will probably crash the program. If you do this, better define a
pointer type to your data type:
type tStore = array[0..10] of Char;
pStore = ^tStore;
function Thingy: pStore;
const Temp: pStore = nil;
begin
Temp := New(pStore);
{ do some stuff with Temp^ }
Thingy := Temp;
end;
Hope this helps.
--
Holger Friedrich
Chemnitz, Germany
h...@glare.in-chemnitz.de