Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utcs!mnetor!seismo!caip!nike!ucbcad!ucbvax!sdcsvax!sdcc6!loral!ian
From: ian@loral.UUCP
Newsgroups: net.lang.mod2
Subject: Re: A Long Note on the Trichotomous String Comparison Example
Message-ID: <1194@loral.UUCP>
Date: Fri, 11-Jul-86 15:21:53 EDT
Article-I.D.: loral.1194
Posted: Fri Jul 11 15:21:53 1986
Date-Received: Sat, 12-Jul-86 22:54:20 EDT
References: <12221138454.23.PATTIS@WASHINGTON.ARPA> <422@valid.UUCP>
Reply-To: ian@loral.UUCP (Ian Kaplan)
Organization: Loral Instrumentation, San Diego
Lines: 34

In article <422@valid.UUCP> sbs@valid.UUCP (Steven Brian McKechnie Sargent) writes:
>I've been idly interested in Modula-2 for a little while, especially
>since I admire the author of the decwrl compiler (Michael Powell) as
>a fellow of fine judgement in these matters.  However, given the
>length of discussion required to solve the rather trivial problem of
>string comparison, I'm very concerned!  Perhaps I will delay the
>plunge into strongly typed languages a little longer, and save some
>wear and tear on my keyboard.
>

  Modula has its problems (e.g., no ARRAY of ARRAY of <type> and you
  can't implement printf), but this string compare issue is not a problem.

  The complexity of the string compare function in Modula has nothing
  to do with the fact that Modula is a strongly typed programming language.
  The problem has its roots in the way that most Modula systems implement
  strings.  A string is null terminated, unless it fills the entire
  character array, in which case there is no null.  As we have seen, this 
  means that the string compare code must perform checks to make sure that
  the string arrays are not indexed beyond their bounds.  There is no 
  reason that strings could not be implemented in the "right" way, always 
  null terminated.  As far as I know there is nothing explicit in Wirth's 
  books that disallows this.

  By the way, Michael Powell and his colleagues have fixed a number of 
  Modula's problems in their Modula implementation.

		     Ian Kaplan
		     Loral Dataflow Group
		     Loral Instrumentation
		     (619) 560-5888 x4812
	     USENET: {ucbvax,decvax,ihnp4}!sdcsvax!sdcc6!loral!ian
	     ARPA:   sdcc6!loral!ian@UCSD
	     USPS:   8401 Aero Dr. San Diego, CA 92123