[M3devel] new target? :)

[Mika Nystrom]

In general I don't disagree with anything you say.

On Linux, BSD, et al., we obviously use C for low-level system-specific
stuff because the system call interfaces on those systems are documented
for C and not for other languages.

As for OSes in M3 I wasn't thinking as much about SPIN as about Topaz.
Ok so it was Modula-2+, but it was the direct inspiration for the
Modula-3 project: you're supposed to be able to write device drivers
and such things in Modula-3.  I agree though that targeting C doesn't
directly weaken the case for M3 as a systems programming language.

There are more similarities between C# and M3 than "unsafe".  Look at
the way methods are overridden in C#... (compared to Java).  I also think
almost everyone who had anything to do with M3 at DEC is now at Microsoft.

     Mika

Jay K writes:
>--_4e7f3be7-1b6e-44e9-92a2-cc8c4f6b0b8c_
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: quoted-printable
>
>
>When you write that system that doesn't have the support of any C compiler=
>=2C sure=2C go ahead and
>write a backend just for it=2C and maybe a linker=2C and rewrite the small =
>parts that depend on C and Posix in some
>sort of native way -- including writing all the underlying stuff.
>=20
>=20
>Getting Modula-3 working on that system will be a relatively small task=2C =
>compared to whatever else
>   is needed to build the system.
>=20
>Note for example=2C we can't e.g. open files in Modula-3=2C w/o underlying =
>Win32 or Posix functionality.
>  Everywhere that varies for Win32 vs. Posix would have to be revisited in =
>this hypothetical system.
>=20
>=20
>This has little/no bearing on the vast vast vast vast majority of real worl=
>d systems.
>The current Modula-3 system is NOT implemented entirely in Modula-3.
>It MUST depend on SOMETHING.
>So far=2C for the vast vast vast vast vast majority of systems=2C that some=
>thing is written in C=2C
>and has a C runtime=2C compiler=2C and linker.
>=20
>=20
>Yes=2C I've heard of SPIN.
>=20
>=20
>You know..how are you actually going to network I/O or keyboard I/O or powe=
>r management
>or video I/O or mouse I/O or sound I/O or preemptive multi-processor schedu=
>ling?
>You need device drivers. You need a processor-specific context switcher.
>i.e. you need a kernel and you need C AND/OR you need to do a lot of work.
>=20
>=20
>If you consider that our system is already forked along Win32 and Posix lin=
>es=2C you can consider
>these hypothetical systems a third (fourth=2C fifth=2C etc.) fork. A third =
>(fourth) implementation
>of threading. A third implementation of file I/O. A third implementation of=
> Trestle. etc.
>=20
>=20
>But this has little/no bearing how we should target existing real systems.
> You can say=2C not that "Modula-3 depends on C (runtime=2C compiler=2C lin=
>ker)"=2C but that "Modula-3 on Linux=2C NT=2C *BSD=2C Solaris=2C Darwin
>depends on C (runtime=2C compiler=2C linker)"=2C and there's absolutely not=
>hing wrong with that=2C as C and C++
>are well supported on those systems and always will be. Increasing that dep=
>endency=2C on those systems=2C is fine.
>=20
>=20
>It would be nice to port the integrated backend to lots more systems=2C and=
> to write our own linker.
>But not easy.
>And notice how the integrated backend also has the worst debugging story of=
> the two/three options=2C currently.
> (I say three options because m3cg kind of has two modes=2C one is incomple=
>te and currently disabled=2C
>  the other requires m3gdb).
>=20
>=20
>One problem I see here=2C is that=2C you kind of sort of maybe forseeable w=
>ant a backend that outputs Java or C#.
>  C# particularly for Windows Phone 7/Nokia.
>  Java kind of for Android=2C where Java is preferred over C/C++.
>=20
>=20
>i.e. there are systems that sort of lack C and C++. Not that they replace i=
>t with Modula-3 though.
>=20
>=20
>However this isn't super easy=2C like if you are to include the existing m3=
>core/garbage collector.
>C# is optionally safe. I don't know if it would serve as a good target.
>  (Optional safety imho makes C# among one of the closest languages to Modu=
>la-3. It is
>  missing "compile to native"=2C but that maybe is a good thing.)
>In addition=2C C# and Java do each compile down to one well documented "obj=
>ect" file format=2C
>so maybe skipping the text is probably sensible. Esp. since with C# there a=
>re in-proc libraries for codegen.
>=20
>=20
>More likely=2C if a Java/C# target were really needed=2C it'd include forki=
>ng within m3core=20
>and replace the garbage collector. This is all highly specuative stuff.
>=20
>=20
> - Jay
>