Astrobe Forum

That does not follow. strings are constants character arrays are variables. The same can be said about numbers too (literals versus variables). For every basic type an exported constant can be turned into an exported variable if needed. Unfortunately an exported string cannot be turned into an expo...

That is not correct. Unless I have misunderstood what you are saying I believe you have 'got the wrong end of the stick'. The system is designed to try to prevent you from modifying an element of an exported record variable - that part is working fine. What is a problem is that you can modify an el...

My last reply in this thread seems to have disappeared. Anyway, my standpoint is that the inability to modify an exported field though an exported pointer (as in my example) represents a minor compiler bug. In a typical scenario, however, I imagine that an exported pointer will refer to a record wit...

Consider the following two modules: MODULE M; TYPE T* = POINTER TO RECORD x*: INTEGER END; VAR t*: T; BEGIN NEW(t); t.x := 0 END M. MODULE Client; IMPORT M; PROCEDURE P*; VAR t1: M.T; BEGIN (*this line does not compile...*) M.t.x := 1; (*...however, these do*) t1 := M.t; t1.x := 1 END P; END Client....

OK, you got me, but I am sure you get my point. With the compile-time concatenation procedure all strings can be represented, just as all representable booleans, numbers and sets can be denoted by constant literals. It is a matter of completeness.

i would vote for the introduction of a predefined procedure for (compile-time) string concatenation. This function procedure (with a variable number of parameters) could be named UNION. With this minimal addition to the language all strings can be represented. Like kevinhely, I would also like to se...

If the path in your example is to be exported as a constant, say, it gets a bit more involved if we decide to add quotes. A module like MODULE M; CONST path* = "C:\temp\"; END M. will turn into something like this: MODULE M; CONST quotes = 22X; VAR path: ARRAY 10 OF CHAR; PROCEDURE GetPath*(VAR out:...

Never mind, I found a rather simple solution: In the case of the empty string ("") the scanner can store it as s[0] := 0X; s[1] := 1X to differentiate it from the null string (0X) which is typically stored as s[0] := 0X; s[1] := 0X.

OK, but the scanner does not know about these contexts (CHAR or ARRAY OF CHAR). Although the language was simplified to use only strings, as far as I can tell the scanner still needs two token types (like charString and ordString) so that the parser can tell the empty string ("") from the null strin...

Does the compiler reject the statement
If it does I guess the scanner uses a distinct token type for string ordinals. Otherwise the parser would not be able to tell the empty string from the null string (0X) as both compare equal and are of length zero.