Search found 54 matches
- Wed Feb 01, 2012 4:36 pm
- Forum: Oberon Language
- Topic: Exported pointer variables
- Replies: 15
- Views: 95178
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...
- Wed Feb 01, 2012 4:06 pm
- Forum: Oberon Language
- Topic: Exported pointer variables
- Replies: 15
- Views: 95178
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...
- Tue Jan 31, 2012 7:22 pm
- Forum: Oberon Language
- Topic: Exported pointer variables
- Replies: 15
- Views: 95178
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...
- Mon Jan 30, 2012 3:11 pm
- Forum: Oberon Language
- Topic: Exported pointer variables
- Replies: 15
- Views: 95178
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....
- Wed Oct 05, 2011 6:48 pm
- Forum: Oberon Language
- Topic: Further revision of Oberon-07
- Replies: 26
- Views: 181565
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.
- Mon Oct 03, 2011 8:37 pm
- Forum: Oberon Language
- Topic: Further revision of Oberon-07
- Replies: 26
- Views: 181565
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...
- Sat Oct 01, 2011 10:54 am
- Forum: Oberon Language
- Topic: Further revision of Oberon-07
- Replies: 26
- Views: 181565
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:...
- Fri Sep 23, 2011 10:39 pm
- Forum: Oberon Language
- Topic: Further revision of Oberon-07
- Replies: 26
- Views: 181565
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.
- Fri Sep 23, 2011 8:25 pm
- Forum: Oberon Language
- Topic: Further revision of Oberon-07
- Replies: 26
- Views: 181565
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...
- Thu Sep 22, 2011 3:38 pm
- Forum: Oberon Language
- Topic: Further revision of Oberon-07
- Replies: 26
- Views: 181565
Re: Further revision of Oberon-07
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.
Code: Select all
ch := ""