# Future Plans

## PM3

PM3 incorporates bug fixes, platform updates, and enhancements as they are contributed by several programmers on the internet. Below is a list of items of interest just waiting for contributors.

- Modula-3 Bindings for the GTK, GNOME and ORBit libraries and CORBA stubs generators.
- Produce binaries for several platforms at every release through remote compilation servers. We have LINUXLIBC6 computers readily accessible.
- Add Spencer's emacs files, m3na, and M3 TXL; if the authors submit an up to date version with HTML documentation, the inclusion will be immediate. Remove redundancy between the StubLib in Pickle and the one in Netobjrt. Check enumerating environment variables under NT386GNU. A few things need to be fixed in Trestle over win32 (fonts, deallocate some handles). Check if m3_strtod is still required in m3core/src/Csupport/LINUXLIBC6/dtoa.c, because of conflicts with strtod in libc.
- Decouple m3ship and m3where from m3templates. Currently m3ship is much too large needlessly.
- Progressively document all the packages using m3doc. For some packages a small introductory `index.html` file linking to public interfaces is sufficient. For some other packages, the m3totex documentation may be reused (vbtkit, netobj, stable, anim3D, m3tk).
- For Windows NT, get someone to look for native versions of gcc, gdb and binutils (avoiding the complexity of cygwin32.dll in the gnu-win32 chain of tools), to check if m3gdb works on version 19 of gnu-win32, and to add support for building dynamically linked libraries in the NT386GNU template.
- Duplicate modules in pm3 were detected using a modified m3browser and removed. Some similar modules still exist and should be merged, see [duplicates]. A few duplicated procedures do exist, most notably a few Quicksort.
- M3pp has problems with pragma EXTERNAL with flex/bison. It looks related to function BufferLexeme in lex_help.h which may depend on lex/yacc internals.
- Detect reusable components hidden in libraries and programs. Candidates include FSM, MText. Find a category specialist for each category to drive this effort and enhance the reusable components.
- Increase the use of generic modules. Text may be used for UNICODE support through generics based on Char.T versus WChar.T ([0..65535]). Similarly, geometry could benefit from generics based on Integer.T, Float.T, Point = ARRAY Axis OF Unit, where Axis is {x,y} for 2D and {x,y,z} for 3D. This could perhaps lead to anim2D versus anim3D.
- Track the evolution of HTML/XML and extensions for vector graphics. Evolve m3doc towards using these native features in XML as they appear.
- Document how Modula-3 can be used for real time programming, by using as little runtime support as possible.
- Check the gamma correction performed by Trestle and Image. If indeed gamma correction is useful (i.e. X windows does none while Mac and Windows do some and would thus display different colors for the same RGB values and bitmaps), find a way to let Image tell Trestle if something does not need to be gamma corrected instead of doing the work twice. The gamma correction overhead is indeed only a problem for large bitmaps.
- Build a library for browsing and analysing Modula-3 code, probably based on m3tk and m3browser. It could be used for computing metrics for Modula-3 programs, detecting procedure clones, extracting object oriented design diagrams (OMT/UML), or building an enhanced integrated development environment. Peter Klein is working on a Modula-3 development environment and associated user interface. See the report entitled ``Designing Software with Modula-3'', it describes a software architecture description language based on Modula-3. Klaus Preschern, Carsten Weich, Laszlo Boszormenyi have made the port of Modula-3 to the PC which includes a student-friendly development environment.
- Rework the HTML kit and the web packages to provide a single package for accessing WWW documents.
- Provide a serial port access package.
- Provide a high level Database interface, for both PostgresSQL and ODBC. Eventually provide a native implementation based on persistent objects for the same high level interface.
- Add some widgets to trestle/vbtkit like a grid (table/matrix) VBT. Incorporate modifications for a 3D look for scrollbars, Win32 mode for the TexteditVBT... Make rotated fonts available from Trestle.
- Find/develop graph layout and display packages. Such functionality may be available from the GRAS/Progres project. GraphVBT already does the display part.
- Extend the draw, sharedboard, html2ps, mgkit, visualobliq or anim3D packages to obtain a nice structured graphics package. This package, not unlike Unidraw/Interviews, could be used as a basis for diagram editors, rich text editors, Web browser widget, user interface builder...
- C to Modula-3 converter, initially for declarations (.h files), to interface C libraries to Modula-3 programs, but eventually for complete programs. The initial translation would convert to equivalent UNSAFE structures but subsequent passes may try to convert char_star to TEXT and so on.
- Develop a network object activator. Network objects servers would be started on demand.
- Add some authentication and access control to network objects, probably along with IPv6.
- Here is what Harry George had to say about his m3na.
  - I didn't known about SUBARRAY at the time, so sort of reinvented it. Probably could redo and make the code cleaner (and faster?)
  - I was experimenting with dynamic arrays -- probably to the detriment of the performance. Adding an object oriented layer on top of random number generators might have been a dumb move too.
  - Most array/matrix functions should accept a result array/matrix as a parameter, instead of creating one on the fly to return. or maybe accept one and return it as syntactic sygar.
  - It would be nice to have bindings for some of the std C numerical libs (nag, lapack, etc.). Or at least some of the items from them. Which of course means getting a binding-generator to work. I never got cbind to go properly.

## SRC Modula-3

Here is an unordered list of small and large tasks that should be done, which used to be kept on Bill Kalsow's desk and whiteboard. But, since it seems to grow rather than shrink over time, here it is. If you want to work on any of these tasks, go for it.

Copyright (C) 1992, 1996, Digital Equipment Corporation. All rights reserved.
See the COPYRIGHT for a full description.

### Driver

- Atomic update of .m3x files The .m3x files should be updated atomically. If the files are damaged, users get terribly confused. Similarly, if an object file gets produced and the version stamps don't get recorded, users are deceived.
- Integrate quake. We should write a Modula-3 version of quake that's callable as a library routine. Then, it should be integrated with the rest of the driver (Done in PM3). The resulting program could persist throughout a development session. Then, the reading, parsing and evaluation of m3makefiles could be cached across builds and the list of source files and configuration data wouldn't be passed through the file system.

- AST cache policy. The current driver keeps an in-memory cache of compiled interfaces, but never flushes entries. So, it's memory usage grows throughout a build. This will be unacceptable when the driver lives across multiple builds.

### Front end

- New definition of ADR. The front end should default to using the new definition of ADR, where instead of ADDRESS, ADR(x) returns an UNTRACED REF T when the static type of x is T. The new definition increases the safety of interfacing with the C world. This feature is available new with the "-X0@-new_adr@" option, but it should just be the default. The change will require a few source changes (m3core, libm3 and ui are already fixed). Ideally, the new types wouldn't require runtime typecells since NEW is never called on the new types and TYPECASE isn't applicable to UNTRACED REFs.

- Scanning floating-point literals. The front end uses the ancient `Convert` interface to convert ascii floating point values to internal binary form. We should use something like the new `Lex` interfaces.

- Floating-point constant folding. The compiler uses the host's LONGREAL type to represent floating-point values. Instead, it should provide a faithful emulation of the target machine's floating point. See `m3middle/src/TFloat.m3`.

- FIRST/LAST(REAL) According to the language definition, these should be plus and minus infinity on IEEE platforms. I am pretty sure that even if the front end used the right values, it would fail to pass them precisely to the back end.

- Missing debugger info. The following things are not passed through to the debugger: `IMPORT A AS B`, named scalar constants, the Modula-3 type of procedure return values.

- Unreachable TYPECASE arms. The compiler should emit a warning for a TYPECASE label T when an earlier label U is a supertype of T.

- Packed array literals. The front end doesn't always layout arrays of packed values correctly. See procedure `GenLiteral` in `m3front/src/exprs/ArrayExpr.m3`.

- Non-regular array literals. The front end doesn't detect 2-D open array initializers where the inner array values are of different sizes until it gets into code generation. It should cleanly report these errors during type checking.

- Type names to prelinker. If the front end passed user-sensible names for types back to the prelinker and they were preserved in the version stamp files, the prelinker could generate better error messages for inconsistencies (e.g. missing or repeated revelations) in the program's types.

- Field packing. Microsoft C supports a "pack" pragma that apparently overrides the normal field packing rules for structures. The result is that the Modula-3 compiler and C compiler disagree about some field layout. For example, `CommDlg.PrintDlg` has a 32-bit integer field that crosses a 32-bit boundary. A fix would be to define a per-platform parameter that describes the minimum (as opposed to preferred) alignment required for full-word loads. Then, BITS FOR could be used to fix up the offending layouts.

- Fingerprints of set literals. Set literals are not canonicalized before they are fingerprinted. They should be. See procedure `GenFPLiteral` in `m3front/src/exprs/SetExpr.m3`.

### GCC back end

- Stack overflow checking. The gcc-based back end doesn't check for thread stack overflows. Whenever a procedure is entered whose stack frame is larger than the thread stack's guard page (`Target.Guard_page_size`), the back end should emit an explicit test for stack overflow. At the moment the front end doesn't tell the back end size of the guard page and the back end doesn't know the size of the stack frame when it begins emitting code for the procedure.

- Gcc optimizer. It seems that every time I try using the optimizer I get burned. The most likely cause is that `m3cc/gcc/m3.c` is not building properly decorated trees. Given that there's almost no spec for well-formed trees, it's going to require intimite knowledge of gcc or lots of tinkering to find the problems.

- Floating-point opcodes on Alpha. The Alpha machine description should be modified to generate floating point opcodes that allow software fixups of denormalized values. It should also insert trapb instructions where needed.

- Mips-tfile vs. /bin/ld. On DS3100, the version of mips-tfile in gcc 2.5.7 generates object files that cannot be linked by /bin/ld. Problems occur when the object module defines an externally callable procedure and the linker is asked to generate the procedure table. If this problem was fixed, we could generate direct procedure calls rather than indirecting through the interface records.

### NT back end

- Return values from external procedures. Apparently, not all procedures (e.g. `NB30.Netbios`) return fully sign-extended results in the return register. I guess the conservative thing to do is to sign or zero extend all procedure results from external procedures. (and procedure variables too?)

- DLLs. We should be able to generate and use DLLs. Unfortunately, Microsoft requires different code sequences to reference a global variable (e.g. interface record) from inside and outside a DLL.

- CodeView symbols. The hooks in `M3ObjFile` already exist, we just need to generate the debugging data for CodeView debuggers.

- A RISC back end. Somebody should use `m3back` and `m3objfile` as starting points to building another backend for one of the current RISC processors. It's much faster to compile directly from M3CG to object file than to go through the "ASCII IL -> gcc -> ASCII .s -> assembler -> object file" mess. Once one RISC back end was written it should be pretty easy to write others. Register handling will be the primary difference from the NT back end. High quality code is not a goal.

### Runtime

- FloatMode and RealFloat interfaces. Most platforms don't have full implementations of the floating-point interfaces.

- Floating-point exceptions. On the DS3100 platform, we attempt to convert floating point traps into the proper Modula-3 exception. But, the traps are delivered via a Unix signal so the longjmp that delivers the exception must cross a signal handler stack frame. The last time I checked we go a "longjmp botch", so either the jmpbuf is incorrect, or you're not supposed to be able to jump out of a signal handler.

- NT -gui vs. Stdio. When a windows subsystem ("-gui") program is started, it's not given a console. Hence, writes to `Stdio.stdout` disappear. `libm3/src/os/WIN32/ProcessWin32.m3` should be modified so that the standard handles are bound to `File.T`s that lazily create consoles. Then, adding print statements to a GUI program would produce useful output.

- Table pickles. The generic table package should register pickle specials. There's no need to pickle a table's internal hash table. The pickle should just contain a list of name/value pairs. The resulting pickle would be robust against changes in the table's hashing function.

- Incremental GC. Several platforms that are capable of supporting the VM-synchronized, incremental and generational features of the garbage collector, need work. For example, ALPHA_OSF should be easy and NT386 should be possible.

- TCP on NT/386 The Unix TCP veneer needs to be ported to use WinSock.

- Error messages on NT We need to write or find a routine that generates a readable message from an NT error number. Such a routine must exist.

### Debugger

- Expression parsing and evaluation. The current expression parser and evaluator are woefully inadequate. For example, they don't handle floating-point literals, TEXT literals, or most of the built-in operations.

### Misc.

- Versioned shared libraries. There should be a way to provide multiple versions of a shared library. Operating systems that support shared libraries usually support some sort of versioning. The problem is to find a maintainable, portable way to do that in the current Modula-3 and m3build environment.

- QPT is broken. Jim Larus' QPT doesn't seem to work with DS3100 binaries. Possibly the problem is that it doesn't properly translate the exception tables in the initialized data segment. ??

- M3browser and type uids. It should be possible to find types by their 32-bit UID using m3browser.

- Exceptions as return values. What would it cost in time and space to implement exceptions as simple return values? Suppose you were allowed to change the calling convention so that each procedure call site had two return locations. Then, non-exceptional returns would cost nothing (except a little code space) and exceptional returns would be quite fast.

- Modula-3 parser. There should be a reusable, lightweight Modula-3 parser. Probably the parser should be easy to hack and lightweight rather than fully general, extensible, and slow as molasses.

- Validation suite. The current test package `m3tests` is a joke. Many more tests should be included. The m3makefile should be made to work on NT.

- M3ship warning. M3ship should warn you if the m3makefile is newer than the .M3EXPORTS files. Shipping a package after it's m3makefile has been modified, but before it's been reevaluated, often leads to confusion or surprise.