[M3devel] Think we need a new release.

[Daniel Alejandro Benavides D.]

Hi all:

To be honest, to make a language change (and of course I'm looking forward but respecting and acknowledging and respecting the path that brigs here) I'm not involved I'm not interested (so I realize your concern).
That's why, you know, I mentioned that we need to care about some issues so whoever comes later (in some time sadly or not many of our brains will be with more decades and some other will take that job of making it better this) will do it rightly.
Although I seem not care about us in the future I understand that we need more than a language revision (I'm not saying changes or update), we need:
1) Make the best effort we can (even that means some money) to try to recover design meetings, since there is already some bits in the SPWM3, I would like to recover the damaged tapes, if they ever really are somewhere and make the effort to at least recover the most of it. This to preserve that for posterity. I don't care more than if they are lost forever
2) Define Languages changes without experimenting makes no sense, so my thinking is that we need to implement gradually baby Modula-3 and start from there a serious (although painful) top down language definition according to the same rules defined or at least type compatible. If that needs human revision or machine learning I guess we would do that.
3) Whatever conclusion is taken a path of action will follow so anyone can always return to the point 1) until some agreement is made between all people.


Thanks in advance

--- El lun, 13/2/12, vintagecoder at aol.com <vintagecoder at aol.com> escribió:

> De: vintagecoder at aol.com <vintagecoder at aol.com>
> Asunto: Re: [M3devel] Think we need a new release.
> Para: m3devel at elegosoft.com
> Fecha: lunes, 13 de febrero, 2012 09:06
> Hello Daniel,
> 
> > Agreed.  I can think of two reasons: adding "must
> have" stuff to the
> > standard library, and fixing bugs or improving library,
> compiler, or
> > runtime.  Note that "must have" should probably be
> evaluated in the
> > context of systems programming, which is what Modula-3
> is for.
> 
> For myself I tend to be very careful when it comes to "must
> have" in
> language design. If you feel the language spec is outdated
> or insufficient,
> then I think it's a dangerous, slippery slope to start
> adding features to
> the language even if they are a must have, without a
> standards committee.
> If people are not careful, they can turn a language that was
> designed well
> into a junk heap before they know it. The threat to the
> death of a language
> through inappropriate changes is far greater than the threat
> of death by
> lack of changes.
> 
> If people agree the current spec is not sufficient, or
> wrong, it seems to
> me the first step is to form a language specification
> committee where the
> language can be carefully controlled- and this has to be
> from a purist
> view of the language with no concern for implementation and
> no "baggage"
> other than the existing language spec has to be respected-
> all the changes
> have to be aligned and harmonious with the original purpose
> and intentions
> and direction of Modula-3, otherwise what you said later
> about a new
> language comes into play. Optional features have to be
> clearly optional-
> extensions to the standard that don't make sense in the core
> have to be
> clearly deliniated and the spec has to be amended cleanly to
> separate core
> language, optional extensions, etc. The Ada specification is
> a good
> document to look at for examples of how to do this.
> 
> > Even adding new platforms should not require bumping
> the version number
> > if it is the existing infrastructure that is being
> ported.
> 
> Agreed.
> 
> > There are loads of "greatest next thing" languages out
> there that you
> > have to re-learn every few releases.  Modula-3 is
> thankfully not one of
> > them.
> 
> Agreed!
> 
> > Want new stuff in the language?  Then you want
> Modula-3+ or Modula-4.
> 
> Agreed again!
> 
> People are so used to constant turmoil because of Linux. I
> come from a much
> different background and I value stability and evolution,
> not revolution.
> New is not necessarily good just like old is not necessarily
> bad. Good
> things pass the test of time and don't need constant
> changes. If we are
> talking about changing the underlying implementation without
> changing the
> language then of course this is fine and should not be held
> back. My
> concern is about letting the implementation drive the
> specification- I feel
> that is wrong, dangerous, and should be resisted.
> 
> Many languages today are out of control. To grow a language
> properly is an
> extremely big challenge that has to be taken with a great
> deal of respect
> and concern.
>