Search found 54 matches

by augustk
Wed Feb 01, 2012 4:36 pm
Forum: Oberon Language
Topic: Exported pointer variables
Replies: 15
Views: 54617

Re: Exported pointer variables

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...
by augustk
Wed Feb 01, 2012 4:06 pm
Forum: Oberon Language
Topic: Exported pointer variables
Replies: 15
Views: 54617

Re: Exported pointer variables

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...
by augustk
Tue Jan 31, 2012 7:22 pm
Forum: Oberon Language
Topic: Exported pointer variables
Replies: 15
Views: 54617

Re: Exported pointer variables

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...
by augustk
Mon Jan 30, 2012 3:11 pm
Forum: Oberon Language
Topic: Exported pointer variables
Replies: 15
Views: 54617

Exported pointer variables

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....
by augustk
Wed Oct 05, 2011 6:48 pm
Forum: Oberon Language
Topic: Further revision of Oberon-07
Replies: 26
Views: 108972

Re: Further revision of Oberon-07

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.
by augustk
Mon Oct 03, 2011 8:37 pm
Forum: Oberon Language
Topic: Further revision of Oberon-07
Replies: 26
Views: 108972

Re: Further revision of Oberon-07

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...
by augustk
Sat Oct 01, 2011 10:54 am
Forum: Oberon Language
Topic: Further revision of Oberon-07
Replies: 26
Views: 108972

Re: Further revision of Oberon-07

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:...
by augustk
Fri Sep 23, 2011 10:39 pm
Forum: Oberon Language
Topic: Further revision of Oberon-07
Replies: 26
Views: 108972

Re: Further revision of Oberon-07

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.
by augustk
Fri Sep 23, 2011 8:25 pm
Forum: Oberon Language
Topic: Further revision of Oberon-07
Replies: 26
Views: 108972

Re: Further revision of Oberon-07

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...
by augustk
Thu Sep 22, 2011 3:38 pm
Forum: Oberon Language
Topic: Further revision of Oberon-07
Replies: 26
Views: 108972

Re: Further revision of Oberon-07

Does the compiler reject the statement

Code: Select all

ch := ""
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.