Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 (Tek) 9/26/83; site tekecs.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!houxm!hogpc!houti!ariel!vax135!cornell!uw-beaver!tektronix!orca!tekecs!patcl
From: patcl@tekecs.UUCP
Newsgroups: net.lang.mod2
Subject: Re: strings in Modula-2
Message-ID: <3973@tekecs.UUCP>
Date: Sun, 19-Aug-84 01:56:44 EDT
Article-I.D.: tekecs.3973
Posted: Sun Aug 19 01:56:44 1984
Date-Received: Wed, 15-Aug-84 00:35:30 EDT
Organization: Tektronix, Wilsonville OR
Lines: 35

>> ...The C style of strings (ie null terminated).
>> could be easily be implemented, as well as the dynamic type.  To solve
>> the literal string problem you only need a routine (LiteralString?) to
>> stuff the constant into the right structure.

This doesn't solve the problem. The problem was not that literal
strings and other (dynamic) strings cannot be used together --
certainly the programmer can explicitly provide the code, as
a routine or inline, to copy values from one type of structure into
another type of structure. The problem was how to avoid making the
programmer do this, in the case of general library modules to support
a varying-size string type. And it *is* a problem, because the
programmer has to potentially code in this explicit conversion
at *every* library routine call.  A general
"concatenate(s1, s2: string; VAR result: string)"
illustrates the point. Certainly I'd like either s1, or s2, or both,
to take either literal string constants, or string variables, as
argument values. In C, there's no problem; an address is generated
either way. To handle this situation in Modula-2, "string" must be
ARRAY OF CHAR (or some user-defined array of char type), and yet the
actual arguments to which s1 and s2 and result are bound must
always of some *fixed size* array type (yes, I know, I could pass
an open array declared in an enclosing procedure -- but that simply
moves the problem to the next outer level). Since the result of
a concatenate might be used as an input string sometime later, I end up
declaring a maximal-sized string type and using it for all string
variables at the outer level. What I would really *like* to do is
have the ability (in the library module code) to dynamically allocate
memory for result strings, and then return these dynamically created
strings in such a way that they are compatible with all other
strings -- currently not possible in Modula-2.

Pat Clancy
Tektronix
{ucbvax,decvax,ihnp4,allegra,uw-beaver,hplabs}!tektronix!tekecs!patcl