Oberon-07

[Xcriber51]

Hi

I just saw this report...

http://www.inf.ethz.ch/personal/wirth/Articles/OberonARM/PortingOberon.pdf

..on Oberone-07, and saw in it the inclusion of Dijkstra's multi-branc
while construct. Which was great news :) I was wondering whether Prof
Wirth had included the much needed multiple assignment construct, as wel
(because it really gets tedious to write "swap" routines for ever
different type, and multiple ":=" (becomes) operators):

x, y, z := z, y, x;
i, j := i+1, j-1;

etc.

Also, does BlackBox 1.6 release candidate include the aforementioned ne
construct?

Thanks!

[Chris Burrows]

I was wondering whether Prof.
Wirth had included the much needed multiple assignment construct, as well

No - it is not included. For details see 'The Programming Language Oberon-07
(Revised Oberon)' and the summary 'Differences between Oberon-07 and Oberon'
can be download from:

http://www.inf.ethz.ch/personal/wirth/Articles/OberonARM/OberonARM.html

--
Chris Burrows
Armaide: Oberon-07 for ARM Development System
http://www.armaide.com

[August Karlstrom]

Post by Xcriber51
Hi
I just saw this report...
http://www.inf.ethz.ch/personal/wirth/Articles/OberonARM/PortingOberon.pdf
..on Oberone-07, and saw in it the inclusion of Dijkstra's multi-branch
while construct. Which was great news :) I was wondering whether Prof.
Wirth had included the much needed multiple assignment construct, as well
(because it really gets tedious to write "swap" routines for every
x, y, z := z, y, x;
i, j := i+1, j-1;
etc.

The reason the multi-branch while statement was introduced was to
compensate for the removal of LOOP and EXIT. Regarding the multiple
assignment construct I don't see the advantage, for me it tends to make
the code harder to read. Moreover, implementing a swap operation still
needs an extra variable behind the scenes and therefore is contrary to
the philosophy of minimizing hidden costs.


August

[Christian Luginbühl]

Wirth had included the much needed multiple assignment construct, as well
(because it really gets tedious to write "swap" routines for every

This would only solve one instance of the general problem of having to
repeat writing similar code for every different type. The real solution
would be support for parametric polymorphism.

Christian

[L505]

Post by Christian Luginbühl

Wirth had included the much needed multiple assignment construct, as well
(because it really gets tedious to write "swap" routines for every

This would only solve one instance of the general problem of having to
repeat writing similar code for every different type. The real solution
would be support for parametric polymorphism.
Christian

Yes see an experiment how I did it with Delphi and Freepascal to prove
the concept, using include file tricks.

http://z505.com/download/lars-poly.zip
http://z505.com/download/lars-poly2.zip

It would be best to have the language deal with parametric
polymorphism in an elegant way, instead of the include file tricks
above.

[Ludovic Brenta]

Post by L505

Post by Christian Luginbühl

Wirth had included the much needed multiple assignment construct, as well
(because it really gets tedious to write "swap" routines for every

This would only solve one instance of the general problem of having to
repeat writing similar code for every different type. The real solution
would be support for parametric polymorphism.
Christian

Yes see an experiment how I did it with Delphi and Freepascal to prove
the concept, using include file tricks.
http://z505.com/download/lars-poly.ziphttp://z505.com/download/lars-poly2.zip
It would be best to have the language deal with parametric
polymorphism in an elegant way, instead of the include file tricks
above.

Ada has had parametric polymorphism (called "generics" in the
language) since 1980.

--
Ludovic Brenta.