Re: Portability Considerations

[Gaius Mulley]

Benjamin Kowarsch <trijezdci@gmail.com> writes:

> Our Modula-2 revision is a modern language derived from PIM4 with
> Oberon-style extensible records replacing variant records, unnecessary
> and outdated features removed and modern features added to increase
> expressive power without increasing the footprint of the core
> language. To avoid balkanisation it provides means to bind library
> functions to built-in syntax and thereby elevate user defined types to
> first class status. It also defines interfacing to C, the JVM and
> CLR. Unfortunately, our compiler is still work in progress as this is
> an unfunded pet project on which we can only work sporadically. Gaius
> has pledged support in GM2, which is likely to appear in a "one
> feature at a time" manner.

yes indeed - the order of implementation is likely to be:

  (a) wide set (re-implementation) using runtime libraries rather than
      large hand created GCC trees.
  (b) inlining module via an attribute.
  (c) extensible records and indeterminate record types.
  (d) READ/WRITE etc and the m2r10 module concept

so far I've almost completed (a) and will shortly reuse the
devel/modula2 branch to track this progress.  The wideset library
implementation is similar to both (Benjamin and Alice) of your set
libraries - except using ARRAY OF BYTE as the set type.  Currently the
compiler will build and will generate buggy a.out's :-)

> Perhaps it is noteworthy that we have an agreement with Springer for a
> fifth edition of Wirth's "Programming in Modula-2" based on our core
> language definition and thus this is poised to become PIM5. Springer
> wanted to keep the same structure as in the previous editions with two
> parts, (1) a tutorial part and (2) a language report part, where Rick
> was to write/edit the former, and I the latter.

that is really great - it would be super to have a PIM5 book available

regards,
Gaius

On Sun, Mar 17, 2024 at 9:00 AM Benjamin Kowarsch <trijezdci@gmail.com> wrote:
>
>
>
> On Sun, 17 Mar 2024 at 16:47, Benjamin Kowarsch wrote:
>
>>>
>>> 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.
>>
>>
>> It wouldn't be of general applicability in using Unicode within PIM/ISO 
>> Modula-2 source text itself, for that the dialects would need to support 
>> Unicode string literals. But it would certainly be of general applicability 
>> in using the library for developing Unicode supporting applications in 
>> PIM/ISO Modula-2.
>
>
> Come to think of this, we don't actually need any support for Unicode string 
> literals in the source code.
>
> Instead, all localisable strings should be stored in a set of data files 
> specific to each supported language. At application startup, the current 
> locale setting should then determine which set of localisable data files will 
> be read and the strings stored therein assigned to string variables which are 
> then used for output. No need to embed any Unicode string literals in the 
> code itself. It makes the code leaner and cleaner, and easier to maintain.
>
> And those data files containing the localisable strings may well be in JSON 
> format. Thus it would be all the more useful and desirable to have both a 
> Unicode library and a JSON library, designed to work together. ;-)
>
> regards
> benjamin