by Dr. John D. Bullock, email/Internet: email@example.com
received September 29, 1992, revised 11-Jan-1993, 13-Jan-1993
Subject: Modula-2, Oberon-2, COMPLEX numbers, C, C++, PC hard- and software, Windows [NT], DEC Alpha, and other chitchat
1.0. PC Marketplace in the USA
The price drops for PC hardware in the USA has been precipitated by the popularity of Microsoft Windows 3.0, and the new 3.1 version since April 1992; both need a lot of CPU horsepower. Competition between Intel, AMD and CYRIX (in the future) in making the i386 (and soon i486) has also helped a great deal. Intel has only hinted about the i586 here (in early Fall '92) and they have pushed back delivery and official announcement until Spring 1993. There will probably be a big deal rollout at the Spring '93 COMDEX in Atlanta (I believe that is the location.). A brief note in the trade press yesterday (from Intel) said that the 80686 was on schedule and will probably be announced by Fall Comdex in 1994.
The PC based hardware world is also about to get a big shot in the arm from the Alpha PC from DEC by March 1993. With a 100 MIPS PC box using the EISA bus and probably local bus video for real time animation, the Alpha PC with Microsoft Windows 3.1 and the new Windows NT (32 bit) operating system, small system users will strap themselves in their ergonomic computer chairs with nice earth tone colors and never look back. Within about 5 years the world has gone from 3 MIP VaxStations at $20,000 each to 100 MIPs PC's at $3500 each. Computing by the end 1994 will be a brave new world, albeit with new software written in C and C++ creating gargantuan *.exe files and lots of DLL [ed. note: dynamic link] libraries. In two years 16 MB of memory and 200 MB of disk space will be entry level requirements.
Addendum: 1/11/93: The i586 is officially the Pentium, but who cares, it will always be just the "old P5" to the micro-crowd. The P5 will not be relevant until the end of 1994 because of cost and new system requirements. The more important next step for the x86 world will be the "P24T" or the unofficial i586SX. It is suppose to fit in the new expanded ZIF sockets showing up on new ISA (and a few EISA) VESA VL-Bus motherboards (MB). By the end 1993 these so equipped machines will be able to transform themselves into 50 mips superPCs. With the processor direct slots of the VL-Bus, real time video and 20 MB/sec SCSI-2 are just around the corner at 1/3 the old price. The new MBs may even be "ALPHA eaters". The end of 1993 will be wild for the PC minions. I am looking forward to 2001, the i986 at 200 mips, and the Modula-2 ISO draft finally being approved.
2.0. My Home Computer
I have put together a PC system using an Intel i486/33 cpu. As of today the system includes 64 KB cache, 16 MB of memory, 200 MB IDE disk with a caching IDE disk controller, CD-ROM on SCSI, SuperVGA 15" display (NEC 4FG) and a SuperVGA graphics card. Since I assembled the system a year ago, the price has dropped almost in half. Because of this price erosion, i486 systems are tending to take 50% of the market for new systems sold in the USA.
Addendum: 1/11/93: I added a 400 MB Quantum IDE drive (to match its 200 MB little brother) two weeks ago. (No food for the family, but I had a great Christmas. OK, so I promised the Lady of the Manor unspeakable amounts of "around the house" project work while praying for a rain every day this Spring and Summer.) Windows NT was crunching the available space down to zip. Development of Windows 3.1 apps under DOS and NT require a tidy 500 MB just to be comfortable.
3.0. Microsoft Windows NT
At the beginning of July I went to San Francisco for the Microsoft Windows NT Software Developers Conference. It was quite a spectacle with around 4800 geeks crammed into the main room to listen to Bill Gates, Dave Cutler, and numerous others from MS expound on what will probably be the next world standard operating system by 1995. Microsoft has been doing their homework (and have been apparently doing a lot of homework since 1988).
I received a copy of what they call the Developers Release, which is essentially an alpha release. The beta was promised for the end of September, but some MS upper level managers admitted a couple weeks ago that the beta would not be available until November. This places the operating system release date between a realistic April to July 1993. Better to be late and work than to be early and almost work which describes OS/2 V2.0. With support for only a handful of graphics cards and disk controllers and very poor Windows 3.0, not Windows 3.1, most people have done what I did; buy OS/2 for $49, try it out, then put it on the shelf and wait until the real release to see what happens.
I received a letter yesterday from Microsoft admitting that the NT beta and the second (official, there have actually been two so far) developers release have been delayed. The inference was for the end of October which means actually delivery by the middle of November. A beta for general distribution to end users will also be available then. NT is important to DEC since it will determine the success of the Alpha chip. Even if NT fails, it will still outsell UNIX which is irrelevant. VMS will become a footnote. I'll bet NT sells 2 million copies by the end of 1993 which will be more than 20 years of UNIX, ten times VMS and at least twice OS/2 2.0.
Addendum: 1/11/93: The official beta of NT arrived the first week of November '92. The copy I received on CD-ROM is billed as the developer's release. It is much better, but not much smaller. MS fixed several things but broke several others (e.g., the CD audio driver applet for Future Domain SCSI cards died and doesn't work now; it did work in July). There is still not a useful development environment for the 32bit C/C++ compiler and the debugger is flaky, but they can spit out code. The experts report on Compuserve that several things don't work and I can confirm that. MS admits this since I received a FAX two weeks ago asking for suggestions (as a C7 C/C++ user). My guess is for an NT release in June '93 at the earliest, but it will probably be more like September.
This will not help the DEC ALPHA PC, and I will down my guess of copies sold to 500,000 by the end of 1993. This may go lower since MS is also hinting that the base system price will be between $399 and $499 list to leave room for DOS 7 and Windows 4.0 in late '94. The latter package will include several NT features such as a 32bit flat address (single 4GB) space, new file system (Not NTFS), and multitasking. It has been referred to as "NT Lite" in the press although Microsoft hates the term. If MS wanted to they could bury OS/2 with a street price of $99 for NT in the "Summer of 93" followed with DOS 7/Win4 in '94 for a similar deal.
Before I lost all PDP-11 access at home and at work, I copied most of the M2 code I had written for the past five years to DOS floppy disk. I had purchased a M2 compiler for PCs last Spring from JPI. JPI was itself bought by someone not really interested in M2. ( I believe Clarion, but that's not a fact.) Since I have not heard anything from them for months, I assume they are not interested in old customers.
I talked to Stony Brook last week for the first time in several months. SB said they would update their M2 product by the end of the year, but is not a super high priority. They have only had three request for it to be ISO compliant, so they will not pay much attention to the standard including complex numbers and Object Oriented extensions. I guess they are surviving on their Turbo Pascal optimized compiler which makes Borland code look like grandma.
From this small but useful sample of opinion, it could be inferred that the general feeling in the USA (my guess) is that the Modula-2 standard is much to late to be market relevant. The USA PC (and UNIX) market(s) are dominated by Microsoft C and Borland C (and "cc" ) and to some extent their C++ extensions, but my guess is that C++ still represents less than 10% of the new code being developed. Turbo Pascal has a following but it is dwindling fast. A big comer in recent months for corporate business development is Visual Basic for Windows. (Version 2.0 has just been released.) The marketing arms of MS and Borland would like to change the fate of C++ , but short of a lot of free training and support to everyone, they have a long way to go. C or C++ on UNIX is way to expensive to be a market force like DOS on the PC.
5.0. How an engineer discovered the Oberon System
Well, because of a recommendation by Guenter Doztel in the July issue of The ModulaTor (Vol. 2, Nr 6), I purchased the second book in the OBERON trilogy entitled Programming in Oberon by Reiser and Wirth, at Siggraph '92 at the end of July in Chicago. Then I sent a letter to ETH at the end of August and received a floppy on Sept. 16th with the Oberon System for 386 based systems. I installed it and have been playing with the system off and on for about a week and a half. My initial impressions are good and it has certainly got my curiosity up.
5.1. Oberon Books
I could not find a copy of the first book entitled the Oberon System User's Guide by Reiser anywhere in Chicago. I finally special ordered it through the ACM in Maryland. (East coast USA programmers must be aware of new languages. NOT just C.) Then, by coincidence yesterday, I received a normal mailing from Addison-Wesley, the publisher in the USA, advertising the first and the second books, and the third, Project Oberon, by Wirth and Gutknecht as "hot new, must-haves". Hopefully the Oberon System will answer a lot of my questions.
I ordered the third book from A-W. Is there a more complete report on Oberon from ETH that covers the details not in the three books (Programming in Oberon, The Oberon Project and The Oberon System)? Where can I obtain more information?
Addendum: 1/11/93: I have all three books now and have been reading off and on for the past two months. Although I can't spend the time desired (since Windows 3.1 SDK and C suck up every spare minute just to hold the bugs to a manageable level), the light is slowly showing at the end of the tunnel.
5.2. First Impressions with the Oberon System
The DOS version (now at V1.1 in Sept. '92) seems to be missing several things. I have browsed several of the *.Obj modules and discovered symbol files missing. While trying to get the IFS module going it was first noted that XYplane.sym was missing because the compiler reported an error. Even though the listing is apparently in the back of the book (pg. 311-313), I did not want to retype the source. Why would the disk include the *.Obj files without the *.Sym file. Is this because of my lack of understanding about how the system works? Any suggestions?
I have exchanged FAX messages with A. R. Disteli at ETH Institute for Computer Systems. He tells me that several *.sym files were left off the disk. I am not sure why, because at the time of writing this he has not answered my most recent FAX.
I received a copy of the first Oberon book by Reiser last night. After a few hours reading a lot of my questions were answered although several thing do not work under DOS.
While the Oberon system that ETH distributes is interesting, I suspect that a compiler and linker plus libraries without the interactive environment will be more useful to programming task on the PC. As far as I know this is essentially what ModulaWare did with their Oberon-2 compiler for VAX/VMS.
Addendum: 1/11/93: I am now at Oberon Release 1.3 from ETH. Several problems above were fixed, but not those discussed in the next sections.
5.3. I Have Caught the Oberon Bug
After running Oberon off and on for the past three days I started to write the following notes which I've also
sent to A. Distelli at ETH-Zuerich. The notes are spread over sections 6.0 through 6.8. I realize that many of the complaints and questions could be dealt with in future releases, but the they may be of use to planners and implementors of Oberon and Oberon-2, especially for the PC environment.
6.0 Oberon for the "non" computer scientist.
In the process of discovering Oberon, I was ignoring several "paying" jobs I should have been working on but had become boring. But that is the nature of software and programming in general, and I could not think of a better way to waste time on Saturday (Sept. 26th '92) when I should be doing home repair projects. I also apologize in advance for my occasional American slang. I hope it is not unreadable or offensive.
I should also preface these remarks by saying that as I understand the Oberon System for PCs from ETH (and other workstations), it is primarily a research tool and not the commercial release of a product. However one of the reasons to disseminate the software around the world is to get other user, not necessarily computer scientist, to use it and show the warts, or suggest more universal language and user interface enhancements. I am not a computer scientist, but a scientist/engineer who is required to write code. When I "bailed out" of FORTRAN in 1984 and decided to learn a structured language for acoustic device and room modeling programming task, I looked around and picked Modula-2. Pascal was a little to amateur, and C was a nightmare (even though I must use it every day now). Within a couple years I learned to appreciate the elegant way M2 handled programming. With a lot of help from my friend Guenter Dotzel of ModulaWare, I learned and used M2 where I could but would not consider myself (close to) an expert. Guenter sent me early information and reprints about Oberon in 1988 and 1989. I have waited for a PC based Oberon system since 1988 and am glad it has finally arrived.
With the above qualifiers in place, I pose the following questions and comments (in sections 6.1 through 6.8). My only intention is to learn how to use the system and possibly help to enhance the use of Oberon in some small way.
6.1. The "Cursor Keys" in the Oberon system.
I understand the concept of the mouse driven interface, but from purely a users viewpoint a few basic key strokes (for cursor control) are handy when programming. Microsoft realized this with the Windows interface and included alternate keystrokes; too many in fact. After entering several small modules in a viewer this past weekend, I am convinced that the following keys (on the PC/AT 101 key extended keyboard) should be in the Editor and Write interfaces: Backspace (<-), up, down, left, and right arrows, and Delete. Page-up and page-down would make it complete. Only BS is there now. I say this from a user stand point of getting things done, and not from a purist computer scientist framework (which I am not).
I am in the process of writing a couple moderate size Windows 3.1 programs in C with touches of C++ (more on this later), but I am not a keyboard lover from the UNIX vi school or Brief school on the PC. I recently bought a copy of SlickEdit for NT work, but have not used it much because their mouse support is not running yet. I tend to use the mouse much more than some of my colleagues who are better typist. The point is I make these comments not as an anti-mouse user, but rather as a pro-mouse user.
Addendum: 1/11/93: I have the new copy of SlickEdit for DOS and NT but time pressures have forces me to stay with MS Programmers Work Bench (PWB). I use it as a dumb editor for C Win 3.1 work moving to the DOS window to run what are becoming large NMAKE files. I have tried Borland C++ V3.1 App. Framework under DOS/Windows 3.1 but it is a little "clunky" and not completely interchangeable with MS C7. I suspect not many care about Borland Object Windows Library (OWL) since several months must be spent just to get the notation down much less understand what is going on in C++ ... back to Oberon ...
6.2. Mouse Setup
To digress for a moment, I would like to suggest the following based on what I discovered with the mouse setup. The install instructions should state that a mouse driver, either MOUSE.SYS (config.sys) or MOUSE.COM (autoexec.bat) must be loaded for mouse support. This is not normal for an environment install. Windows supplies a mouse driver during the install and this was my assumption when I first started Oberon.
The instructions should also explicitly state that the appropriate mouse driver should be used for the following reasons. I have a Microsoft Inport mouse board and Microsoft two button (2B) mouse installed (for Windows NT alpha release compatibility) on my i486, but a Logitech Mouseman (MPD139MD) 3 button (3B) mouse sits next to the MS unit. Part of the problem with initial editing attempts was the clumsiness with the MS 2B Mouse (Yes, I read the instructions). I plugged the Logitech mouse into the Inport jack which works fine also as a 2B mouse. The 3B Logitech needs a Logitech driver (I used the mouse.sys driver from the middle of 1991) in order for all three buttons to work. This driver seems to work OK with the Microsoft Inport board (and 3B Logitech) and in the Oberon environment. MS does not apparently support three buttons with their driver (V8.2), i.e., obviously since their mouse only has two buttons. With all three buttons working, I finally got "cut and paste" to be reliable for editing. But not as complete for editing as per my comments in the previous section where a few additional keys being operational would be very useful. I also suspected the problem to be evident with PS/2 type mouse interfaces. I confirmed this on my PC at work (an Intel i486 EISA system, i403E) which has the small PS/2 mouse connector built on the motherboard.
These operational details on the mouse should be included in your release notes (in the .Text file on the disk) for completeness to reduce possible future install problems (and simply not waste time).
Addendum: 1/11/93: The version 1.3 release notes did not make installation that much clearer. One problem computer scientist have is not saying exactly what they mean for the benefit of non-computer scientist. Setting up the Oberon system should be spelled out in detail in the release notes so the user, expert or beginner, does not have to spend time guessing. I noticed be fore Christmas that some new Oberon converts in San Francisco have taken up the banner in the USA. Gee, I thought all bit-pusher in the city-by-the-bay "awk"ed and "cc"ed all day long. I stand (ah-h-h.. sit) corrected.
6.3. Mouse Cursor
The arrow cursor is too large for the (resolution of the) VGA screen. The tail of the arrow should be half as long (for one suggestion). Can other cursors be generated with Paint or Draw and installed as the system cursor? This was possible with the original M2 systems from ModulaWare with GDC-11 Q-Bus graphics adapter under RT-11 on my old PDP-11/73 back in 1984.
Is there a mouse fix to better control the viewer scroll?
Addendum: 1/11/93: Distelli sent some code with a possible fix for the mouse, but the code suggested had several bugs. Combined with my limited understanding of the Oberon PC system, I effected only a partial fix in Oct. '92.
6.4. Better Graphics Resolution
The mouse and VGA display bring up another suggestion. The system needs 1024x768 with 256 colors (minimum 16 colors). This should be either VESA compatible VGA extensions (even just 800x600 would be great) or better yet IBM 8514a drivers. Do not use the 8514 AI interface which is very slow, and do not assume interlaced video. There are several fast, high resolution cards in the USA which emulate 8514, e.g., ATI Graphics Ultra. But the most widely used Hi-Rez graphics chips in the USA by the middle of 1993 will be probably be the S3 911 (old one) and 924 (new one) combination. They are primarily used for 5 to 10 to 1 improvements in MS windows speed.
Addendum: 1/11/93: The most popular chip for graphics boards in the USA in '93 will be the 86C801 and '805 from S3 (including the 924 and 928 which use more expensive VRAM). The former use DRAM for graphics memory and improve the speed of Windows 3.1 5 to 10 times (over superVGA) for boards under $200. Based on recent revelations about XGA, the clone market will likely pass it by.
6.5. Symbol Files
Also another problem with *.sym files. After a successful compiled a module in an editor viewer, I changed a couple things while in an experimental mode and executed a new compile command in the system viewer. It compiles without apparently a code error but does not complete. Rather the system viewer shows an error 155, "generation of new symbol file not allowed". After deleting the symbol file, it will recompile but this can't be the proper method. What am I missing here?
Does the system require a TEMP or TMP variable assignment or SET in autoexec.bat for swap files?
Addendum: 1/11/93: The new ETH Oberon books #1 and #3 answered these questions to some extent.
Yes, my CIT 8510 works on the LPT1 port as a generic printer under the "Edit.Print LPT1 *" command for the marked (F1 -> *) or current viewer. But neither "line wrap" at 80 char's for example, nor "recognition/setting of page boundaries" is operational which makes printouts cumbersome. The 8510 completely chokes in Write which makes it useless for the present. I read some of the printer control notes in the Write manual, but I could not print it out in formatted form. We have Laserjets and Epson compatible printers at work.
To make the system useful to a majority of PC users, I suggest the following support options: (1) generic printer as is the case now but with limited in line control options for formatting, (2) a postscript laser as an absolute necessity as soon as possible (concentrate on the Apple LaserWriter NTX and HP Laserjet III series with a Postscript cartridge in the option slot), and (3) Epson LQ-1000 or LQ-2500 series 24 pin dot matrix (DM) printers. The Epson emulation is on virtually all DM printers sold in the USA. Drivers for these three printers would cover, I am sure, 95% of the printer in the world.
Addendum: 1/11/93: The Version 1.3 release from ETH did include support for Edit and the Com ports to a laser printer. After much playing I did get printouts to a Lasejet IIIP as a Postscript printer (with Pacific Page XL processor board installed). It works but is "tacky" to put it in a nice way. The Write print procedures did not work for me as of V 1.3. I have not seen a copy of of V1.4 even though I noticed it was in the CodePort LIB on Compuserve. My last download of Ver 1.2 which took over an hour was a problem.
6.7. Operating Systems
I am very interested in the Oberon System V1.2, but will wait for V2.0 if it is going to cost me another 50 SFr. A version which runs under OS/2 2.0 would be great. My intuition says that Windows32 as with NT and DOS will be the only relevant operating systems for the PCs by the end of 1993. However, it would be best for all PC users if OS/2 would be successful and challenge Microsoft because competition would improve both.
IBM just does not understand how to market anything when they must compete. I bought (a couple copies of) the bargain OS/2 upgrade for $49 (USA) back in the Spring but took it off the system by Summer and put it on the shelf. IBM has promised a fixed upgrade with 32 bit graphics and more support by Nov. '92 (V2.01), but now it is wait and see. OS/2 does not support enough graphics cards or disk controllers, Windows V3.1, and development software is too expensive. I am afraid the "old guys" at IBM are going to remain too greedy and slow to survive in the long run.
PS/2s are great hardware, but at two to three times the price of ISA and EISA PC/AT type systems (and soon high speed VESA VL-Bus direct slots for real time graphics), no one in the USA cares. Well O.K., maybe a few, but IBM has a long way to go. I plan on building a new system by Fall '93. If a loaded IBM i486/33-66 can be assembled for less than $3000, I (and many others) will be interested.
Addendum: 1/11/93: I received a beta of OS/2 V2.1 with the SDK a month ago. But because MS and IBM don't get along in life or on a multi-partitioned disk (without a kludge to the loaders), OS/2 is on hold. As of now, OS/2 V2.1 in the USA has not been released. I suspect they will wait until Spring COMDEX in April especially if Windows NT is late.
6.8. DOS Extender
I am expecting MS-DOS V6.0 beta in about a month. Supposedly it (still) will not include an extender as part of the operating system. The 32 bit DOS with one 4 GByte flat address space is allegedly scheduled for DOS 7.0 in late 1994. Too Late! Microsoft is playing marketing games. I would make Oberon V2.0 DPMI compliant and run with 386 to the MAX V6.02 when used without Windows 3.1. This is a more normal configuration for PCs. Users are not happy about separate config and autoexec files for "dumb" DOS "I own the whole machine" applications. Windows 3.1 includes partial DPMI compliance at V0.9 I believe. (I assume the readers are more aware of these details than I am.) The other rumor I heard somewhere was that 386MAX Version 7.0 will be available for DOS 6.0 and make 32bit DPMI clean and useful.
Bay the way, I noticed that the "system.free" command (in Oberon) showed only real installed RAM (15MB+ on my i486). I suggest considering Virtual Memory and roll Oberon pages out to disk for 4 MB and less systems (or larger). It could be a useful option for all memory levels in the future.
Addendum: 1/11/93: I am on beta 5 for DOS 6 and it looks good. My guess is only about half as successful as DOS 5 because it only adds features that can be had elsewhere (with complete add on packages) albeit for more money, i.e., it is not 32 bits and 64KB segments are still with us.
This concludes remarks sent to A. Distelli regarding the ETH Oberon system.
Recently I went to a seminar given by Bjarne Stroustrup on (what else) C++. During the morning session he made a disparaging remark about Pascal. Then during the break I asked him if he had seen or used Oberon. He said no, but had heard that the interesting part of Oberon was the interactive environment.
I am just now starting to slowly experiment in C++ because operator overloading and the complex number class allow writing engineering equations like FORTRAN, i.e., readable, as opposed to an unreadable jumble of multi-level function (procedure) calls. It appears that the M2 ISO committee has gotten the word and will include complex numbers in the language.
Addendum: 1/11/93: C++ is not the programming panacea many would like it to be. For the Microsoft Windows 3.1 (and up) programmer, an Oberon-2 compiler, IDE [ed. note: integrated development environment], and clean links to the MS libraries and DLLs would be a nice package to produce readable and maintainable code. I suspect many Microsoft Pascal programmers who were abandoned would like such a system. Even Turbo Pascal has strayed from the fold so far it is "goofy" (just my opinion); What the -ell is a UNIT?.
8. Oberon-2 for engineers?
Since I am not familiar enough with Oberon yet, I ask the following: Can Oberon return structured variables? Can the type extension facility be used to implement a complex number type which functions normally with the *,+,-, and / operators (as for real variables)? My understanding at this point says that the answer to these questions is "no." If "no", then the majority of the scientific community will be excluded from ever trying Oberon for the first time.
Addendum: 1/11/93: I am still waiting for an answer from the computer scientist al la Oberon jocks.
[Ed. long note: the answer is no! Most Oberon-2 implementations don't allow to return other than basic types. The only exception I know is AmigaOberon (V3?). H2O on VAX/VMS allows SYSTEM.QUADWORD and SYSTEM.OCTAWORD as function return which is sufficient to design basic complex arithmetic and complex library functions.
MODULE Complex; IMPORT SYSTEM; TYPE LONGCOMPLEX* = SYSTEM.OCTAWORD; PROCEDURE CADD * (c1,c2: LONGCOMPLEX): LONGCOMPLEX; END Complex.would allow to write
IMPORT C:=Complex; ... c3:=C.CADD(c1,c2);Just an idea (possibly an overkill) would be a class library for complex artithmetic in Oberon-2. 2. Example:
MODULE Complex; (* written in Oberon-2 by Guenter Dotzel, ModulaWare/12-Jan-1992 *) TYPE COMPLEX* = POINTER TO ComplexDesc; ComplexDesc=RECORD re,im: REAL END; VAR c1,c2,c3,c4: COMPLEX; PROCEDURE NewComplex * (VAR c: COMPLEX; r,i: REAL); BEGIN NEW(c); c.re:=r; c.im:=i; END NewComplex; PROCEDURE (c1: COMPLEX) ADD * (c2: COMPLEX): COMPLEX; VAR c: COMPLEX; BEGIN NewComplex(c, c1.re+c2.re, c1.im+c2.im); RETURN c; END ADD; BEGIN NewComplex(c1,1,2); NewComplex(c2,3,4); NewComplex(c3,5,6); c4:=c1.ADD(c2.ADD(c3)); (* c4 := c1+c2+c3 *) END Complex.Just an idea. Yes, it works! And it looks more natural because the method call associates
an infix notation. But the solution with pointers leaves the question for deallocation temporary expressions [at least on implementations without appropriate garbage collectors] open.
To answer John's second question: It is not allowed in Oberon-2 to redefine or overload built-in operators. But adding pervasive type COMPLEX and LONGCOMPLEX with operators +,-,*,/, =, and # together with the pervasive functions CMPLX, RE and IM a la ISO Modula-2 would be easy. Provisons are already made in H2O for these ISO M2-like extensions, since H2O uses the Modula-2 back-end which knows how to emit code for the complex-stuff, but this a language extension (although no syntax change) which must be discussed with ETH first.]
Addendum 1/11/93: Or lighten-up. While it may seem important, "tomorrow is always another day", and computers are not the only toys in the world.
The above comments are strictly (or STRICT, for the Win 3.1 SDK crowd) the ramblings of an engineer/scientist, but mostly 60's generation geek who was never quite motivated enough to bailout of the Ph.D. program (back then) and get an MBA to make some "real money". All the products and companies mentioned above own their "stuff" (in the George Carlin sense), and everyone pretty much knows (or should know) who owns what. Most of us are just software hackers trying to solve some problems and hoping that the experts will finally give us what we want even though marketing tells them they can't make money doing it. Besides, everyone knows that making money, i.e., "real money", is defined in the USA now as having the right six numbers on a small piece of paper, in any order, before we are too old to appreciate it and the kids have all the fun of spending it. Maybe the real truth was as the dancing GDC-11 [graphics] board in old ModulaWare ads use to imply, " Happiness is Modula-2", but now Oberon-2 will lead the way.
IMPRESSUM: The ModulaTor is an unrefereed journal. Technical papers are to be
taken as working papers and personal rather than organizational statements.
Items are printed at the discretion of the Editor based upon his judgement on
the interest and relevancy to the readership. Letters, announcements, and
other items of professional interest are selected on the same basis. Office of
publication: The Editor of The ModulaTor is Guenter Dotzel; he can be reached
by tel/fax: [removed due to abuse] or by
mailto:[email deleted due to spam]
Home Site_index Contact Legal Buy_products OpenVMS_compiler Alpha_Oberon_System DOS_compiler ModulaTor Bibliography Oberon[-2]_links Modula-2_links