Re: Portability Considerations

[Alice Osako]

    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.