[M3devel] Downsides of Modula-3 ?

[Jay K]

I don't understand what LONGADDRESS is either. > >> Bugs in the "standard" threading library (pthreads
> >> based).  Have
> >> to use the longjmp hack version.
1) please elaborate 2) We don't use longjmp as much any more, but get/set/make/swapcontext on platforms that support them.And where we do use longjmp, we have a more portable use than before -- we no longer hack on the jmpbuf.There is a "trick" where you use sigsetstack or some such to get the stack pointer into the jmpbuf.Look at the code and read the paper referenced. It is possible it didn't work on all platforms.  But anyway, see #1.We'd really prefer to just use pthreads.Hm. I'd like to look again at what pthreads features we use -- I suspect pthreads/Win32 can beabstracted more thinly and the Modula-3 code less-forked/more-shared. But later..  - Jay > From: dragisha at m3w.org
> Date: Sat, 21 Apr 2012 23:28:15 +0200
> To: dabenavidesd at yahoo.es
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] Downsides of Modula-3 ?
> 
> What would be LONGADDRESS? Pointer to a location inside LONGRAM? :)
> 
> On Apr 21, 2012, at 6:26 PM, Daniel Alejandro Benavides D. wrote:
> 
> > Hi all:
> > If we accept to exist LONGINT and ADDRESS is a Word.T why we don't have LONGADDRESS? That's you don't care if that's in UNSAFE TYPE, do you?
> > Assembly in lining was handled about perfect in Modula-2 for VMS I wonder why DEC didn't provide Modula-3 support with that as well.
> > Thanks in advance
> > 
> > --- El vie, 20/4/12, Mika Nystrom <mika at async.caltech.edu> escribió:
> > 
> >> De: Mika Nystrom <mika at async.caltech.edu>
> >> Asunto: Re: [M3devel] Downsides of Modula-3 ?
> >> Para: penn43 at gmx.com
> >> CC: m3devel at elegosoft.com
> >> Fecha: viernes, 20 de abril, 2012 15:29
> >> 
> >> Now that I have the rather unpleasant task of writing C code
> >> for a client,
> >> I have a few things I "like" about C and that I "miss"
> >> somewhat when
> >> I write Modula-3.
> >> 
> >> I find that I sort of like the C preprocessor.  But
> >> maybe it's just the
> >> sort of code I'm writing with it... (test programs, which
> >> need lots and
> >> lots of annotations and instrumentation, something easy to
> >> do with cpp).
> >> 
> >> No alloca....
> >> 
> >> No varargs...
> >> 
> >> No real "const" (Java "final").  Sometimes WITH can do
> >> it.
> >> 
> >> No GO TO.............. can't believe I just wrote that but
> >> Modula-3 had
> >> as one of its design objectives to be a good target for code
> >> generation,
> >> and having goto would make that easier!  (Look at the
> >> C-Mix partial
> >> evaluator for an application.)
> >> 
> >> A C++ programmer would undoubtedly miss a lot of crazy C++
> >> stuff 
> >> that lets you do tricky stuff entirely without heap
> >> allocation.
> >> And operator overloading.
> >> 
> >> Then there are some annoying implementation limitations:
> >> 
> >> No EXTENDED floating point in the standard implementation.
> >> 
> >> Bugs in the "standard" threading library (pthreads
> >> based).  Have
> >> to use the longjmp hack version.
> >> 
> >> Dubious "enhancements" relative to the Green Book: LONGINT,
> >> WIDECHAR
> >> (and a lot of issues with TEXT as a result).  And
> >> efficiency problems
> >> in the CM3 code in *some cases* (compared with the older SRC
> >> M3).
> >> 
> >> ----
> >> 
> >> My own evaluation of the above is that the things lacking
> >> relative to C
> >> are really pretty minor and the language is so much easier
> >> to use
> >> and better engineered that you almost never say to yourself
> >> "oh I wish
> >> I could write this procedure in C" (you might say it of one
> >> line of code).
> >> 
> >> The implementation issues are things that could "easily" be
> >> fixed by
> >> someone who had the time..
> >> 
> >> Oh regarding efficiency problems: I still find that CM3 with
> >> optimization
> >> turned on produces code that runs faster and with a far
> >> smaller memory
> >> footprint than code doing the same thing in Java, most of
> >> the time.
> >> That's when you try to do as close to an apples-to-apples
> >> comparison
> >> as possible.  If you take into account the fact that in
> >> Modula-3 you can
> >> allocate structured memory in "batches" (called "arrays"!)
> >> the difference
> >> is even bigger.  Modula-3 also links far easier with C
> >> and Fortran than
> >> Java does.
> >> 
> >>     Mika
> >> 
> >> 
> >> 
> >> penn43 at gmx.com
> >> writes:
> >>> An object appraisal must take into account the problems
> >> too. So I am asking yo
> >>> u, could you please mention any downsides of using
> >> Modula-3, in your experienc
> >>> e?
> >>> 
> >>> Of course, the non-existent language community has
> >> already been mentioned as a
> >>> major downside. 
> >>> And the lack of documentation.
> >>> What about other issues, such as compiler efficiency? Or
> >> interaction with fore
> >>> ign libraries?
> >>> 
> >>> Thanks
> >>> 
> >>> Marresh
> >> 
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120421/72b0c9ce/attachment-0002.html>