Re: Portability Considerations

[Christoph Schlegel]

Alice,

the academic, the perfect technical, the purist view and so on always
let us feel unsure because of all the good arguments against keeping to
do, what we are doing. Meanwhile very often I said to myself at a
certain point: I'll stop the discussion to invest the time for my
project. As long as I have fun and know why I am doing... Some but not
all are coding for the perfect world.

There's a working compiler with great support, a language worth a go -

Keep up your interesting work.

Regards,
Christoph


> Benjamin Kowarsch:
> > On Sat, 16 Mar 2024 at 15:36, Alice Osako wrote:
> >
> >     As for PIM, now that I have a better idea of its history and
> >     limitations, I am entirely willing to write Wirth's book - in
> > all editions - off as a legacy standard. It is no more relevant to
> > new code
> >     in Modula-2 than K&R C or Ada-83 would be for new code in those
> >     languages. I can understand that it is very important for
> > compiler support, or to someone maintaining existing PIM code, but
> > for something
> >     written today it seems like a peculiar thing to be concerned
> >     about. Am I
> >     wrong in thinking this way?
> >
> >
> > Well, ISO is as much a legacy standard as PIM.  
> 
> Is there a more recent promulgated standard, then? One supported by
> the GCC implementation?
> 
> > As far as the core language is concerned there are only a few
> > things in ISO that improved over PIM, notably
> >
> > * delimiters for pragmas separate from those for comments
> > * support for structured constants other than sets, called
> > structured value constructors
> > * making the control variable of a FOR loop explicitly undefined 
> > outside of the loop's body
> > * making unsafe type transfer explicit by introducing a CAST
> > function to module SYSTEM
> >
> > and that's about it. Pretty much all other modifications to the
> > core language made things worse.
> >  
> I am not so well versed in the language at this time to judge how the 
> ISO changes made things worse. Can you give me some examples of this?
> 
> > The bigger issue with PIM was the absence of a standard library.
> > But although ISO provides a standard library, it is
> > over-engineered. It is overly complex and thus difficult to teach
> > and cumbersome to use.  
> 
> Again, I am not familiar enough with the library to judge.
> 
> > Even so, it doesn't cover much of the functionality needed in our
> > day and age.  
> 
> That is inevitable in a language which hasn't been updated in 30
> years, to be sure. The lack of modern libraries is exactly what led
> me to this point.
> 
> > Yet, if you have to supply your own library anyway, then you might
> > as well write one for PIM, or portably for PIM and ISO.
> > In any event, writing portably usually leads to cleaner code and
> > fewer bugs, regardless of the language used. This is so because
> > writing portable code typically requires the use of abstraction
> > layers and design the API from a functional point of view.  
> 
> I agree, but only to a point. While it is certainly true that a
> better designed API results in better client code, writing a library
> for portability generally leads to significantly less clear internal
> code, as it invariably means the use of special cases, and often
> means applying conditional compilations and/or separate versions of
> the library for separate circumstances.
> 
> While better use of abstraction layers internally can mitigate this,
> it doesn't avoid it - at best it can isolate the non-portable
> sections more carefully. While this is worthwhile
> 
> More importantly, you can only write a program to be cleanly portable
> to a system/compiler/dialect you know exists. While the Modula-2
> ecosystem isn't a particularly large one, there have been several
> competing compilers on the market in the past, each with their own
> libraries and idiosyncrasies.
> 
> The alternatives are clear - either support one specific environment, 
> and make it clear that you are doing so, or else support as many as
> you can, again making it clear that it might not portable to
> non-supported environments. The latter is certainly preferable, but
> is it really practical?
> 
> > There is also the aspect of reputation. You put your code into a 
> > public repository with some kind of open source license and
> > eventually somebody may use it with a different compiler and/or
> > different dialect.  
> 
> True, but as I said earlier, it is impossible to predict all of the 
> possible environments someone might try to use a program in. One can
> try to support as many environments as possible, but not everything.
> 
> > Some of the troublespots I have mentioned have the nasty property
> > of being syntactically compatible but semantically incompatible.
> > This means, if somebody uses the code on a different compiler, for
> > a different dialect or a different target, it may seem to work,
> > until it doesn't.  
> 
> That's a valid point, yes, but also inevitable when dealing with 
> multiple compilers and library implementations.
> 
> > And whose reputation do you think is on the line then? The one who 
> > tweaked it to compile on a different compiler/dialect/target or the 
> > original author?  
> 
> The original author, of course.
> 
> However, given that this was intended as a support library for 
> particular use case of my own, it leads me to ask if it should be
> public at all, or if it would be better to make the repo private. I
> don't want to do that, if my code could be useful for others, but at
> the same time I have no expectation of maintaining this indefinitely.
> I have no particular commitment to Modula-2 as a language - I am
> primarily a Lisper, and was undertaking this mainly as an interesting
> stretch of my skills in a language I had been curious about since the
> 1980s - and don't see this as something which very many people even
> within the Modula-2 community would have much interest in. Am I wrong
> about that?
> 
> Given the lack of UNICODE support in the language itself (especially
> the lack of string literal support), a UNICODE library is of only
> limited use. I am writing this for a specific purpose, and I am not
> certain if it would be of general applicability.
> 
> I was posting on this mailing list mainly to get support in using
> gm2, not for general language support, though as you know I certainly
> have needed that as well. I wasn't even aware of the discrepancies
> between the different standards when I first posted here. My
> knowledge of Modula-2 is still fairly limited; the only reason I made
> the repos public was because that is the default on GitHub, and I
> kept them public to facilitate getting outside help.
> 
> As far as I was aware when I started this project, gm2 was the only 
> Modula-2 compiler in active support, and I was frankly surprised that 
> even that was the case when I heard about it - I hadn't done anything 
> with the language before in part because every other Modula-2
> compiler I'd ever heard of was an expensive commercial product that
> hadn't been updated since the 1990s. I now know that this isn't the
> case, but I hadn't known that when I began this trek. However, far
> from simplifying matters, this just makes it more complicated.
> 
> The sum of all this is leading me to question whether to proceed at
> all.