Why?
Gary Scott
Pascal Bourguignon
> Why are there no posts in modula3? What is modula3?
Modula-3 is a nice, object oriented, strongly and early typed, system
programming language, inspired from Modula-2 and other languages of
this familly.
I can't say for others, but a few years ago, I've switched to Common Lisp,
which is why I don't usually post here :-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
Paul Vixie
>
> Modula-3 is a nice, object oriented, strongly and early typed, system
> programming language, inspired from Modula-2 and other languages of
> this familly.
yes.
> I can't say for others, but a few years ago, I've switched to Common Lisp,
> which is why I don't usually post here :-)
i switched back to C some years ago, and as much as i'd prefer M3, the fact
that there are two incompatible language variants (CM3, PM3) and that every
OS needs extensive library-level porting to map structures in /usr/include/sys
and that it's not a standard backend for GCC means that it "falls just short"
of my minimum requirements for a development platform.
which is a darned shame. code written in M3 looks like what it does, and does
what it looks like, to a higher degree than in any other language i've ever
used. and unlike CL or C++, it's *fast*. as fast as C in most situations.
what i guess i need is some interns who want to work on "Common Modula-3" as
a single-standard based on GCC4 with intent to make the backend part of GCC.
(there's no formal application process for it yet, just send me some e-mail.)
--
Paul Vixie
Ken Rose
> what i guess i need is some interns who want to work on "Common Modula-3" as
> a single-standard based on GCC4 with intent to make the backend part of GCC.
> (there's no formal application process for it yet, just send me some e-mail.)
That's a good idea, except we need a way for the adults to play too.
You know - those of us who can contribute a few hours a week, but can't
live on an intern's income...
Ah, heck. Let's start now. What are the points of incompatibility
between PM3 and CM3, and how should they be resolved? What should be
added to the language? What should be taken away?
Hopefully,
- ken
Paul Vixie
> what i guess i need is some interns who want to work on "Common
> Modula-3" as a single-standard based on GCC4 with intent to make the
> backend part of GCC. (there's no formal application process for it
> yet, just send me some e-mail.)
Ken Rose <ken...@tfb.com> writes:
> That's a good idea, except we need a way for the adults to play too.
> You know - those of us who can contribute a few hours a week, but can't
> live on an intern's income...
i'm very sure that the current maintainer of PM3/CM3 would welcome all help...
> Ah, heck. Let's start now. What are the points of incompatibility
> between PM3 and CM3, and how should they be resolved? What should be
> added to the language? What should be taken away?
...but since i believe that a "common" M3 would be controversial to many, i
also therefore believe there is no way to get it done "volunteer-style." we
either start up a standards organization with fees and voting and meetings
and delegates, like was done for the various ANSI-C's or the S-100 bus or the
various PCI busses, or somebody Just Does It. lacking the means or expertise
for the former, i'm leaning toward the latter.
i'd love to be found wrong on all counts.
--
Paul Vixie
Olaf Wagner
changes have been committed during the recent months. I think the
situation improves, though slowly:
Paul Vixie wrote:
> i switched back to C some years ago, and as much as i'd prefer M3, the fact
> that there are two incompatible language variants (CM3, PM3) and that every
The (more recent) CM3 compiler has been imtegrated into the PM3 code
distribution quite some time ago; differences between the code
distributions are not really that great. There has been no official
PM3 release though recently, since Elego uses and concentrates on
the CM3 distribution.
> OS needs extensive library-level porting to map structures in /usr/include/sys
> and that it's not a standard backend for GCC means that it "falls just short"
> of my minimum requirements for a development platform.
It's not a standard backend because the FSF people never accepted the
code that circumvented their license IIRC :-( There's currently a
working gcc-3.4 backend though, and work is ongoing on a current gcc 4
backend.
One of the big porting problems, system dependencies due to the need for
memory protection, has been eliminated by extending the code generator
to produce hints for the garbage collector for incremental and
generational collection strategies; so porting to a new platform should
be significantly easier. Indeed it should not need more than a couple
of days to get the system up on a new target platform if all needed
information is available.
Staying up-to-date with respect to OS releases could still be made
much easier by abstracting most of the system specific interfaces
into a standard POSIX layer within the runtime and dealing with some
differences in C code. (Any volunteers for this project? :)
> which is a darned shame. code written in M3 looks like what it does, and does
> what it looks like, to a higher degree than in any other language i've ever
> used. and unlike CL or C++, it's *fast*. as fast as C in most situations.
I can second that. I would also dearly love to see M3 more widely used.
> what i guess i need is some interns who want to work on "Common Modula-3" as
> a single-standard based on GCC4 with intent to make the backend part of GCC.
> (there's no formal application process for it yet, just send me some e-mail.)
We could also try again to contribute the current gcc M3 backend to the
gcc distribution (which would avoid another M3 implementation), but I
think we'd need to name a maintainer for that part. I wouldn't dare to
point at someone for this task :)
Operator
Olaf Wagner <wag...@in-berlin.de> writes:
[...]
> Paul Vixie wrote:
>> i switched back to C some years ago, and as much as i'd prefer M3, the fact
>> that there are two incompatible language variants (CM3, PM3) and that every
>
> The (more recent) CM3 compiler has been imtegrated into the PM3 code
> distribution quite some time ago; differences between the code
> distributions are not really that great. There has been no official
> PM3 release though recently, since Elego uses and concentrates on
> the CM3 distribution.
I'm using PM3 ported by John Polstra on FreeBSD.
Currently there is no maintainer and recently there was a call for
volunteers for unmaintained ports.
Is an upgrade posible if you release the source?
Or is CM3 the prefered dist?
>> [mapping /usr/include/sys and gcc backend]
> [working on backend]
>
> Staying up-to-date with respect to OS releases could still be made
> much easier by abstracting most of the system specific interfaces
> into a standard POSIX layer within the runtime and dealing with some
> differences in C code. (Any volunteers for this project? :)
Umm, is it doable by just using the default cc and /usr/include/sys ?
(and some auto tools)
>> [love M3]
>
> I can second that. I would also dearly love to see M3 more widely used.
/M(e)2 :-)
>> ["Common Modula-3"]
>
> We could also try again to contribute the current gcc M3 backend to the
> gcc distribution (which would avoid another M3 implementation),
That would be nice.
> but I
> think we'd need to name a maintainer for that part. I wouldn't dare to
> point at someone for this task :)
It's not me (yet)
Paul Vixie
> There is still active work on CM3/PM3 ongoing; important and substantial
> changes have been committed during the recent months.
i havn't seen any release announcements on this newsgroup...?
> > i switched back to C some years ago, and as much as i'd prefer M3, the
> > fact that there are two incompatible language variants (CM3, PM3) ...
>
> The (more recent) CM3 compiler has been imtegrated into the PM3 code
> distribution quite some time ago; differences between the code
> distributions are not really that great. There has been no official PM3
> release though recently, since Elego uses and concentrates on the CM3
> distribution.
are there any significant users or codebases in PM3 any more? that is,
could we all just declare CM3 "common" or would elegosoft have to merge in
any bits of PM3 to reach that state? and: why did you integrate CM3 changes
into PM3 if your primary work is on CM3? (this is what makes me wonder if
there are still any significant PM3 users or codebases out there.)
> It's not a standard backend because the FSF people never accepted the
> code that circumvented their license IIRC :-( There's currently a
> working gcc-3.4 backend though, and work is ongoing on a current gcc 4
> backend.
can you say more about the licensing problems? it seems to me that the GPL
more or less rules the GCC world and that there's no place else you can go
with your CM3 back end than into that community. so either you want a more
restrictive license (CDDL?) in which case you're trying to prevent people
from using code away from GCC that would be useless away from GCC, or you
want a less restrictive license (BSD?) in which case just put that one on
and deal with the fact that deltas can only flow in one direction between
your repository and FSF's. i don't like the GPL but i respect its power to
unilaterally set the terms of engagement for the GCC.
> One of the big porting problems, system dependencies due to the need for
> memory protection, has been eliminated by extending the code generator to
> produce hints for the garbage collector for incremental and generational
> collection strategies; so porting to a new platform should be
> significantly easier. Indeed it should not need more than a couple of
> days to get the system up on a new target platform if all needed
> information is available.
*wow* that's huge.
> Staying up-to-date with respect to OS releases could still be made much
> easier by abstracting most of the system specific interfaces into a
> standard POSIX layer within the runtime and dealing with some differences
> in C code. (Any volunteers for this project? :)
i don't know if i'd be qualified to work on that project. can you say more?
> I can second that. I would also dearly love to see M3 more widely used.
that's effectively not going to happen without leveraging the GCC community
which means dealing with their GPL unilateralism. and speaking of wide use,
what does CM3 have or lack with respect to John Polstra's Ezm3?
> We could also try again to contribute the current gcc M3 backend to the
> gcc distribution (which would avoid another M3 implementation), but I
> think we'd need to name a maintainer for that part. I wouldn't dare to
> point at someone for this task :)
what's involved, beyond getting past the licensing issues?
--
Paul Vixie
Roland Illig
> Ah, heck. Let's start now. What are the points of incompatibility
> between PM3 and CM3, and how should they be resolved? What should be
> added to the language? What should be taken away?
If I could decide, I would add a well-defined FOR statement, as described in
http://www.roland-illig.de/articles/modula-3-for-loop.pdf
I had also some thoughts for extending the WITH statement, for example
WITH <Identifier> = READONLY <Expression> DO <Statements> END;
or, as syntactic sugar,
WITH <Identifier> := <Expression> DO <Statements> END;
which would create a new variable <Identifier> and not an alias to
<Expression> if that's an lvalue.
It's about six months ago that I have used Modula-3 for the last time,
so it might be that I don't remember exactly what I had wanted back in
that time. :)
Another thing that makes the language "look old" is the requirement that
all keywords are written in uppercase letters. But apart from this, I
really like the language. And, after some initial problems, I really
liked that feature because it leaves the programmer with the freedom to
use _all_ identifiers that have a lowercase letter in them, which is
very convenient.
Roland
Roland Illig
> Ah, heck. Let's start now. What are the points of incompatibility
> between PM3 and CM3, and how should they be resolved? What should be
> added to the language? What should be taken away?
Another thing I'd like to have in Modula-3 are multi-level namespaces
for modules, just like in Java. This would avoid conflicts between
programs or libraries that define modules of the same, generic name like
"Interval", which hit me once when I implemented a module for closed
interval arithmetics on integers.
Roland
Olaf Wagner
> Olaf Wagner <wag...@in-berlin.de> writes:
>
> i havn't seen any release announcements on this newsgroup...?
There have been no complete official releases recently, nor has the
ongoing work been communicated very well to those who might be
interested. I've just added a pre-announcement for the next CM3
release to http://www.elegosoft.com/cm3/, which contains some
information about the new features.
> are there any significant users or codebases in PM3 any more? that is,
> could we all just declare CM3 "common" or would elegosoft have to merge in
> any bits of PM3 to reach that state? and: why did you integrate CM3 changes
> into PM3 if your primary work is on CM3? (this is what makes me wonder if
> there are still any significant PM3 users or codebases out there.)
Antony Hosking and his research group have implemented their object
persistence work based on PM3.
>>It's not a standard backend because the FSF people never accepted the
>>code that circumvented their license IIRC :-( There's currently a
>>working gcc-3.4 backend though, and work is ongoing on a current gcc 4
>>backend.
>
> can you say more about the licensing problems? it seems to me that the GPL
> more or less rules the GCC world and that there's no place else you can go
> with your CM3 back end than into that community. so either you want a more
> restrictive license (CDDL?) in which case you're trying to prevent people
> from using code away from GCC that would be useless away from GCC, or you
> want a less restrictive license (BSD?) in which case just put that one on
> and deal with the fact that deltas can only flow in one direction between
> your repository and FSF's. i don't like the GPL but i respect its power to
> unilaterally set the terms of engagement for the GCC.
Well, almost all the M3 code is under less restrictive license than the
GPL, which allows you to do more or less anything you want with it
(including commercial use). Only if you pass back changes to the
copyright owners these will be free to do with them what they like.
The problem with the gcc backend was that Digital SRC specified a small
file-based interface which allowed them to put only some lines of C code
under the GPL and avoid the viral license for the rest of the M3 code,
which wasn't very well received by the FSF people, who rejected to
include the backend in their distribution :-(
>>One of the big porting problems, system dependencies due to the need for
>>memory protection, has been eliminated by extending the code generator to
>>produce hints for the garbage collector for incremental and generational
>>collection strategies; so porting to a new platform should be
>>significantly easier. Indeed it should not need more than a couple of
>>days to get the system up on a new target platform if all needed
>>information is available.
>
> *wow* that's huge.
I myself have done several ports of (C)M3 (FreeBSD, DarwinPPC,
LINUX_PPC). The biggest problem was always to get all the needed
information about the target architecture (stack layout etc.).
The second biggest problem was the tedious work to check and
adapt all the (POSIX) Unix interfaces and the system call wrappers
for enhanced garbage collector support (now obsolete).
>>Staying up-to-date with respect to OS releases could still be made much
>>easier by abstracting most of the system specific interfaces into a
>>standard POSIX layer within the runtime and dealing with some differences
>>in C code. (Any volunteers for this project? :)
>
> i don't know if i'd be qualified to work on that project. can you say more?
There are a lot of Unix-system specific interfaces that are called by
various part of the M3 runtime. The current porting strategy is to copy
all the stuff from a similar platform and do all the needed changes for
the new platform. It would be much better if we had a standardzied
POSIX interface layer in m3core (and implement some system adaptions
in C). Most of the Unix support code of the existing target platforms
could made obsolete this way. This project could be started concurrently
to other work by defining and implementing the new POSIX interfaces,
and then converting the existing Unix code target platforms one by
one.
>>I can second that. I would also dearly love to see M3 more widely used.
>
>
> that's effectively not going to happen without leveraging the GCC community
> which means dealing with their GPL unilateralism. and speaking of wide use,
> what does CM3 have or lack with respect to John Polstra's Ezm3?
There are some notes of the CM3 features on
http://www.elegosoft.com/cm3/about-cm3.html
(improved backend, mapping of system level exceptions, implicit
exceptions, etc.) John Polstra actually took a PM3 distribution
and removed everything from it he didn't need for CVSup (including
advanced garbage collection). I don't think EZM3 is the way to go
(though it's a great distribution for compiling CVSup).
>>We could also try again to contribute the current gcc M3 backend to the
>>gcc distribution (which would avoid another M3 implementation), but I
>>think we'd need to name a maintainer for that part. I wouldn't dare to
>>point at someone for this task :)
>
> what's involved, beyond getting past the licensing issues?
Technically, the code could be added very easily to the gcc distribution
I think. It would not contain a complete M3 compiler then, but just an
M3 code generator. Aside from the licensing problems we would probably
have to add some test framework so it can be maintained independently
of the complete CM3 distribution.
Olaf
Olaf Wagner
> In article <4foappF...@individual.net>,
> Olaf Wagner <wag...@in-berlin.de> writes:
> [...]
>>distribution quite some time ago; differences between the code
>>distributions are not really that great. There has been no official
>>PM3 release though recently, since Elego uses and concentrates on
>>the CM3 distribution.
>
>
> I'm using PM3 ported by John Polstra on FreeBSD.
> Currently there is no maintainer and recently there was a call for
> volunteers for unmaintained ports.
> Is an upgrade posible if you release the source?
> Or is CM3 the prefered dist?
The source for both the PM3 and CM3 distributions of Modula-3
is always available from the CVS repositories on
www.elegosoft.com via CVS and CVSup.
Elego has never made a PM3 release due to lack of resources;
anybody willing to do so is welcome, though. All the CM3 releases
have been pushed out by Elego workers (which is always a considerable
effort).
>>>[mapping /usr/include/sys and gcc backend]
>>
>>[working on backend]
>>
>>Staying up-to-date with respect to OS releases could still be made
>>much easier by abstracting most of the system specific interfaces
>>into a standard POSIX layer within the runtime and dealing with some
>>differences in C code. (Any volunteers for this project? :)
>
>
> Umm, is it doable by just using the default cc and /usr/include/sys ?
> (and some auto tools)
I'm afraid not :-( You would need to understand and refactor a fair
amount of M3 code in the m3core library.
Olaf
Paul Vixie
>
> Well, almost all the M3 code is under less restrictive license than the
> GPL, which allows you to do more or less anything you want with it
> (including commercial use). Only if you pass back changes to the
> copyright owners these will be free to do with them what they like.
right. i love that licensing model and i use it all the time. the success
of FreeBSD, NetBSD, X11, Apache, BIND, MIT Kerberos, UDel NTP, etc, are proof
that this licensing model is viable.
> The problem with the gcc backend was that Digital SRC specified a small
> file-based interface which allowed them to put only some lines of C code
> under the GPL and avoid the viral license for the rest of the M3 code,
> which wasn't very well received by the FSF people, who rejected to
> include the backend in their distribution :-(
"viral" is the part i don't understand. if you want some source files to be
shipped as part of GCC, then those files will have to be licensed under GPL.
but, the viral nature of GPL only taints the code that ships with GCC, not
the rest of the CM3 code base (which will not ship with GCC or via FSF.)
so while i can wish that the GCC could include some files with BSD-style
licenses, i don't see how the GPL virus affects CM3 at all. the files you'd
be "giving up" (allowing to be published with a GPL) would still be yours to
publish under some different license if you wanted to. but there's no reason
to want to do that, since they wouldn't be useful outside of GCC. if someone
else improves the files you "give up" to GCC in this way, then their mods
would likely also be available only-under-GPL. those files are just lost to
you, tainted by GPL, etc. but the rest of CM3, which depends only on a GCC
that has those files inside it but does not link to them or include text from
them, would not be tainted.
so, please say more?
> > and speaking of wide use, what does CM3 have or
> > lack with respect to John Polstra's Ezm3?
>
> ... John Polstra actually took a PM3 distribution and removed everything
> from it he didn't need for CVSup (including advanced garbage collection).
> I don't think EZM3 is the way to go (though it's a great distribution for
> compiling CVSup).
so, cvsup will build just fine on CM3, and we have no worries about it
depending on some special feature of PM3 or EZM3. that's good, since it
preserves the possibility of CM3 becoming the standard for M3.
> > what's involved, beyond getting past the licensing issues?
>
> Technically, the code could be added very easily to the gcc distribution
> I think. It would not contain a complete M3 compiler then, but just an M3
> code generator. Aside from the licensing problems we would probably have
> to add some test framework so it can be maintained independently of the
> complete CM3 distribution.
that's all very easy compared to the licensing problems if any. good.
--
Paul Vixie
Olaf Wagner
>>>can you say more about the licensing problems? ...
>>file-based interface which allowed them to put only some lines of C code
>>under the GPL and avoid the viral license for the rest of the M3 code,
>>which wasn't very well received by the FSF people, who rejected to
>>include the backend in their distribution :-(
>
>
> "viral" is the part i don't understand. if you want some source files to be
> shipped as part of GCC, then those files will have to be licensed under GPL.
> but, the viral nature of GPL only taints the code that ships with GCC, not
> the rest of the CM3 code base (which will not ship with GCC or via FSF.)
>
> so while i can wish that the GCC could include some files with BSD-style
> licenses, i don't see how the GPL virus affects CM3 at all. the files you'd
> be "giving up" (allowing to be published with a GPL) would still be yours to
> publish under some different license if you wanted to. but there's no reason
> to want to do that, since they wouldn't be useful outside of GCC. if someone
> else improves the files you "give up" to GCC in this way, then their mods
> would likely also be available only-under-GPL. those files are just lost to
> you, tainted by GPL, etc. but the rest of CM3, which depends only on a GCC
> that has those files inside it but does not link to them or include text from
> them, would not be tainted.
>
> so, please say more?
I don't think anybody in the M3 community sees any problems in putting
all the files in cm3/m3-sys/m3cc/gcc/gcc/m3cg/ which make up the
M3 gcc backend under the FSF license. As far as I remember the FSF
didn't accept the code (long time ago now) because they didn't like
the way the gcc backend was decoupled from the rest of the compiler
(avoiding the tainting of all the rest of the M3 sources with the
license). As I said, all this was now a long time ago, and I wasn't
personally involved, I only heard and read about it. So perhaps it's
time to try again :)
>>>and speaking of wide use, what does CM3 have or
>>>lack with respect to John Polstra's Ezm3?
>>
>>... John Polstra actually took a PM3 distribution and removed everything
>>from it he didn't need for CVSup (including advanced garbage collection).
>>I don't think EZM3 is the way to go (though it's a great distribution for
>>compiling CVSup).
>
> so, cvsup will build just fine on CM3, and we have no worries about it
> depending on some special feature of PM3 or EZM3. that's good, since it
> preserves the possibility of CM3 becoming the standard for M3.
CVSup runs nicely on top of CM3.
Hallvard B Furuseth
> As far as I remember the FSF didn't accept the code (long time
> ago now) because they didn't like the way the gcc backend was
> decoupled from the rest of the compiler (avoiding the tainting
> of all the rest of the M3 sources with the license).
Yes. See <http://gcc.gnu.org/ml/gcc/2000-06/msg00010.html>.
--
Hallvard
Paul Vixie
there's no evidence in that thread that RMS ever ruled on the question,
it's just suppositions as to how things probably would go. and tim mann
is wrong on two critical points: there is forward-compatibility between
M3's BSD-like license and the GPL, just not backward-compatibility. what
i mean by that is, there is nothing in the M3 license which would prohibit
a code fork where the forked code had the M3 license AND the GPL. so, if
FSF wanted M3 they could slap their own license on top of the M3 license
and thus control the rights to their copy.
i think it's time to try again, but i'd like to be the one to try, since
i've fought license wars before and i seem to have a good grasp of the
fine points. but before anyone tries, can we rename the file we want to
donate to FSF, and rename the functionality? if all it's doing it
offering a pipe to the backend, then it's language-independent and not
part of the M3 system at all. can we call it "pipe_to_backend.c" or
something like that? what i'd like to do is reduce the number of
questions posed by the donation down to: does FSF want this functionality
in their compiler?
i also note that in a post-EGCS world, there are more voices than RMS's
who would weigh in on these questions.
--
Paul Vixie
Olaf Wagner
gcc has grown, and so has the m3cg backend, which currently looks like
this (for gcc 3.4.5):
% wc m3-sys/m3cc/gcc-3.4.5/gcc/m3cg/*
1 6 512 m3-sys/m3cc/gcc-3.4.5/gcc/m3cg/CVS
111 435 3316 m3-sys/m3cc/gcc-3.4.5/gcc/m3cg/Make-lang.in
35 197 1246 m3-sys/m3cc/gcc-3.4.5/gcc/m3cg/config-lang.in
40 220 1524 m3-sys/m3cc/gcc-3.4.5/gcc/m3cg/lang-options.h
51 184 1406 m3-sys/m3cc/gcc-3.4.5/gcc/m3cg/lang-specs.h
71 235 1369 m3-sys/m3cc/gcc-3.4.5/gcc/m3cg/lang.opt
108 550 3924 m3-sys/m3cc/gcc-3.4.5/gcc/m3cg/m3-convert.c
323 1269 12190 m3-sys/m3cc/gcc-3.4.5/gcc/m3cg/m3cg.h
4599 14487 120344 m3-sys/m3cc/gcc-3.4.5/gcc/m3cg/parse.c
5339 17583 145831 total
We'll have to check if other changes besides the new m3cg sub-directory
were necessary, and of course we should try to donate the most recent
version (for gcc 4.1), which is not checked in yet. Antony Hosking,
who has done most of the recent gcc integration work, is currently
traveling, but I think you should talk to him directly when he's
back in a few days. There should be no problem with renaming any
offending file or procedure.
Olaf
Andrew Reilly
> gcc has grown, and so has the m3cg backend, which currently looks like
> this (for gcc 3.4.5):
I've just subscribed to c.l.m3: sorry for dredging up the past.
Have any of the modula3 maintainers looked at using the LLVM
infrastructure as a back-end, rather than GCC? Or perhaps emiting ANSI C
as the intermediate form (as Sma{ll,rt}Eiffel and several Scheme
compilers do)?
Further to the "why" question, and without trying to be inflammatory: what
do the M3 afficianados think of Eiffel and Ada (and maybe Oberon), all of
which seem to inhabit approximately the same or similar
object/syntax-flavour/native-code niche (although Ada seems to do it
without garbage collection).
[I do like a lot of what I've seen of Modula-3, and did work in Modula-2
while at University, twenty years ago, but platform independence and tool
availability have always mitigated in favour of C (or native assembler)
during my professional career. I'd love to be able to change that...]
Cheers,
--
Andrew
Tony Hosking
Andrew> I've just subscribed to c.l.m3: sorry for dredging up the past.
No problem!
Andrew> Have any of the modula3 maintainers looked at using the LLVM
Andrew> infrastructure as a back-end, rather than GCC? Or perhaps emiting
Andrew> ANSI C as the intermediate form (as Sma{ll,rt}Eiffel and several
Andrew> Scheme compilers do)?
LLVM would make a fine target for Modula-3, but I don't know what platforms
LLVM currently targets. The wide variety of targets for GCC makes porting M3
relatively straightforward. I expect that emitting C makes source-level
debugging a little trickier -- there is a hacked version of gdb that
understands the debugging information that M3 emits and enables full
source-level debugging of M3 programs.
Andrew> Further to the "why" question, and without trying to be inflammatory:
Andrew> what do the M3 afficianados think of Eiffel and Ada (and maybe
Andrew> Oberon), all of which seem to inhabit approximately the same or
Andrew> similar object/syntax-flavour/native-code niche (although Ada seems to
Andrew> do it without garbage collection).
These are all fine languages. I think M3 has some advantages in the "systems"
space, but my knowledge of these other languages is fragmentary at best.
--
Antony Hosking | Associate Professor
Dept of Computer Sciences | Office: (765) 494-6001
Purdue University | Mobile: (765) 427-5484
250 N. University Street | Email:hos...@cs.purdue.edu
West Lafayette, IN 47907-2066 | http://www.cs.purdue.edu/~hosking
_--_|\
/ \
\_.--._/ )
v /
Riley
Modula-3, at:
http://www.cs.wichita.edu/~rodney/languages/Modula-Ada-comparison.txt
Hendrik Boom
> Why are there no posts in modula3? What is modula3?
Modula 3 discussions seem to have moved elsewhere.
The modula 3 mailing lists are described at http://modula3.elegosoft.com/
cm3/mailing-lists.html
The interesting one seems to be m3devel. See recent archives at
https://mail.elegosoft.com/pipermail/m3devel/ Subscribe to it at
https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
(The site has an invalid security certificate; it's still the right site)
Or look at the wikipedia entry:
http://en.wikipedia.org/wiki/Modula-3
I hope this helps.
-- hendrik