Modula, Oberon or Ada

[valdir.marcos]

But it's the way it is. This project is developed by users in their free time. People follow their interests (e.g. Florian improving the optimization, Jonas implementing the LLVM backend, me playing around in the parser).

And me being a pain in the collective backside of the core developers for the last 15 years or so :-)

At least since 06/02/02:
https://groups.google.com/forum/#!topic/comp.lang.modula2/DmRsV52YLb8
or is this the recruitment ? :-)
Afaik we came onto c.l.m2 about the same time (1994-1995 ?), and you might have submitted bugs/comments to my xtdlib library. So that would make it 25 years already :-)

Modula-2 product hits 400 thousand copy mark
https://groups.google.com/forum/#!topic/comp.lang.modula2/DmRsV52YLb8

For those who have already used Modula, Oberon or Ada.
Do those programming languages have any interesting features that Free Pascal currently doesn't?

[marcov]

For those who have already used Modula, Oberon or Ada.
Do those programming languages have any interesting features that Free Pascal currently doesn't?

From memory, Modula2 was basically an incompatible continuation of Pascal, and had

• A better block structure. Omits begin for all non procedure/function blocks, and makes END mandatory (also for one line blocks).
• inner modules (nested units), which more or less served as a information hiding building block within a module/unit.
  
• Opague pointer type. You could declare something in the interface as (geneneric) pointer, and redefine the pointer as a pointer to some record in the implementation. Great for handle types.
• FOR had a BY clause.
• Some interesting runtime library concepts that are however dated now 
  •         textwindowing unit, more than Crt, less than FV
  •         a cooperative multitasking unit
• case sensitivity. Not an advantage IMHO
•   unsigned types by default (jury is still out on this one too)
• End 'procedurename'  at the end of a block. A mixed blessing, made refactoring code more complicated, but "missing end"  kind of errors were less confusing. I think a distinct procedural END is a good thing, but recycling the procedurename a bridge too far.

But above all I really missed a decent way of handling strings. M2 string handling was too manual for my taste. I changed to FPC in 1998, but kept maintaining the old codebases till 2001-2003, when I move to win2000, first at work, later at home, and the dos binaries started very slow under windows 2000, so I ported the code to FPC.

Oberon was a minimalistic OOP follow up to Modula2, and IMHO too limited to function.

Ada's story is different and more distinct from the real Wirthian languages.  Best read up in wikipedia or so.

[MarkMLl]

For those who have already used Modula, Oberon or Ada.
Do those programming languages have any interesting features that Free Pascal currently doesn't?

In the case of Modula-2, coroutines. A coroutine is in-thread, you can transfer control from one coroutine to another at any point and then later revert to where you left off. At least some implementations also had IOTransfer() which could be hooked onto a physical interrupt, and those together are enough to write a scheduler.

The other obvious thing was IF THEN END and IF THEN ELSE END etc. which, while not quite as elegant as Pascal syntax, did eliminate the dangling else issue.

Unfortunately ALGOL's inline conditional a := IF b THEN c ELSE d;, which I consider to be an unfortunate omission from Pascal etc., is at least visually inconsistent with this.

Modula-2 reserves braces { } to delimit a set of elements, and insists on (* *) (which were originally digraphs for braces) for comments. It also allows both single and double quotes for strings so that you could write e.g. "Wirth's Modula-2" (in some other stuff I've done I've allowed quote format to be extended and for quoted strings to carry additional info around with them, so that e.g. / / can be used to delimit a string to be treated as a regex when comparisons are involved, or as a backref if encountered as an rvalue.

There were undoubtedly other things which were standardised as part of the language rather than being de-facto facilities defined by the implementation. LOOP EXIT END springs to mind.

MarkMLl

[MarkMLl]

A better block structure. Omits begin for all non procedure/function blocks, and makes END mandatory (also for one line blocks).

Taken from ALGOL-68, not in ALGOL-W. I've already commented about Wirth and the ALGOL-68 standardisation process.

inner modules (nested units), which more or less served as a information hiding building block within a module/unit.

Pioneered by Brinch Hansen.

Some interesting runtime library concepts that are however dated now 

•         textwindowing unit, more than Crt, less than FV
•         a cooperative multitasking unit

Not sure those were in the language, either as defined by Wirth or in the later (ISO?) standard. Might have been TopSpeed-specific, although coroutines were in the language.

The water is a bit muddied here by stuff that I think Wirth brought back to Europe from PARC, which were later sold by Logitech (e.g. a mouse toolkit which was the first time I'd seen the source of an input event message handling loop).

case sensitivity. Not an advantage IMHO

Arguable. Even if it's not mandatory, I'd like a way of enforcing it purely to improve documentation etc.

unsigned types by default (jury is still out on this one too)

Note that both signed integers and unsigned cardinals were supported.

End 'procedurename'  at the end of a block. A mixed blessing, made refactoring code more complicated, but "missing end"  kind of errors were less confusing. I think a distinct procedural END is a good thing, but recycling the procedurename a bridge too far.

Note that at least some ALGOL-60 implementations treated everything after END as a comment, allowing the procedure name to be put there even if it wasn't checked.

But above all I really missed a decent way of handling strings. M2 string handling was too manual for my taste. I changed to FPC in 1998, but kept maintaining the old codebases till 2001-2003, when I move to win2000, first at work, later at home, and the dos binaries started very slow under windows 2000, so I ported the code to FPC.

I think that M2 strings were /defined/ as being zero-terminated. Can't remember whether they were based on element zero, but they were basically arrays of chars rather than having special handling.

Oberon was a minimalistic OOP follow up to Modula2, and IMHO too limited to function.

Agreed, from what little I know of it. I'd add that as I understand it there's also an Oberon GUI environment which still has its enthusiasts, but the real successor to M2 was M3 etc.

Ada's story is different and more distinct from the real Wirthian languages.  Best read up in wikipedia or so.

Agreed. Also Ada mandated that there could not be any language subsets and that a substantial "workbench" should accompany the compiler, and it was those that made it sufficiently large that it didn't fit onto an affordable PC.

MarkMLl

[marcov]

inner modules (nested units), which more or less served as a information hiding building block within a module/unit.

Pioneered by Brinch Hansen.

I always thought they were a bit overly stylistic, and I never really used them/had a use for them. That said, I'm not that big on information hiding other than some basic level between modules. IMHO it is a good concept that is often take way too far.

Some interesting runtime library concepts that are however dated now 

•         textwindowing unit, more than Crt, less than FV
•         a cooperative multitasking unit

Not sure those were in the language, either as defined by Wirth or in the later (ISO?) standard. Might have been TopSpeed-specific, although coroutines were in the language.

It is the book (by N. Wirth, but a Dutch translation) about the standard, but it says it is not part of the standard. But many compilers had them. (terminal, (text)window(ing) etc). I liked the TS Window module.

It describes coroutines exclusively in the context of standard procedures. (no language enhancements for them, so could be purely library). Correct me if I'm wrong, it has been a while since I did anything with that.

The water is a bit muddied here by stuff that I think Wirth brought back to Europe from PARC, which were later sold by Logitech (e.g. a mouse toolkit which was the first time I'd seen the source of an input event message handling loop).

The book lists that too, modules Terminal, FileSystem, InOut, RealInout, Windows, TextWindows, GraphicWindows, CursorMouse, Menu, Storage, Mathlib0. 

case sensitivity. Not an advantage IMHO

Arguable. Even if it's not mandatory, I'd like a way of enforcing it purely to improve documentation etc.

Use formatters or IDEs, doesn't belong in a language. The old joke was that Wirth simply wanted twice the amount of one digit variables.

unsigned types by default (jury is still out on this one too)

Note that both signed integers and unsigned cardinals were supported.

In retrospect, maybe I understood it wrong at the time. In Pascal, signed being default means that mixed expressions get promoted to the signed integer that is a superset of both, so that the full range is supported.

Maybe it matters less in M2 what default is because it does not allow mixing of integer types (and likewise real types) like Pascal and C do. You need to explicitely cast and thus indicate the calculation type.

But above all I really missed a decent way of handling strings. M2 string handling was too manual for my taste. I changed to FPC in 1998, but kept maintaining the old codebases till 2001-2003, when I move to win2000, first at work, later at home, and the dos binaries started very slow under windows 2000, so I ported the code to FPC.

I think that M2 strings were /defined/ as being zero-terminated. Can't remember whether they were based on element zero, but they were basically arrays of chars rather than having special handling.

Afaik the only special handling was assignment of literals to array of chars even if sizes mismatched. The convention was zero terminated except when the length of the string matched the size of the allocation, then it was  _not_ zero terminated.    But static arrays only.

In assembler it was repne scasb iirc. with cx the size of the allocation. If it ran to completion, it was the non zero terminated case, if it didn't, there was a zero termination and the remainder in cx gave the position from the back.

Oberon was a minimalistic OOP follow up to Modula2, and IMHO too limited to function.

Agreed, from what little I know of it. I'd add that as I understand it there's also an Oberon GUI environment which still has its enthusiasts, but the real successor to M2 was M3 etc.

Yeah.  The M3 compilers I saw were sad, so I mostly ignored that language.

[MarkMLl]

It describes coroutines exclusively in the context of standard procedures. (no language enhancements for them, so could be purely library). Correct me if I'm wrong, it has been a while since I did anything with that.

Coroutines were definitely a fundamental part of the language. They did a lot of stack etc. manipulation that isn't really suitable for putting in a library... I forget how I managed it but I mapped coroutine transfers directly onto x86 call/jump gates.

case sensitivity. Not an advantage IMHO

Use formatters or IDEs, doesn't belong in a language. The old joke was that Wirth simply wanted twice the amount of one digit variables.

Modula-2 was the first language Wirth had worked on which was effectively guaranteed to have a full ASCII character set. The sequence of tools which culminated with ALGOL-W was roughed out on a Burroughs mainframe which had a 6-bit (64-character) character set, Pascal tried to be portable including (as somebody mentioned a day or so ago) to CDC systems which basically had a 64-bit character set plus multiple escapes to extend it. And while that was going on luminaries such as Xerox PARC were still using ASCII-63, which had a left-arrow rather than an underscore.

Afaik the only special handling was assignment of literals to array of chars even if sizes mismatched. The convention was zero terminated except when the length of the string matched the size of the allocation, then it was  _not_ zero terminated.    But static arrays only.

In assembler it was repne scasb iirc. with cx the size of the allocation. If it ran to completion, it was the non zero terminated case, if it didn't, there was a zero termination and the remainder in cx gave the position from the back.

The x86 string instructions are surprisingly similar to the much-maligned string instructions on the Burroughs B5000 of 15 years earlier. Much-maligned since if used incautiously an unprivileged user could trample over memory he didn't oughter.

MarkMLl

[winni]

Hi!

I worked in the 80s and 90s some years with Modula II.

Marcovs  list is nearly complete but one point was the main reason that Modula was developed: The modules!

In the original Wirth Pascal and in Turbo Pascal including version 3 you had no modules aka units or libraries. So you got only ONE Pascal file - and a horrible bunch of include files.

That was the reason why UCSD Pascal introduced the libraries and was delivered with the system.library. Turbo Pascal had "stolen" that concept and introduced it in version 4.

So N. Wirth recognized that it was high time to implement the module concept.

The other changes are more or less cosmetic.

Two disadvanteges should be mentioned:

The separation of interface and implementation in two files complicates the coding and leads to the search for a good but small multi file editor (joe, EVE) (we were in the 80s!).

And the introducing of the case sensivity was an idiotic idea. As Pascal man who was not used to it it gave me hundreds of unnecessary compiler runs.

The coroutines were definitly a big step but seldom used in those times.


Winni

PS: Untyped vars you could do with an undocumented trick already in UCSD Pascal.

This was allowed by the compiler:

Code: Pascal  [Select][+][-]

1. Procedure DemoUntyped(x,y: integer; var z );

[marcov]

Yes, but not just modules, some other functionality (like open array parameters) are now already in FPC too.

Depending on compiler, the interface of the units (definitions of the modules in M2 talk) are sometimes stored tokenized. But afaik not as complete symbolic streams as TP, Delphi and FPC do.

I didn't feel as strong about the separation of files, but I've mostly used during the nineties and always used IDEs, and used joe only for small potato programming (and even joe can open multiple files). With more grown up IDEs like Lazarus that have syntactic source navigation (codetools), it is even less pronounced

The M2 compilers that I knew were spending more time in parsing DEF files than in actually compiling code. That is a C disease, but in M2 it was unnecessary. Going back to TP (for a brief while before migrating to FPC) felt as a blessing.


Another big difference ( and one I like to see in FPC someday) is more control over what identifiers are imported and exported (un)qualified.

This both in the module definition, you can e.g. say that symbol X from unit Y is ALWAYS exported qualified (so you must always write Y.X to use it. Imagine that X is a very common word, like "write" or "seek", and you see the point)

.. as in the module/program importing the module. So a program can chose to import all symbols of module Y qualified only. (so you must always use Y.).  You can also import some symbols unqualified (so that they are accessible without modulename prefix)

What I didn't like is that there is no equivalent of USES to mass import symbols unqualified.

One of the reasons to implement it in Pascal is because afaik some similar functionality is in the Extended Pascal (1990) standard.

[marcov]

Apropos UCSD, I got this to compile last weekend:

https://www.wirth-dijkstra-langs.org/index.html

My fixed version: http://www.stack.nl/~marcov/files/p6-fpc.zip

[winni]

Hi!

And as mentioned the string handling unit was lousy. Here:
https://www.modula2.org/reference/isomodules/isomodule.php?file=STRINGS.DEF

The first thing we did with Modula II was to port our homebrew StringUtils and the TaDunit (Time and Date unit) from Stride Micro (Reno Nevada) from UCSD to M2.

There was not even a Trim (aka Strip aka EatSpaces) in M2!

@markov:  Now I know what to do on christmas: P6 .....!

Winni

[marcov]

@markov:  Now I know what to do on christmas: P6 .....!

If you want to see what I was up to using M2, see e.g. http://www.stack.nl/~marcov/xtdlib100.zip  Well, probably more asm than M2, but still :-)

One of the things I did most with M2 was parsing logfiles, so to speedup I had quite some string and datetime routines in assembler.

[PascalDragon]

• FOR had a BY clause.

Which reminds me that I wanted to take a look at this old feature request again. 

[MarkMLl]

@winni: do you know anything about the history of modularisation, specifically what was in the original Modula? Brinch Hansen's modules weren't cross-file IIRC, if anything they were more a groping towards OO than anything else.

I'm ambivalent on separate .def and .mod files, but I think that the important thing was that the definition modules were precompiled and consistency was protected by makefile-like timestamp checking. A colleague presented a paper where this was used to good effect in a "software hut" teaching environment, with definition modules written by different teams and then shuffled around- something which would have been far more difficult to enforce with untimestamped  include files.

I'm a little bit vague on the history of separate compilation, but I think it entered the mainstream with the IBM S/360 in the mid-60s. I don't think that Burroughs had anything directly comparable at the time, although they did have a way of including "libraries"- large chunks of source- in a compilation from tape or (later) disk. And Burroughs- I think- gave us the whole idea of dollar cards... and UC San Diego at one time had one of their mainframes.

Going back to M2... in principle you shouldn't need to have the definition module open in an editor, since once written and compiled it shouldn't be changed. One of the M2 successors took that a stage further and was able to brand modules as being permitted to do questionable things, and obviously messing around with that should be a senior developer's decision even if most implementation coding was being done by somebody less skilled. Quite frankly I think I'd like to see more of this sort of thing: "this unit has some pointer arithmetic in it and MUST NOT be fooled with by junior staff".

OTOH, I was once working on a disc sector display program where various display units bid depending on how confident they were that they could handle the format. What I really wanted there was a single definition module and multiple implementation modules, or failing that an include file in the definition module... neither of which the language implementations provided and in one case I hit a compiler limit (possibly TopSpeed v1, and it was something like the total number of procedures defined in the entire population of definition modules).

MarkMLl

[guest64953]

Just to remind I found this project is the Oberon equivalent of Free Pascal: https://github.com/kekcleader/FreeOberon It's even listed by the FSF: https://directory.fsf.org/wiki/Free_Oberon

[MarkMLl]

Just to remind I found this project is the Oberon equivalent of Free Pascal: https://github.com/kekcleader/FreeOberon It's even listed by the FSF: https://directory.fsf.org/wiki/Free_Oberon

There's also apparently people working on the operating system aspect of Oberon.

I don't know to what extent these are praiseworthy endeavours, unless they're also actively being used to teach newcomers to the profession (which for a long time was the objective of MINIX, as one particular example). Oberon (the language) dates back to when people looked at Ada and considered it too big and complex, but by today's standards 1980s Ada is probably rather svelte and feature-deficient.

MarkMLl