JIM@UCF1VM.BITNET (Jim Ennis) (06/07/88)
Hello net, I found this bounced mail at my site. Jim Ennis - JIM@UCF1VM.BITNET >From: Nathan Bohlmann <ACC.NATE@VALPO> >To: INFO-M2@UCF1VM Greetings all, This is my first time submitting to this list as we are using a very crippled mailer here and I finally found out it doesn't put headers on my outgoing mail. Anyway, that obstacle over, I have a few words to say about the JPI Modula-2 compiler from Jensen and Partners Intl. since that has been a subject of interest lately. I can only say one thing about the system: It's FANTASTIC. I love it. The compiler is FAST, the code produced is very compact and the environment is absoultely great. It comes with a time-sliced scheduler/manager which is used in the demos that come with the compiler and it works very well on my Zenith Z-248 machine. (That's a 80286 machine for those who don't know.) The compiler has a multitude of switches so that you can do just about anything you want to a given program's running environment just by setting a few switches. I have done a bit of crude benchmarking with Turbo C and Turbo Pascal 4.0. What I found agrees with what their ads state. JPI Modula-2 beats them in every respect. I have used the compiler to compile Ken Yap's ZCAT decompressor and found that the language has the bit-shift operators built-in. This leads me to one of the flaws in the language. It has extensions out the kazoo. I do think most of them stay within the spirit of Modula-2 and I do know that most of them are very useful such as the bit-shifting and built-in type-casting which can be accomplished as follows: If Type1 is of type CARDINAL then to get an value of integer type all you need to do is say INTEGER(Type1). That's all there is to it. There are several other extensions which escape me at the moment. These extensions can be very addictive. One thing to keep in mind though is that the base Modula-2 definition is encompassed in this compiler so that 'standard' stuff should run with very few hitches. One thing that threw me for a loop the first time I encountered it though, is that this compiler does its reads funny. Instead of making the different ReadType's procedures with a variable parameter, they made them functions with no parameters that return the type you are reading. It just takes a little getting used to. A comment on the development environment. I was able to convert the neural network simulator that Mitch Wyle posted a while back in one evening. Not bad at all. The compiler automatically checks all of the dependancies in the current module and the compiles the modules needing it. That makes life much easier when working on a project of that size. One final comment. I received today a posting from Albert Meier at the Swiss Standardization Body on type casting. I would like to see the proposal from Pat Terry. Also I would like to suggest that the Standardization Body look at the way type casting is done in the JPI compiler. It works very nicely and is very readable. I would like to see something similar to this in a standard. I will be more than happy to answer any specific questions about the JPI compiler if you mail to me directly. Nathan Bohlmann ACC.NATE@VALPO Disclamer: I don't have any connection to Jensen and Partners Intl. other than being a very satisfied customer. =========================================================================
keithc@cognos.uucp (Keith Campbell) (06/14/88)
In article <INFO-M2%88060616534629@UCF1VM> Nathan Bohlmann writes: >type-casting can be accomplished as follows: > If Type1 is of type CARDINAL then to get an value of integer > type all you need to do is say INTEGER(Type1). That's all > there is to it. >There are several other extensions which escape me at the moment... I believe that the feature to which you refer, is NOT an extension, but rather has always been in the definition of modula2. Has some standardization effort removed it? -- Keith Campbell Cognos Incorporated S-mail: P.O. Box 9707 Voice: (613) 738-1440 3755 Riverside Drive FAX: (613) 738-0002 Ottawa, Ontario UUCP: decvax!utzoo!dciem!nrcaer!cognos!keithc CANADA K1G 3Z4
alan@pdn.UUCP (Alan Lovejoy) (06/16/88)
In article <3179@cognos.UUCP> keithc@cognos.UUCP (Keith Campbell) writes: >In article <INFO-M2%88060616534629@UCF1VM> Nathan Bohlmann writes: >>type-casting can be accomplished as follows: >> If Type1 is of type CARDINAL then to get an value of integer >> type all you need to do is say INTEGER(Type1). That's all >> there is to it. >>There are several other extensions which escape me at the moment... > >I believe that the feature to which you refer, is NOT an extension, >but rather has always been in the definition of modula2. Has some >standardization effort removed it? In Wirth's Modula-2, "INTEGER(65535)" has the value -1 (on a two's complement machine with 16-bit INTEGERs). In BSI/ISO Modula-2, it is an overflow error. In the first case, the type transfer is not meaning preserving, but bit-pattern preserving. In the second case, the opposite is true. The above quote does not explain which option is implemented by the compiler in question. I think the BSI approach is superior. BSI also has defined a mechanism for bit-pattern preserving (non-meaning preserving) type transfers. It is a pseudo-function that must be imported from SYSTEM and whose name currently escapes me. So BSI's langauge has the same (in fact, more) functionality but with different syntax. -- Alan Lovejoy; alan@pdn; 813-530-8241; Paradyne Corporation: Largo, Florida. Disclaimer: Do not confuse my views with the official views of Paradyne Corporation (regardless of how confusing those views may be). Motto: Never put off to run-time what you can do at compile-time!