5 ms·

I just implemented a parser based on the Lisa Pascal 3 specification (see https://github.com/rochus-keller/LisaPascal https://github.com/rochus-keller/LisaPasca

by Rochus 4y ago

I just implemented a parser based on the Lisa Pascal 3 specification (see https://github.com/rochus-keller/LisaPascal https://github.com/rochus-keller/LisaPascal) and started to analyze the published Lisa source code. So far I only saw two of the ~350 Lisa OS source files looking like Clascal (both from the Lisa toolkit). Lisa Pascal has quite a lot of essential features not present in original Pascal; an important one for system programming is the possibility to take the address of things which was not possible with original Pascal.

musicale 4y ago
> an important one for system programming is the possibility to take the address of things which was not possible with original Pascal I believe with (unsafe, packed) case variant records you could often get the address of anything that was allocated on the heap: ... type ptrAddr = packed record case Integer of 0: (addr: Integer); 1: (ptr: ^Something); end; var p: ptrAddr; var somethingPtr: ^Something; begin new(somethingPtr); { allocate a Something } p.ptr = somethingPtr; { copy its pointer } writeln('Allocated something at', p.addr); ... (Apologies for any errors - I don't write Pascal very often and haven't tested this.) This obviously relies on implementation-specific behavior such as integers and pointers being the same size. With this sort of trickery you can do all sorts of (unsafe) things including pointer arithmetic, custom memory allocators, garbage collectors, (unsafe) type casts, (unsafe) low-level memory and memory-mapped I/O access, etc..
- Rochus 4y ago
  There were indeed loopholes in variant records you could misuse for all kinds of tricks, and Wirth was aware of these and finally replaced the concept by type extension. Instead of "not possible" I should better have stated "not officially supported". My point was instead, that Lisa Pascal added concepts, which were official part of the language specification, from which we can conclude, that (also) from the view of Apple original Pascal was not suited for the endeavor. Others came to the same conclusion (see e.g. the famous paper by Kernighan), and even Wirth added features similar to the ones found e.g. in Lisa Pascal to his Modula-2 language.
  - musicale 4y ago
    If you want to pick nits, many C and C++ programs and OS kernels also rely on technically undefined and implementation/machine-specific behavior. From which I suppose we can conclude that C/C++ without undefined and/or implementation-specific behavior has been found to be unsuitable for systems programming. Or that systems programs tend to be non-portable by nature. Perhaps a more charitable conclusion is that languages like Wirth Pascal and K&R C (for example) contain (sometimes explicit and intentional) loopholes and unsafe/technically undefined behavior which can be useful for systems programming but problematic for memory safety and security/reliability. Sadly Pascal standardization seems to have stalled after ISO Extended Pascal in 1991, while C is still evolving into C23.
    - Rochus 4y ago
      All languages have loopholes; even Oberon has at least one, in the type case statement (uncovered by C. Szyperski).
  - musicale 4y ago
    > from which we can conclude, that (also) from the view of Apple original Pascal was not suited for the endeavor Another conclusion might be that Apple started with UCSD Pascal (which was available for the Apple II and already included extensions to standard Pascal) and that they thought that certain extensions were useful even if they weren't technically necessary. Clearly the Lisa didn't need Clascal or Object Pascal (the Macintosh didn't require them), but they provide advantages in terms of conciseness, modularity, reusability, etc..
musicale 4y ago
> I just implemented a parser based on the Lisa Pascal 3 specification cool! > So far I only saw two of the ~350 Lisa OS source files looking like Clascal (both from the Lisa toolkit) Have you looked for instances of SELF in the Lisa Toolkit and app sources? Anything that is SELF.foo is a Clascal instance variable or instance method reference in a method. You can also use with SELF do... to make it more implicit like C++ or Java. Also look for METHODS OF, SUPERSELF, CREATE, etc..
- Rochus 4y ago
  I'm still troubled by the fact that I don't have implemented the preprocessor yet and the code is cluttered over hundereds of .txt files with diverse content (i.e. many modules are parceled to several .txt files). But from what I have seen so far some units in the Lisa_os seem indeed to be Clascal (estimated 5%).
  - musicale 4y ago
    It appears that the Lisa OS kernel is primarily straight Pascal and that Clascal is mainly used in the toolkit and apps (which are of course the most interesting bit of the Lisa.)
- Rochus 4y ago
  Please also note that I'm talking about the Lisa OS (subfolder LISA_OS in the source code ZIP), not the Lisa Toolkit (subfolder Lisa_Toolkit in the source code ZIP). It's actually not a surprise I see some Clascal files in the Lisa OS tree since LIBTK in LISA_OS/LIBS is apparently just a copy of the Lisa Toolkit.

by Rochus 4y ago

musicale 4y ago

> an important one for system programming is the possibility to take the address of things which was not possible with original Pascal I believe with (unsafe, packed) case variant records you could often get the address of anything that was allocated on the heap: ... type ptrAddr = packed record case Integer of 0: (addr: Integer); 1: (ptr: ^Something); end; var p: ptrAddr; var somethingPtr: ^Something; begin new(somethingPtr); { allocate a Something } p.ptr = somethingPtr; { copy its pointer } writeln('Allocated something at', p.addr); ... (Apologies for any errors - I don't write Pascal very often and haven't tested this.) This obviously relies on implementation-specific behavior such as integers and pointers being the same size. With this sort of trickery you can do all sorts of (unsafe) things including pointer arithmetic, custom memory allocators, garbage collectors, (unsafe) type casts, (unsafe) low-level memory and memory-mapped I/O access, etc..

Rochus 4y ago
There were indeed loopholes in variant records you could misuse for all kinds of tricks, and Wirth was aware of these and finally replaced the concept by type extension. Instead of "not possible" I should better have stated "not officially supported". My point was instead, that Lisa Pascal added concepts, which were official part of the language specification, from which we can conclude, that (also) from the view of Apple original Pascal was not suited for the endeavor. Others came to the same conclusion (see e.g. the famous paper by Kernighan), and even Wirth added features similar to the ones found e.g. in Lisa Pascal to his Modula-2 language.
- musicale 4y ago
  If you want to pick nits, many C and C++ programs and OS kernels also rely on technically undefined and implementation/machine-specific behavior. From which I suppose we can conclude that C/C++ without undefined and/or implementation-specific behavior has been found to be unsuitable for systems programming. Or that systems programs tend to be non-portable by nature. Perhaps a more charitable conclusion is that languages like Wirth Pascal and K&R C (for example) contain (sometimes explicit and intentional) loopholes and unsafe/technically undefined behavior which can be useful for systems programming but problematic for memory safety and security/reliability. Sadly Pascal standardization seems to have stalled after ISO Extended Pascal in 1991, while C is still evolving into C23.
  - Rochus 4y ago
    All languages have loopholes; even Oberon has at least one, in the type case statement (uncovered by C. Szyperski).
- musicale 4y ago
  > from which we can conclude, that (also) from the view of Apple original Pascal was not suited for the endeavor Another conclusion might be that Apple started with UCSD Pascal (which was available for the Apple II and already included extensions to standard Pascal) and that they thought that certain extensions were useful even if they weren't technically necessary. Clearly the Lisa didn't need Clascal or Object Pascal (the Macintosh didn't require them), but they provide advantages in terms of conciseness, modularity, reusability, etc..

musicale 4y ago

> I just implemented a parser based on the Lisa Pascal 3 specification cool! > So far I only saw two of the ~350 Lisa OS source files looking like Clascal (both from the Lisa toolkit) Have you looked for instances of SELF in the Lisa Toolkit and app sources? Anything that is SELF.foo is a Clascal instance variable or instance method reference in a method. You can also use with SELF do... to make it more implicit like C++ or Java. Also look for METHODS OF, SUPERSELF, CREATE, etc..

Rochus 4y ago
I'm still troubled by the fact that I don't have implemented the preprocessor yet and the code is cluttered over hundereds of .txt files with diverse content (i.e. many modules are parceled to several .txt files). But from what I have seen so far some units in the Lisa_os seem indeed to be Clascal (estimated 5%).
- musicale 4y ago
  It appears that the Lisa OS kernel is primarily straight Pascal and that Clascal is mainly used in the toolkit and apps (which are of course the most interesting bit of the Lisa.)
Rochus 4y ago
Please also note that I'm talking about the Lisa OS (subfolder LISA_OS in the source code ZIP), not the Lisa Toolkit (subfolder Lisa_Toolkit in the source code ZIP). It's actually not a surprise I see some Clascal files in the Lisa OS tree since LIBTK in LISA_OS/LIBS is apparently just a copy of the Lisa Toolkit.