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