[net.lang.mod2] strings in Modula-2

bobc@teltone.UUCP (Bob Campbell) (08/11/84)

>> for a given string to really change size dynamically,
>> one must either declare a string type which is large enough
>> to hold any expected string value,
...
>> string type is to use NEW/ALLOCATE and pointers, in which
>> case these "dynamic" strings will be incompatible with literal strings
>> (which are ARRAY OF CHAR), so the whole thing is very ugly.
>> True dynamic array types would be one solution.
	
The points made are true, but one must remember that Modula-2 is not a
generic do it all language.  The language was made with the intent that
these functions could be added with modules.  Perhaps there is no standard
group of string handling functions because there are too many different
methods of handling them.  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.



If you really want true dynamic strings with out any effort use icon,
snobol, basic(yuck), lisp(dynamic memory in general), logo,
Ada (tm US Dept. Of Defense) or some such language.

As soon as we get modula-2 for our pyramids I will do some expermenting
with strings and modula-2  (I am currently trying to get icon for the
pyramids also.  Any leads would be gladly excepted) 

Bob Campbell
Telco-Software at Teltone Corp.  Kirkland Washington.

...uw-beaver!teltone!tikal!bobc
(tikal is the name of a American Pyramid)
...uw-beaver!teltone!bobc

patcl@tekecs.UUCP (08/19/84)

>> ...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