Post by Waldek HebischTurbo Pascal had 256 bit limit. Gnu Pascal limits size to signed
integer, that is 2^31 elements on 32-bit machine. On 64-bit machines
Gnu Pascal imposed limit of 6^63 elements, but there were extra
limitations due to linker.
The situation today is this. If I want to write a recursive descent parser in Modula-2 and I want to use enumerated sets of all tokens for FIRST, FOLLOW and skip sets (resync points after an error), then I cannot be sure that the set will work across compilers because the number of tokens may exceed what the compiler will handle, precisely because it is completely left up to implementers.
In other words, the advantage that Modula-2 as an implementation language for such a parser has over C which lacks sets, is diminished because to be sure, I will have to roll my own set library anyway.
Specifying this in a language specification makes sense. Yet, if you pick a value that is too large, then you may run into trouble with compilers targeting small architectures such as micro controllers.
Post by Waldek HebischCan you form literals of user defined set types?
Yes
Post by Waldek HebischCan user defined type be optimezed as well as the buit in one?
In two ways yes.
First, since Modula-2 was designed as a systems implementation language, you have all the means necessary to map out the data of your ADT as you wish, the language doesn't abstract this away.
Second, since M2 R10 is more explicit than most other languages and the syntax is designed to convey the intent of the author where possible, you can pass information to an optimising back end that will usually not be available when using other languages and the optimiser will then have to collect the information (often by heuristics which is nothing more than guessing) or back off.
In M2 R10 all bitset types are library defined, even the ones that look like built-ins such as BITSET and LONGBITSET (they are alias types). The library defined bitsets are generated from templates. In our implementation we will use the exact same templates for the built-in enumerated set types.
There is thus no difference between the IR of a code snippet that handles a built-in enumerated set and that of a bitset of an imported bitset type. The optimisation done on that IR is whatever it is. If the compiler doesn't do any optimisation then it applies to both built-in and library defined sets. If the compiler does optimise or hook into an optimising back end infrastructure, then both are optimised in the same way. The optimiser doesn't ask "Is this a built-in type so I need to do more work on it?".
Post by Waldek Hebisch... I do not see why you specify built-in set type at all.
We have pondered this. At the extreme, we could have designed the dialect with only BOOLEAN and OCTET, no other predefined built-in types, and only ARRAY, RECORD and POINTER as built-in type constructors. All else could have been left for user defined ADTs to handle.
The reason why we didn't quite go that far is mostly convenience and .
Most people are used to and find
TYPE ColourSet = SET OF Colour;
more palatable than
GENLIB ColourSet FROM Sets FOR baseType = <<Colour>> END;
IMPORT ColourSet;
At one point we experimented with the idea to simply treat a TYPE definition/declaration as a directive to kick off the template engine on a library template, but this runs counter to our design objective of transparency, "no invisible magic" and "implicit-rather-than-explicit" which is important to show author intent and ultimately for readability and maintainability.
Post by Waldek HebischWell, I do not want to write myself big enumerations. But I may
wish to write program that generates code using such big enumarations.
Even then we would consider it an abuse. The output of any generator should always be palatable and comprehensible to a human reader. This is very important for correctness, reliability and safety because it impacts verifiability and maintainability.
Post by Waldek HebischHower, upper limit is little issue. I would hope that elements of
small enumerations fit in 8 bits. OTOH, if machine can only read
memory in say 32-bit units (like some DSP) then I want compiler
to choose efficient size (which may be 32-bits).
For that we have pragmas that tell the compiler or optimiser to pack data.
Post by Waldek HebischPost by trijezdciThe point is this, in a language that makes user defined ADTs first class, that is to say user defined ADTs are for all practical purposes indistinguishable from built-in types, in such a language the built-in types no longer reign supreme.
I think you need to make this clearer in your specification.
Correct. You will find that the wiki says update is in progress.
I think I had explained this before. We had initially started out with a wiki but I had to leave Japan after the Fukushima earthquake in a hurry because I had just switched jobs and my new job was to start the Monday after the earthquake and my new employer told me all changed I couldn't start and they had no idea how long this situation would persist, so I accepted another offer in Europe and had to leave Japan within a few days, leaving our wiki server unattended in my apartment in Tokyo where it collected more and more dust and eventually stopped working.
At that point I had already started drafting a PDF from the wiki content and so we simply kept using that PDF as a basis for recording of revisions. At some point I had (prematurely) put in quite a bit of work on layout and formatting so it would look nice, but we still had changes which then messed up the layout and I spent more time on layout than documenting. We then recorded our decisions in a scratch file in plain text, not necessarily in a form that was ready for publication. After we got the wiki back, I decided to build the specification from the earlier PDF and the scratch notes on the wiki first and update a new PDF later because on the wiki I don't need to spend much time on layout and formatting.
This is why the PDF is out of date and the wiki is not yet complete. I am working on that.
Post by Waldek Hebischmention collections in decription of for loop, but I saw no way
for user to define a collection type. Is set a collection?
Yes. I am sure the data type section in the PDF says that sets are collections but that isn't on the wiki yet and next on my to do list. Apologies for that.
Perhaps I may also mention that it has been a challenge to organise the document such that a human reader can read it from start to end without running into situations where a terminology or concept is mentioned that has not yet been explained but sits in a later part of the document.
Especially the blueprint compilation unit did not seem to fit in anywhere. If you build your own ADT and want it to use built-in syntax in the way a built in type does, then you need to declare conformance to a blueprint. Our standard library comes with a complete set of blueprints for common use, so you could just treat them as black boxes at the point where you explain libraries, but since the blueprint defines constraints and requirements that the ADT must follow, you cannot completely ignore blueprints.
But if you start out explaining blueprints first, then you may lose your reader because you are one level above what they may expect. They want to know how do I write a library, and you talk about how to write a specification for writing a certain kind of library.
It has turned out that it is best to organise the document without going into blueprints at first and introduce all else first, then explain them at the end. It also turned out best to order the grammar in the same way as the document and to structure both grammar and document by compilation unit, that is to say first everything relating to definition parts of libraries, then implementation parts, etc.
All this is a side effect of having facilities that make user defined ADTs first class. Since this is a new facility, it was not entirely clear how to order and structure the material when we started out. We had to find out what works by trial and error from the feedback of peer reviewers.
To make matters even worse, what seemed to be the best presentation order changed as a result of certain design decisions along the way.
These factors have also contributed to the specification not being in one piece yet.
Post by Waldek HebischDo you have generic types? For example, can you define a list
type such that you can store on the list elements of some
family of types and retain type safety.
Yes.
Although we do not accomplish this by what you might think of as a "generic type".
What you might call a generic type is not part of the type system in M2 R10.
Post by Waldek HebischMore precisely, can
you define list type that one specialization is list
of integers and another is list of say strings.
Yes.
Post by Waldek HebischThe point is having single definition of list type,
but avoid mixing element types.
I am not sure what you mean by mixing element types, but I think I understand what your concern is.
What you call a definition in this context is not a type definition in M2 R10. Instead it is a blueprint which is a compilation unit of its own that imposes constraints and requirements on libraries that declare conformance to it.
The concept is somewhat similar to what Smalltalk calls protocols and Java calls interfaces, but there are significant differences. It would be incorrect to consider them equivalent.
For example some of the requirements in a blueprint are only intended for the compiler to be able to synthesise certain operations, a client library would never ever need to use those facilities directly.
Also, an ADT doesn't define its own literal compatibility because this is something that can be specified at the blueprint level and the ADTs inherits that from the blueprint without the need to restate it.
Post by Waldek Hebisch... Namely, in language that is serious about
there is always risk that you have routine doing what you
need but on incompatible type. So you want buit in types
to be widely applicable. Arbitrary limits go against
such purpose.
Well, this is too generic for me to comment on, but suffice it to say: our limits don't.
Post by Waldek Hebisch... nestable comments
are useful to comment out sections of code.
No, they are not.
The practise you describe leads to what is known as technical debt.
It needs to be machine readable/identifiable so it can be found if forgotten and flagged in reports.
To satisfy that need, sections of code should be disabled by means that make it visible and obvious. We have a pragma for that.
Post by Waldek HebischBut once you allow
them any fixed limit causes trouble. In case of comment the
compile can just count nesting level, so you can make it practically
unlimited (have limit bigger than maximal allowed file size).
Parsers need to use stack, but for example Gnu Pascal used
parser with dynamically allocated stack, so limits were
quite high.
We disagree on the level of "freedom".
Our philosophy is essentially about extreme strictness.
I once read a usenet posting many many many years ago where somebody was comparing operating systems or computer platforms to political isms. People then commented by offering alternative isms.
One such comment was either about VAX/VMS or MacOS -- I don't remember those particulars now, but I remember the comment as saying "XYZ is not ***, it is fascism, but GOOD fascism".
Although the whole comparison may be objectionable on the grounds of political correctness. I believed back then and I do believe now that -- leaving political correctness aside -- there was a great deal of truth in that statement.
I would rather call it extreme strictness but essentially quality assurance in software is first and foremost about restrictions imposed on programmers who all too often don't follow good practise, whatever the reasons may be -- they may be under pressure, they may be tired or in some cases they may not anticipate the negative consequences of their actions.
It is no accident that Modula-2, although essentially based on a Xerox PARC design, arose out of Switzerland, where people can be rather stubborn about rules they like to impose on themselves.
It is also no accident that Swiss watches emerged in that environment.
Post by Waldek HebischI do not think you can get real portablity via limits.
I am not saying that portability is a result of limits, at least not limits alone, but leaving limits to implementors is a pretty sure way of not having portability.
Post by Waldek HebischModula-2
in principle should be usable for embedded programming.
Our design is very much influenced by the desire to target embedded device controllers. The notion to move larger stuff into library is rather more helpful in this context.
Post by Waldek Hebischyou may get 8-bitter with 1 kilobyte of RAM and 16 kilobyte
flash. Compilcated code simply is to big to fit into such
machine.
Hence the move into a library. Don't use the "large stuff" libraries on a small target.
Post by Waldek HebischOTOH on big machines people routinely generate
huge surce files: GNU C folks get bug reports about files
bigger than half milion lines.
Just because this is done doesn't mean it is a good practise.
Post by Waldek HebischI understand the mindset, but I do not agree.
There are cases where things should be left to implementation, there are other cases where this is not so. I do not think that there can be one blanket rule for all cases.
Post by Waldek HebischBut IMO limits are better
left to common sense and market.
I do not believe in feature evolutionism.
If we leave software features to (consumer) markets we get precisely the kind of lousy quality we have now. Features, features, features, ship early, fix later.
As for common sense, all the limits we set are common sense in the context I have explained.
If you wrote a generator that generates source code with a 65000 value enumeration type, I wouldn't do any further business with you. Our mission is not about nostalgia, it is not about giving geeks a new toy, it is ultimately about telling folks "YOU ARE DOING IT WRONG".
Call us stubborn old farts if you like. We are in good company. Niklaus Wirth would be a stubborn old fart by this definition, too. So would renowned software quality assurance experts like Harry Sneed.
We are all stubborn old farts who are telling the rest of the IT world that they are doing it wrong.
So be it.