From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_05,INVALID_DATE, MSGID_SHORT autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!attcan!uunet!mcvax!enea!sommar From: sommar@enea.se (Erland Sommarskog) Newsgroups: comp.lang.ada Subject: Re: Verdix Corp ADA-language development systems Message-ID: <3918@enea.se> Date: 26 Aug 88 22:05:33 GMT Organization: ENEA DATA AB, Sweden List-Id: David E. Emery (dee@linus.UUCP) writes: >Verdix is 1 of only 2 compilers that that I know to implement code >sharing of generic bodies. Furthermore, Verdix does NOT require that >the body of a generic be compiled before its instantiation. It is >possible to write mutually dependent generics (each generic >instantiates the other) in Verdix, where most compilers will gag on >such code. We're having 5.41 of VADS here for VAX/4.3BSD, and I have written several error reports on VADS, and more than one of them was on generics. For instance, the debugger couldn't find the source for generic procudure within a generic package. Even more amazing was to find a generic package to be dependent of its instantiator! A good point is that if you change a generic body, instantiators doesn't get invalidated, like they do with DEC/Ada. But the recompilation takes a very long time. Another problem I have had with VADS are the DIANA files. They get BIG, and *eats* diskquota. (And a.rm doesn't clear away old instantiations.) To make things worse, units from other libraries are cached in a local directory. Tip if you plan to use VADS: Get your own disk, and don't have any quota. -- Erland Sommarskog ENEA Data, Stockholm - Why are Macintosh screens so small? sommar@enea.UUCP - Big Mac is registered by McDonald's.