Re: Fixes for GNU Sather 1.2.2

[Michael R. Taylor]

----- "Sather User" <address@hidden> wrote:
...

> My laptop is 64-bit today.  Why does it make no sense?
> 
> No code changes are required in Sather programs.  Existing binaries,
> unless they have static linking, won't run on Linux x86_64.
> Recompiled with a compiler that has my patches, they will.  They may
> have greater arithmetic precision, but that will rarely be a problem.
> Shouldn't be at all.  I can't see that your "backwards-compatibility"
> argument makes sense.
> 
> The reason 1.2.3 went with 32bit INTs was because, when you compiled
> 1.2.2 on x86_64, make test reported an integer overflow, and you
> found
> a one or three line work-around that replaced longs with ints.

Binaries won't, no one said that.  Existing source will, and should, run with 
the same expected outcome on 32 or 64 bit.  That was the reason the test was 
created.  When the test fails, it's a regression.  Check out "Software 
Regression" on Wikipedia.  I don't have any time today to look up any better 
material on the subject.
 
> > happen in GNU Sather 2.0 when code breakage is more expected.  It
> 
> Oh.  I didn't know any GNU Sather 2.0 was planned.  You didn't
> mention
> in when referring to your plans in response to my first post.  You
> said, "I would be interested in helping to modernize GNU Sather if
> there is some interest."  When did you last discuss and take feedback
> on your GNU Sather 2.0 plans in a GNU Sather mailing list?  How does
> it relate to the 1.3 betas?
> 
> My second, replacement, set of diffs leave 32-bit Sather code totally
> unchanged.  Nil changes.  Apart from fixes to existing broken code.
> Still, you'd better leave them alone.  "Code breakage", you know.
> 
> > looks like it will be one of the first changes towards 2.0 (along
> > with removing the ALL_CAPITAL class requirement).  One decision
> that
> 
> Have you considered the discussion in comp.lang.sather concerning the
> decision to make class names all-capital?  Do you reject the reasons
> stated by Stephen Omohundro, the inventor of the Sather programming
> language?  What are your credentials to do that?
> 
> Is there any actual reason to do it?

I am familiar with the reasons for ALL_CAPS class names.  The decision was made 
long ago and the way people program today is different.  I'm not sure what you 
mean by "credentials to do that".  You don't need any credentials to make 
changes to Free Software.  That is the beauty of Free Software.  You should 
read http://www.gnu.org/philosophy/why-free.html if you are not familiar with 
Free Software and the GNU Project.

However, like I previously said, I am open to discussion on the issue.  You 
give the reason of readability, but that was mostly an issue when 
text/programmer's editors weren't in color and didn't have code completion 
abilities.  I don't think it is good to ignore these advances made in 
programming environments.  I also think that leaving the base classes as 
ALL_CAPS and letting people implement their own classes without that 
restriction would make for a good way for people to separate classes that are 
included with the compiler from 3rd party classes.

> Are you being guided by the whinges of mere spectators, C programmers
> with no commitment to Sather, who don't like change, haven't made the
> change, from the C-language aesthetics they are familiar with?  You
> need to be careful of people who shout criticisms from 100 paces.
> 
> Typing convenience?  When there is only one class name per entire
> class, and when reading convenience, perspicuity, easy readability,
> easily keeping your bearings when reading the code (not Omohundro's
> reason, just a point that occurs to me now) is hugely more important?

I think you might be a little paranoid. :)  Typing convenience should not be 
overlooked, especially, like I mentioned above, when modern programming 
environments make the readability argument moot.

> And this trifle, a gratuitous change to something that works well, is
> the epoch-making change which will define 2.0?  The only one that you
> can think of to mention?

No, it was just the quickest to type about.

> > needs to be made is whether GNU Sather 2.x releases should have
> > 64bit INTs or C long INTs.  There are pros/cons to either.
> 
> Okay, what are the pros and cons?  There is no such issue.  How has
> it
> arisen in your mind?  Again, the decision was made by the language
> designer, and I've already, in a recent message, mentioned an obvious
> reason why they have to be the size of C longs.  "64bit INTs"?  What
> are you talking about?
> 
> The decision has been made.  You are the maintainer.  Maintain it!

I program on many different architectures everyday, so I probably should have 
been clearer.  C longs, and C ints, are different sizes on different 
architectures.  Their sizes can't be assumed to be the same on two different 
computers.  That's what I meant by 64bit INT.  What I was saying was:  should 
GNU Sather "hide" the architecture precision differences from the programmer, 
so that the programmer doesn't need a bunch of #ifdefs.  Much the way Java does.

> > If you don't use GNU Sather, you might be on the wrong mailing
> 
> I don't use GNU Sather because it has been degraded by gratuitous,
> showy but useless, changes made by GNU maintainers.  The most
> disgusting to me, though I can understand that others would think it
> unimportant, was the change of the name of the executable, from "cs"
> to "sacomp".
> 
> Yes, I'm on the wrong mailing list.  Will unsubscribe very soon, and
> leave you in peace.

That line of mine was meant as a joke, I think you took it much harder that I 
was expecting.  However, I think you are over-exaggerating the changes made 
since GNU took over maintaining Sather.  The naming change is documented in the 
source code.  It was made because of fear of namespace conflicts.  That seems a 
valid reason.
 
> > list, but your input is still appreciated.  About the licensing:
> GNU
> > Sather is a part of the GNU system, and as such follows the GNU
> > software standards as much as possible.  The ICSI code was donated
> > to GNU and with it ICSI allowed the license change.  Since then, it
> > has always been GPL-ed.  The original GNU Sather license is
> > compatible with converting to GPL v3.
> 
> You are absolutely correct.  However my own development is based on
> the Sather-1.2b release, not on the later Sather-1.2b-gpl release.
> Sather-1.2b was released before it was donated.  When I make changes,
> the changes are not automatically GPL'd, and I specifically adhere to
> the original Sather license.  You can say that all the code of
> Sather-1.2b was subsequently donated, but you can't say that about
> development based on Sather-1.2b.
> 
> If I post fixes to this mailing list, I place them under the GPL.  I
> don't mean that that is automatic, I mean I specifically give that
> authority.
> 
> I was only saying that marks of my adherence to the Sather license
> might have remained in my diffs, specifically, comments with my
> initials, and that you are authorized to remove them.

I understood.  I'm certainly not a lawyer, but most of the legal knowledge I do 
know, I learned from free software licenses. :)
 
> Michael, I hope I didn't set out to attack you, but IMHO your message
> does not bear serious scrutiny.  All I could find in it was excuses
> to
> do nothing.  There is a huge amount of work to be done on GNU Sather.

I've given reasons for all the changes I've made.  Your reason appears to be 
"My laptop is 64-bit today." and that "they have to be the size of C longs".  
Either you are unaware of the differences in precision of C longs on different 
platforms, or you are OK with GNU Sather having multi-precision "INT"s.  I 
don't think that is OK (especially since GNU Sather doesn't have a 
pre-processor that can handle the #ifdefs that arise from that situation).  The 
Sather v1.1 spec says of INTs "Immutable objects which represent efficient 
integers. The size is defined by the Sather implementation but must be at least 
32 bits."  The GNU Sather INT is 32 bits and meets that specification.  C long 
is not mentioned at all.

IMHO your message does not bear serious scrutiny.  Do you really want to bring 
platform-dependent code into Sather programs?

> Something as simple and easy as an install target is missing. 
> pSather
> platforms are in disrepair and the 1.2.3 Makefile has:
> 
> > #PLATFORMS=linux,linux/lwp,linux_at,linux_at/smp
> >
> > PLATFORMS=linux
> 
> Why is the pSather PLATFORMS line commented out, when most personal
> computers on the market today are dual core?
> 
> The total concentration on Linux indicated by those lines is
> unfortunate and unnecessary, when you have access to a GNU compile
> farm.  But, okay, given that, why won't linux/lwp and linux/smp
> compile in 1.2.3?
> 
> There is much in connection with pSather that needs documentation.
> Get it working on Solaris, Solaris 5 if possible, read the headers,
> and document them and the programs, how it all works.  Write with a
> view to assisting your successors with the information they will need
> to do fresh ports to Linux and BSD, to keep them working when other
> things change.
> 
> There is so much real work to be done that you should be hard at it.
> You should be able to say something intelligent about what you are
> doing or plan to do, rather than fancifully waffling about Sather 2.0
> in the never-never, using the prospect of it as an excuse to do
> nothing; and about how you are going to over-rule Berkeley academics
> on int versus long, and class name capitalization, things that are
> working today as they designed and implemented them.

"over-rule Berkeley academics"?  I think you are making that a bit dramatic.  
Where are these "Berkeley academics"?  This isn't a closed-source project.  It 
would be great to get some patches from them.  For instance, fixes for pSather, 
like you mentioned above.  I've given my reasons for the INT issue and 
capitalization above.  I listen to input, but you've only given "input" from 
the late 1980s (ICSI Berkeley) with no mention of how those reasons are still 
valid today.  Sometimes the road less traveled, is less traveled for a reason.

You can hardly criticize my work on GNU Sather, or tell me how hard I should be 
working on it.  I can't afford the time/money required for a PR campaign to 
make Sather more popular, to get the developers required to make all the 
necessary changes to GNU Sather.  So I work on the stuff that I think is most 
important.

> Regards,
> Mike
> 
> -- 
> Michael Talbot-Wilson

-- Michael R. Taylor