Info about Objective Modula-2?

[Xin Wang]

Site[1] of Objective Modula-2 seems broken, could anyone point me where I can get info about that project?

Basically, I'd like to find a usable Modula-2 compiler without GPL license restriction.

[1] http://objective.modula2.net

[Nemo]

Post by Xin Wang
Site[1] of Objective Modula-2 seems broken, could anyone point me where I can
get info about that project?

The Wayback machine has archives. (For example,
https://web.archive.org/web/20120301214945/http://objective.modula2.net/ .)

Post by Xin Wang
Basically, I'd like to find a usable Modula-2 compiler without GPL license restriction.
[1] http://objective.modula2.net

[trijezdci]

Post by Xin Wang
Site[1] of Objective Modula-2 seems broken, could anyone point me where I can get info about that project?

We have had network issues at the US facility where the modula2.net server was hosted, for extended periods of time, people from outside of North America could not reach the site and they operator didn't seem to get on top of the problem which occurred to be coming and going at random.

We then moved the content to a new domain hosted in Switzerland, but with all focus on implementing M2 R10 and the bootstrap compiler (M2C rewrite) the ObjM2 part seems to have been left out of the move. Thanks for reminding, we'll put it onto the todo list.

Post by Xin Wang
Basically, I'd like to find a usable Modula-2 compiler ...

Note that the code base for the compiler was still experimental and I am not sure it would be useful out of the box without any further work on it. We intend to build a new ObjM2 compiler on the basis of our present work on M2C and M2 R10.

Post by Xin Wang
... without GPL license restriction.

The M2C rewrite is licensed under the LGPL, which only applies copyleft to bug fixes and modifications to the compiler itself but not to any other libraries you integrate it with. For example if you were to build a commercial IDE around it, the IDE can remain closed source and be licensed any way you wish. Only if you made changes to the compiler itself would those changes have to be published, but only that, not any of your own code.

Work on M2C has recently moved to the code generator, DEF units are almost covered, so the end of the tunnel is now in sight.

https://bitbucket.org/trijezdci/m2c-rework/wiki/Home

https://bitbucket.org/trijezdci/m2c-rework/wiki/Language%20Extensions

[trijezdci]

Post by trijezdci
The M2C rewrite is licensed under the LGPL, which only applies copyleft to bug fixes and modifications to the compiler itself but not to any other libraries you integrate it with. For example if you were to build a commercial IDE around it, the IDE can remain closed source and be licensed any way you wish. Only if you made changes to the compiler itself would those changes have to be published, but only that, not any of your own code.

Likewise, if you were to use the M2C front end for your own commercial compiler, using your own middle and back end, the license would allow that, too. The front end falls under copyleft, but your own middle and back end do not.

[Xin Wang]

@Nemo: Thanks, I should have thought of that magic machine. :)

@trijezdci: Thank you for your detailed reply. I'm aware of M2R10 project, really appreciate your work, glad to know that new m2c will be released under LGPL. I'm looking forward to its release.

[trijezdci]

Post by Xin Wang
@Nemo: Thanks, I should have thought of that magic machine. :)
@trijezdci: Thank you for your detailed reply. I'm aware of M2R10 project, really appreciate your work, glad to know that new m2c will be released under LGPL. I'm looking forward to its release.

It seemed to me that you are after Modula-2 in general not necessarily Objective Modula-2.

For object oriented programming style you could well use extensible record types which the new M2C supports. We have a related article on our website.

http://modula-2.info/m2r10/pmwiki.php/Examples/ObjectOrientedProgramming

The object model of Objective Modula-2 is based on that of Objective-C which is a hybrid of Smalltalk and C. This will be interesting when targeting MacOS X and iOS, but perhaps more interestingly for web development based on GNUstep's GSweb which is a clone of the original WebObjects by NeXT.

[Xin Wang]

在 2016年3月14日星期一 UTC+8下午5:08:40，trijezdci写道：

Post by trijezdci

Post by Xin Wang
@Nemo: Thanks, I should have thought of that magic machine. :)
@trijezdci: Thank you for your detailed reply. I'm aware of M2R10 project, really appreciate your work, glad to know that new m2c will be released under LGPL. I'm looking forward to its release.

It seemed to me that you are after Modula-2 in general not necessarily Objective Modula-2.

Yes, I do not care much about OO part, although I think some kind of OO is necessary to easily bind to third-party library interfaces.

Post by trijezdci
For object oriented programming style you could well use extensible record types which the new M2C supports. We have a related article on our website.
http://modula-2.info/m2r10/pmwiki.php/Examples/ObjectOrientedProgramming
The object model of Objective Modula-2 is based on that of Objective-C which is a hybrid of Smalltalk and C. This will be interesting when targeting MacOS X and iOS, but perhaps more interestingly for web development based on GNUstep's GSweb which is a clone of the original WebObjects by NeXT.

It sounds interesting. I have some experience about web programming, it would be nice to be able to use Modula-2 in that field.

[trijezdci]

Post by Xin Wang
Yes, I do not care much about OO part, although I think some kind of OO is necessary to easily bind to third-party library interfaces.

With M2C any interfacing to foreign libraries will be via-C.

For that you do not need any OOP capability. All you need to do is write a Modula-2 definition module for a C library and mark it with the FFI pragma after the module identifier in the module header.

DEFINITION MODULE FooLib (*$FFI="C"*);

If you wanted to interface to OOP languages, you would have to use any C interfaces that those languages may provide. Usually, the direction is the reverse, people interface to C from Java, C# or Python. M2C will make it possible to write libraries in Modula-2 to which these language could then interface via whatever mechanism they use to interface to C. Again, you don't really require OOP there.

However, if you need OOP for whatever other reason, you can use extensible record types and do OOP in the style of Oberon.

Post by Xin Wang

Post by trijezdci
The object model of Objective Modula-2 is based on that of Objective-C which is a hybrid of Smalltalk and C. This will be interesting when targeting MacOS X and iOS, but perhaps more interestingly for web development based on GNUstep's GSweb which is a clone of the original WebObjects by NeXT.

It sounds interesting. I have some experience about web programming, it would be nice to be able to use Modula-2 in that field.

WebObjects was extremely successful before Apple acquired NeXT. By then it had become NeXT's bread and butter business. All the big names used it for web commerce. There is the story of Michael Dell becoming extremely angry about having to move DELL off WebObjects because he couldn't have his business depend on a product made by a competitor but there wasn't any other product that came anywhere close to WO.

The original ObjC based WO combined the flexibility of a dynamic language with the scalability of a compiled static language. This advantage disappeared when Apple foolishly moved WO to Java. However, GSweb still has this advantages by virtue of following the original NeXT WO model.

To my knowledge still no other web framework does this even today, although I am not an expert in this market and do not have a complete overview of what's out there, so I might be wrong. I did look into some of the web frameworks for Lisp and Smalltalk, but unfortunately, by an extremely large margin, they are just not as scalable and efficient. The original WO just utterly destroys them.

ObjC is quite a nice and decent language but it would be so much nicer if it wasn't built on top of C. With ObjM2 we will be able to hook into the NeXT WO model from Modula-2 without having to reinvent and reengineer the web framework. The GNUstep project have already done that. All we need is a Modula-2 front end for it.

http://wiki.gnustep.org/index.php/GNUstepWeb

[Xin Wang]

在 2016年3月14日星期一 UTC+8下午8:04:12，trijezdci写道：

Post by trijezdci

Post by Xin Wang
Yes, I do not care much about OO part, although I think some kind of OO is necessary to easily bind to third-party library interfaces.

With M2C any interfacing to foreign libraries will be via-C.
For that you do not need any OOP capability. All you need to do is write a Modula-2 definition module for a C library and mark it with the FFI pragma after the module identifier in the module header.
DEFINITION MODULE FooLib (*$FFI="C"*);

Is this method capable to describe C types, like `FILE *`, `char *const *`? Current version of m2c uses type casts (e.g. see macros in Files.mod), which I think is quite dirty.

Post by trijezdci
If you wanted to interface to OOP languages, you would have to use any C interfaces that those languages may provide. Usually, the direction is the reverse, people interface to C from Java, C# or Python. M2C will make it possible to write libraries in Modula-2 to which these language could then interface via whatever mechanism they use to interface to C. Again, you don't really require OOP there.

What I thought was that if we target Modula-2 to JVM or browser, it will be easier to interface to Java or Javascript API if Modula-2 have some kind of OO facility.

Post by trijezdci
However, if you need OOP for whatever other reason, you can use extensible record types and do OOP in the style of Oberon.

Post by Xin Wang

Post by trijezdci
The object model of Objective Modula-2 is based on that of Objective-C which is a hybrid of Smalltalk and C. This will be interesting when targeting MacOS X and iOS, but perhaps more interestingly for web development based on GNUstep's GSweb which is a clone of the original WebObjects by NeXT.

It sounds interesting. I have some experience about web programming, it would be nice to be able to use Modula-2 in that field.

WebObjects was extremely successful before Apple acquired NeXT. By then it had become NeXT's bread and butter business. All the big names used it for web commerce. There is the story of Michael Dell becoming extremely angry about having to move DELL off WebObjects because he couldn't have his business depend on a product made by a competitor but there wasn't any other product that came anywhere close to WO.
The original ObjC based WO combined the flexibility of a dynamic language with the scalability of a compiled static language. This advantage disappeared when Apple foolishly moved WO to Java. However, GSweb still has this advantages by virtue of following the original NeXT WO model.
To my knowledge still no other web framework does this even today, although I am not an expert in this market and do not have a complete overview of what's out there, so I might be wrong. I did look into some of the web frameworks for Lisp and Smalltalk, but unfortunately, by an extremely large margin, they are just not as scalable and efficient. The original WO just utterly destroys them.
ObjC is quite a nice and decent language but it would be so much nicer if it wasn't built on top of C. With ObjM2 we will be able to hook into the NeXT WO model from Modula-2 without having to reinvent and reengineer the web framework. The GNUstep project have already done that. All we need is a Modula-2 front end for it.
http://wiki.gnustep.org/index.php/GNUstepWeb

I'm not familiar with ObjC ecosystem, only learn some Smalltalk and Squeak years ago, quite an interesting language.

[trijezdci]

Post by Xin Wang
Is this method capable to describe C types, like `FILE *`, `char *const *`? Current version of m2c uses type casts (e.g. see macros in Files.mod), which I think is quite dirty.

The definition module is simply an interface. As far as the interface is concerned FILE is an opaque type, it is the implementation that knows how it is structured, and that implementation is written in C.

So you would write your interface most likely with an opaque type ...

TYPE FILE;

or in M2 R10 syntax

TYPE FILE = OPAQUE;

For the new M2C I am currently working with a model by which every opaque type definition generates an incomplete type declaration in C, for example

TYPE Foo; (* OPAQUE *)

becomes

typedef foo_s *foo_t;

If the actual implementation is not a record type but say an INTEGER, the new M2C will generate a struct with a single integer field in it. Thus every opaque type is a pointer to a record type. This avoids casting.

If you were to write a library in Modula-2 and provide it as a replacement of a C API, then of course you know the internal structure you implement, so there shouldn't be any need for casting either.

As for C strings, the best practise would be to wrap a C API call into a Modula-2 function that uses ARRAY OF CHAR or CONST ARRAY OF CHAR parameters. This way the unsafe practise of not knowing the length of the passed string is confined to the lowest level that interfaces directly with the C library and everything up uses Modula-2 conventions with safety facilities.

Post by Xin Wang
What I thought was that if we target Modula-2 to JVM or browser, it will be easier to interface to Java or Javascript API if Modula-2 have some kind of OO facility.

Sure, but M2C targets C.

In M2 R10 spec we defined "JVM" and "CLR" as possible values for the FFI pragma. However, this is optional and any implementation of a JVM and/or CLR code generator will be low priority.

Post by Xin Wang
I'm not familiar with ObjC ecosystem, only learn some Smalltalk and Squeak years ago, quite an interesting language.

Roughly speaking, ObjC is like C with an escape syntax for embedding Smalltalk. The practise is to use the C part of the language for flow control and the Smalltalk part for abstraction.

[Xin Wang]

在 2016年3月15日星期二 UTC+8下午7:01:50，trijezdci写道：

Post by trijezdci

Post by Xin Wang
Is this method capable to describe C types, like `FILE *`, `char *const *`? Current version of m2c uses type casts (e.g. see macros in Files.mod), which I think is quite dirty.

The definition module is simply an interface. As far as the interface is concerned FILE is an opaque type, it is the implementation that knows how it is structured, and that implementation is written in C.
So you would write your interface most likely with an opaque type ...
TYPE FILE;
or in M2 R10 syntax
TYPE FILE = OPAQUE;
For the new M2C I am currently working with a model by which every opaque type definition generates an incomplete type declaration in C, for example
TYPE Foo; (* OPAQUE *)
becomes
typedef foo_s *foo_t;

Take FILE for example. If I define FILE as an OPAQUE type, how does it map to FILE type defined in stdio.h?

Post by trijezdci
If the actual implementation is not a record type but say an INTEGER, the new M2C will generate a struct with a single integer field in it. Thus every opaque type is a pointer to a record type. This avoids casting.
If you were to write a library in Modula-2 and provide it as a replacement of a C API, then of course you know the internal structure you implement, so there shouldn't be any need for casting either.
As for C strings, the best practise would be to wrap a C API call into a Modula-2 function that uses ARRAY OF CHAR or CONST ARRAY OF CHAR parameters. This way the unsafe practise of not knowing the length of the passed string is confined to the lowest level that interfaces directly with the C library and everything up uses Modula-2 conventions with safety facilities.

Post by Xin Wang
What I thought was that if we target Modula-2 to JVM or browser, it will be easier to interface to Java or Javascript API if Modula-2 have some kind of OO facility.

Sure, but M2C targets C.
In M2 R10 spec we defined "JVM" and "CLR" as possible values for the FFI pragma. However, this is optional and any implementation of a JVM and/or CLR code generator will be low priority.

Yes, reasonable, C and LLVM is more important for now.

Post by trijezdci

Post by Xin Wang
I'm not familiar with ObjC ecosystem, only learn some Smalltalk and Squeak years ago, quite an interesting language.

Roughly speaking, ObjC is like C with an escape syntax for embedding Smalltalk. The practise is to use the C part of the language for flow control and the Smalltalk part for abstraction.

[trijezdci]

Post by Xin Wang
Take FILE for example. If I define FILE as an OPAQUE type, how does it map to FILE type defined in stdio.h?

M2C generates C output. Thus an include directive can easily be inserted. For that M2C needs to know that this is what we want (pragma FFI) and what the name of the library is (pragma FFIDENT).

DEFINITION MODULE (*$FFI="C"*) CStdIO (*$FFIDENT="stdio"*);

TYPE FILE;

etc

[Xin Wang]

在 2016年3月17日星期四 UTC+8上午3:31:45，trijezdci写道：

Post by trijezdci

Post by Xin Wang
Take FILE for example. If I define FILE as an OPAQUE type, how does it map to FILE type defined in stdio.h?

M2C generates C output. Thus an include directive can easily be inserted. For that M2C needs to know that this is what we want (pragma FFI) and what the name of the library is (pragma FFIDENT).
DEFINITION MODULE (*$FFI="C"*) CStdIO (*$FFIDENT="stdio"*);
TYPE FILE;
etc

Still can not fully understand your idea. Maybe some kind of concrete examples in wiki[1] would be helpful.

[1] https://bitbucket.org/trijezdci/m2c-rework/wiki/Language%20Extensions

[trijezdci]

Post by Xin Wang
在 2016年3月17日星期四 UTC+8上午3:31:45，trijezdci写道：

Post by trijezdci

Post by Xin Wang
Take FILE for example. If I define FILE as an OPAQUE type, how does it map to FILE type defined in stdio.h?

M2C generates C output. Thus an include directive can easily be inserted. For that M2C needs to know that this is what we want (pragma FFI) and what the name of the library is (pragma FFIDENT).
DEFINITION MODULE (*$FFI="C"*) CStdIO (*$FFIDENT="stdio"*);
TYPE FILE;
etc

Still can not fully understand your idea. Maybe some kind of concrete examples in wiki[1] would be helpful.
[1] https://bitbucket.org/trijezdci/m2c-rework/wiki/Language%20Extensions

The FFIDENT pragma is not yet on the wiki because this isn't on the radar yet. It will be documented before implementation, but first the code generator has to be working, pragmas will come after that.

In a nutshell, the FFI pragma tells the compiler that the module is a foreign function interface. The FFIDENT pragma maps Modula-2 identifiers to foreign API identifiers. In the case of a module identifier, the mapped foreign identifier is the name of the foreign library.

Consequently

DEFINITION MODULE (*$FFI="C"*) CStdIO (*$FFIDENT="stdio"*);

provides sufficient information to insert

#include <stdio.h>

into the generated source.

For this we will have to define a list of header names of the C standard library within the compiler, so as to distinguish when to use quotes (#include "foo.h") and when to use angular brackets (#include <foo.h>). Alternatively, this could be incorporated into the pragma.

Once the include directive is inserted, then all the definitions of stdio.h are available within the output C source, including FILE. The Modula-2 opaque type definition is simply there to satisfy the M2 type system, because a type that hasn't been defined/declared nor imported cannot be used in M2.

[Xin Wang]

在 2016年3月17日星期四 UTC+8下午12:30:12，trijezdci写道：

Post by trijezdci

Post by Xin Wang
在 2016年3月17日星期四 UTC+8上午3:31:45，trijezdci写道：

Post by trijezdci

Post by Xin Wang
Take FILE for example. If I define FILE as an OPAQUE type, how does it map to FILE type defined in stdio.h?

M2C generates C output. Thus an include directive can easily be inserted. For that M2C needs to know that this is what we want (pragma FFI) and what the name of the library is (pragma FFIDENT).
DEFINITION MODULE (*$FFI="C"*) CStdIO (*$FFIDENT="stdio"*);
TYPE FILE;
etc

Still can not fully understand your idea. Maybe some kind of concrete examples in wiki[1] would be helpful.
[1] https://bitbucket.org/trijezdci/m2c-rework/wiki/Language%20Extensions

The FFIDENT pragma is not yet on the wiki because this isn't on the radar yet. It will be documented before implementation, but first the code generator has to be working, pragmas will come after that.
In a nutshell, the FFI pragma tells the compiler that the module is a foreign function interface. The FFIDENT pragma maps Modula-2 identifiers to foreign API identifiers. In the case of a module identifier, the mapped foreign identifier is the name of the foreign library.
Consequently
DEFINITION MODULE (*$FFI="C"*) CStdIO (*$FFIDENT="stdio"*);
provides sufficient information to insert
#include <stdio.h>
into the generated source.
For this we will have to define a list of header names of the C standard library within the compiler, so as to distinguish when to use quotes (#include "foo.h") and when to use angular brackets (#include <foo.h>). Alternatively, this could be incorporated into the pragma.
Once the include directive is inserted, then all the definitions of stdio.h are available within the output C source, including FILE. The Modula-2 opaque type definition is simply there to satisfy the M2 type system, because a type that hasn't been defined/declared nor imported cannot be used in M2.

Got it! Thanks.

[trijezdci]

Post by Xin Wang
Got it! Thanks.

Note that some of the finer details still need to be worked out.

For example, the FFIDENT pragma could be made to understand "<stdio.h>" when used in a module header.

(*$FFIDENT="<stdio.h>"*)

In that case, the compiler would know to use #include <stdio.h> instead of #include "stdio.h". This would avoid the need to hardcode a list of standard library header names into the compiler.

Alternatively, the FFI pragma could be given a second parameter to indicate that we are dealing with an interface for the standard library.

(*$FFI="C", "stdlib"*)

But since there is also a stdlib.h, perhaps that might not be as intuitive to a human reader as it could and should be. However, it would serve the same purpose.

Or, maybe there is yet a better idea how to convey this information to the compiler.

This kind of finer detail has yet to be determined. We get to it when it becomes acute.

However, the general direction is to use pragmas for this. If you stripped the pragmas out, the remaining source code should look as if the library was all in Modula-2. Thus, if you wanted to replace the C library you interface to, you could use the same interface, remove the pragmas, add your own Modula-2 implementation and rebuild your project.