Discussion:
What happened to modula2.net
(too old to reply)
Nemo
2015-10-03 01:54:24 UTC
Permalink
Raw Message
Modula2.net has changed and requires Javascript to even load. Whois
indicates a recent change. Anyone have any more information?
trijezdci
2015-10-03 02:33:55 UTC
Permalink
Raw Message
Post by Nemo
Modula2.net has changed and requires Javascript to even load. Whois
indicates a recent change. Anyone have any more information?
The site is now at modula-2.net (with a dash),

The earlier domain was hijacked and I am in contact with the registrar to get it back. It may be possible without legal action, but should it become necessary then legal action will be on the table, too.
j***@gmail.com
2015-10-03 08:35:38 UTC
Permalink
Raw Message
Post by trijezdci
The earlier domain was hijacked
that's not how it works. if you fail to renew the existing lease of the domain name, the name goes into quarantine for 4 weeks. after that time, the name is inhibited for a year or so.
a domain registrar 'saved the name' when it was in quarantine (since it saw the potential of the name) and leased the domain for another year. it will do so for the next 4 years as well.
Post by trijezdci
and I am in contact with the registrar to get it back. It may be possible without legal action, but should it become necessary then legal action will be on the table, too.
legal action is NOT required. these people care for your domain name and prevented the domain from going into oblivion. you will get the domain back in an auction. you, and a dummy buyer, will start bidding for the name. you will get it back for less than 2 k$. legal action will be more expensive, so the auction is cheaper.

forget about modula2.net. you have modula-2.net and the content of that site is so minimal.. the list of compilers is downright out of date. the page is useless
trijezdci
2015-10-03 11:27:05 UTC
Permalink
Raw Message
Post by j***@gmail.com
that's not how it works.
It was hijacked before its current state. The hijackers then put up one of those useless-links pages in the hope to earn money from click through. At one point it was even showing pr0n pictures.
Chris Burrows
2015-10-03 23:49:13 UTC
Permalink
Raw Message
Post by j***@gmail.com
forget about modula2.net. you have modula-2.net and the content of that site is so minimal.. the list of compilers is downright out of date. the page is useless
My favourite Modula-2 site that is comprehensive AND regularly maintained is:

http://freepages.modula2.org/index.html
trijezdci
2015-10-05 03:02:44 UTC
Permalink
Raw Message
Post by j***@gmail.com
forget about modula2.net. you have modula-2.net and the content of that site is so minimal.. the list of compilers is downright out of date. the page is useless
I did maintain the content regularly before the domain was hijacked. Its aim wasn't as broad, but more specific. It took a lot of time tracking down compilers and finding out what their status was, in some cases tracking down the authors, write to them, ask questions, try to convince them to release sources or at least provide a copy of documentation and perhaps executables to Randy Bush so he can put them on psg.com.

At the time, the site ranked within the first page of Google's search results for Modula-2. But of course that changed when it was replaced with an irrelevant click-through link page. Furthermore, the machine it was running on had some kind of heat problem and I was no longer there.

I was to start a new job with Ericsson in Yokohama on the Monday after the Fukushima disaster. They called me to tell me that I couldn't start, they would likely evacuate to Hong Kong, that me and my family wouldn't be evacuated because I hadn't received my badge yet, declined to let me come in for 10 minutes to collect my badge, go back home and wait, said that it was entirely unclear how long the uncertain situation would persist.

I had also received an offer from Nokia in Helsinki but was waiting for a security clearance from the Finnish authorities which took ages. On that same day I got a call from Helsinki that my clearance had come through. With Ericsson having left me in limbo, we packed two suitcases and left for Finland within days. No time to do any preparations for relocating anything because it wasn't anticipated.

I got very busy trying to make ends meet, having to pay for apartments in two of the world's most expensive cities. I never got a chance to go back to clean up and relocate or recover the machine. I just couldn't afford the holidays, nor the tickets. By the time my contract in Finland finished we had only just about stayed afloat. I got another assignment in Switzerland where I could take accommodation in a neighbouring EU country and commute in order to keep the cost of living down, when three weeks into the assignment the Swiss national bank decided they wanted to weaken the Swiss Franc which wiped out 20% of my new income in an instant keeping me in the same barely subsisting situation for another two years. Eventually, I ran out of contracts, income and money, and after a stint in a homeless shelter we returned to Japan where I was finally able to recover the data. I sent it to Rick who hosted it on the present domain without doing any filtering on what may or may not be outdated.

The reason it is up there is not the site but because we needed some content from the wiki for completing our specification and Rick's part of the book we are working on. You may forgive me but work on the R10 project is a lot more important to us than updating the content of the landing page. Every spare time I had over the last 5 years I spent on the project. A lot of people are looking forward to us completing work on the project and very few people mind that the landing page of the hosting domain hasn't been maintained. Most agree with the priority being on the project instead.

BTW, amongst the people who are looking forward to progress on our project is the maintainer of the site you mentioned.

I trust this will put things into perspective for you.

Thank you for your understanding.
Gour
2015-10-05 10:31:22 UTC
Permalink
Raw Message
On Sun, 4 Oct 2015 20:02:44 -0700 (PDT)
Post by trijezdci
At the time, the site ranked within the first page of Google's search
results for Modula-2. But of course that changed when it was replaced
with an irrelevant click-through link page. Furthermore, the machine
it was running on had some kind of heat problem and I was no longer
there.
Thank you for sharing...

[...]
Post by trijezdci
BTW, amongst the people who are looking forward to progress on our
project is the maintainer of the site you mentioned.
WHile browsing modula-2.net site I've noticed that Team some additional
members besides you & Dick (http://modula-2.net/m2r10/pmwiki.php?n=Project.Team). Is it recent event?

In any case, let's hope there will be additional members in not so
distant future...

Otoh, there are noble goals mentioned in http://modula-2.net/m2r10/pmwiki.php?n=Project.Goals andI hope all of them will be accomplished with success...


Sincerely,
Gour
--
There is no possibility of one's becoming a yogī, O Arjuna,
if one eats too much or eats too little, sleeps too much
or does not sleep enough.
trijezdci
2015-10-05 12:35:05 UTC
Permalink
Raw Message
Post by Gour
WHile browsing modula-2.net site I've noticed that Team some additional
members [...]
In any case, let's hope there will be additional members in not so
distant future...
One thing that sets our project apart is that we used the old-fashioned approach: Do a thorough design first and get it right, then implement. However, good language designs don't come from large groups. Wirth has written about that and Rick and I had our own personal experience from participating in the ISO M2 working group. Nevertheless, we have had many collaborators during our design phase who peer reviewed our work and provided invaluable feedback.

Now that we have embarked on implementation, we need a different kind of collaboration and we are actively recruiting. To this end, it is important to divide the work in such a way that people can work mostly independently. Another challenge is that many people, even with excellent skills, often think building a compiler is a kind of rocket science and they won't be able to contribute anything because it must be over their heads. In reality, this isn't really as hard as many imagine it is, especially not with the recursive descent parsing method we chose. High efficiency code optimisers are hard to do, but there are frameworks for that such as LLVM, and then again it is not strictly necessary. If I am not mistaken, most if not all of Wirth's compilers have been non-optimising.

Nevertheless, there are a few more folks interested in joining. However, the important milestone here will be the bootstrap. Even limited to a subset, once we have a self-hosting compiler that people can download, build and play with, we can expect a larger number of volunteers joining the effort.
Post by Gour
Otoh, there are noble goals mentioned in http://modula-2.net/m2r10/pmwiki.php?n=Project.Goals andI hope all of them will be accomplished with success...
One of the folks commenting in this group -- even though usually in an obnoxious and negative way -- has made an interesting observation in that once universities teach Python to their undergraduate students, the latter become addicted and all hope to teach them proper engineering is then lost.

There is a lot of truth to that. The ideal is to have an appealing notation that is also founded on proper engineering principles. While these objectives are often contradictory and thus hard to design in a single package, it is not impossible to do. Steve Jobs said "You need to start with the user experience and then work your way back to the technology". A lot of what makes programming languages appealing has to do with user experience, and in particular with convenience.

Thus, the choice is often "do we give them the convenience or do we make it safe and reliable?" The kind of designer who designs languages such as Python and Ruby generally chooses convenience over safety and reliability. OTOH, when you want to design a type safe language you are often inclined to choose safety over convenience, but in many cases it does not have to be an either-or proposition. Work a little harder at your design and you will find that you can very often accomplish safety, reliability and convenience. Very often you can have your cake and eat it too. You must not give up too easily.

When you accomplish that for a large part of your design, you will have something that is both pleasant to use but also founded on engineering principles. Then even people who do not yet know to appreciate the engineering foundation will at first notice the convenience and like the tool for that. Later on, they will get to realise the value of the engineering foundation, too. And those who know that in case of a conflict between convenience and safety, convenience must be sacrificed will come to realise that they do not necessarily need to make that sacrifice as often as they have come to accept. They too will come to like the tool for it gives them the safety they don't want to compromise together with the convenience they have previously had to do without.

This is why we believe we have a very good chance of successfully broadening the reach of our project.

To name a few examples where we managed to do both convenience and safety ...

(1) variadic functions

C practitioners often use variadic functions, they can be of great utility and thus convenience. Think of inserting an arbitrary number of key/value pairs into a tree, if only for initialisation:

insert(tree, key1, value1);
insert(tree, key2, value2);
insert(tree, key3, value3);
etc etc etc

versus

insert(tree, key1, value2, key2, value2, key3, value3, etc etc etc);

Unfortunately, though, in C variadic functions are done such that they are dangerous. Variadic parameters are entirely untyped, crashes are almost guaranteed.

That doesn't mean you couldn't do it right. In our revision we have designed fully type checked variadic parameters, thus combining safety and utility/convenience.

(2) string concatenation

Languages like Python and Ruby permit infix expression concatenation of strings, not only string literals, but runtime strings as well, or a mix of runtime strings and string literals. Working with strings without infix concatenation can be extremely inconvenient and significantly increase clutter and opportunity for error in source code. Yet when it is done by way of what is known as duck typing, the facility is not safe. Here again it seems that the choice is either convenience or safety, not both.

Our revision provides infix concatenation of non-rigid arrays (including ARRAY OF CHAR and ARRAY OF UNICHAR) but type safe.

A non-rigid array is an array whose number of components is not fixed (within limits). Even statically allocated arrays may be non-rigid. NUL terminated character arrays and Pascal strings are examples of non-rigid arrays that can be statically allocated.

Some languages call them open arrays but this usually only applies to dynamically allocated arrays. Our terminology includes both statically and dynamically allocated arrays.

(3) array slicing

Python and some other languages offer array slicing which is of immense utility and convenience, but again due to the means by which it is implemented (duck typing) it is unsafe.

Our revision provides both L-value and R-value slicing for non-rigid arrays and lists, again, type-safe.

target := source[m..n];

target[p..] := source;

target[p..q] := source;

target[p..q] := source[m..n];

and with concatenation

foo := bar[m..n] & baz[p..q] & bam;

all indices are bounds checked, all component types must satisfy strict name equivalence.


There are other instances where we have married utility with safety. In fact we did not compromise safety anywhere. We are confident that the aforementioned addiction effect that reportedly occurs when teaching undergraduates Python, will work in our favour and thus in favour of safety and engineering principles, since convenience doesn't mean abandoning the latter.

IOW, to promote engineering principles, you have to wrap it in a convenience package or it won't fly. We worked very hard to heed that lesson.

I am thus confident that we will not have any issues recruiting volunteers for the project. However, as mentioned, the important milestone to achieve first is the bootstrap. That is going to be key.
Nemo
2015-10-05 14:09:42 UTC
Permalink
Raw Message
Post by trijezdci
However, good language designs don't come from large groups.
Wirth has written about that
And Brooks has a section on that.
Post by trijezdci
Now that we have embarked on implementation,
Multi-processor implementations are a necessity. Despite what some
vocal people think, the world does not run on x86.
trijezdci
2015-10-05 17:38:04 UTC
Permalink
Raw Message
Post by Nemo
Post by trijezdci
However, good language designs don't come from large groups.
Wirth has written about that
And Brooks has a section on that.
To get a good design, you have to scrutinise your ideas to exhaustion, over and over again, and often you will abandon things that seemed already decided and redo them.

Often, an improvement in one seemingly unrelated and isolated area can have a domino effect on a large number of other areas where previous decisions may have to be revisited and redone.

This is extremely difficult to accomplish in a larger group of participants when they are not all intensely focussed on the subject matter of every feature at any given time.

Moreover, if you abandon a significant piece of work for which consensus had been reached before, possibly by painful concessions of individuals, there will be a lot of people who will leave the effort in anger. You won't get the buy in, so you don't have the flexibility needed.
Post by Nemo
Multi-processor implementations are a necessity. Despite what some
vocal people think, the world does not run on x86.
Agreed.

BTW, we have every intention to add native actors to our design but we left this for phase two. In the meantime, we'll provide a library interface to POSIX threads. For multi-threading we will recommend to use our revised coroutines though. On multi-processor/multi-core targets it is always possible to run multiple pools of coroutines, each pool running on its own CPU/core.
Gour
2015-10-06 07:04:38 UTC
Permalink
Raw Message
On Mon, 5 Oct 2015 05:35:05 -0700 (PDT)
Post by trijezdci
Another challenge is that many people, even
with excellent skills, often think building a compiler is a kind of
rocket science and they won't be able to contribute anything because
it must be over their heads. In reality, this isn't really as hard as
many imagine it is, especially not with the recursive descent parsing
method we chose. High efficiency code optimisers are hard to do, but
there are frameworks for that such as LLVM, and then again it is not
strictly necessary. If I am not mistaken, most if not all of Wirth's
compilers have been non-optimising.
Heh, I recall that while I was studying computer engineering on the
university (many years ago), we had to write (pair-programming) compiled
and were using (Turbo) Pascal for tha...and I can safely bet it was a
non-optimizing one. :-)

The problem is that due to life circumstances I went into another
direction and hardly remember anything from that time. :-(
Post by trijezdci
Nevertheless, there are a few more folks interested in joining.
However, the important milestone here will be the bootstrap. Even
limited to a subset, once we have a self-hosting compiler that people
can download, build and play with, we can expect a larger number of
volunteers joining the effort.
I fully agree...having anything which produces some result, even 'Hello
world' is an important milestone.
Post by trijezdci
There is a lot of truth to that. The ideal is to have an appealing
notation that is also founded on proper engineering principles.
I'm doing some light reading of King's Modula-2 book and looking to
check how much it's different from today's Object Pascal although I'm
aware that due to 'designing process0 deployed with OP, Modula-2 is
certainly more elegant, not to speak about R10 revision.
Post by trijezdci
This is why we believe we have a very good chance of successfully
broadening the reach of our project.
All the best!!
Post by trijezdci
That doesn't mean you couldn't do it right. In our revision we have
designed fully type checked variadic parameters, thus combining
safety and utility/convenience.
Nice one!
Post by trijezdci
Our revision provides infix concatenation of non-rigid arrays
(including ARRAY OF CHAR and ARRAY OF UNICHAR) but type safe.
How much is R10 Unicode-aware?
Post by trijezdci
Some languages call them open arrays but this usually only applies to
dynamically allocated arrays. Our terminology includes both
statically and dynamically allocated arrays.
Iirc, King's book mentions open arrays withing the context of Modula-2
itself?
Post by trijezdci
target[p..] := source;
target[p..q] := source;
target[p..q] := source[m..n];
That's elegant indeed.
Post by trijezdci
and with concatenation
foo := bar[m..n] & baz[p..q] & bam;
all indices are bounds checked, all component types must satisfy strict name equivalence.
Cool, cool!
Post by trijezdci
I am thus confident that we will not have any issues recruiting
volunteers for the project. However, as mentioned, the important
milestone to achieve first is the bootstrap. That is going to be key.
Do you have any rough estimate when you would like to see it?


Sincerely,
Gour
--
A person is considered still further advanced when he regards honest
well-wishers, affectionate benefactors, the neutral, mediators, the
envious, friends and enemies, the pious and the sinners all with an
equal mind.
trijezdci
2015-10-06 08:29:37 UTC
Permalink
Raw Message
Post by Gour
Post by trijezdci
Our revision provides infix concatenation of non-rigid arrays
(including ARRAY OF CHAR and ARRAY OF UNICHAR) but type safe.
How much is R10 Unicode-aware?
There are ten built-in types in M2R10, two of those built-in types are CHAR and UNICHAR.

http://modula-2.net/m2r10/pmwiki.php?n=Spec.LanguageReport#TypeChar

Compliant compilers are required to recognise source text encoded in 7-bit ASCII or UTF-8, optionally implementations may support other encodings. Any source file that is not 7-bit ASCII encoded must specify the encoding using the <*ENCODING*> pragma.

http://modula-2.net/m2r10/pmwiki.php?n=Spec.LanguageReport#PragmaEncoding

When this pragma is specified and the compiler recognises the encoding, then printable characters outside of the 7-bit ASCII range may also appear in quoted strings and within comments.

Identifiers may only contain the standard identifier characters a-z, A-Z, 0-9, foreign identifier characters _ and $, and on OpenVMS additionally %, but never any unicode characters outside the ASCII set.
Post by Gour
Post by trijezdci
Some languages call them open arrays but this usually only applies to
dynamically allocated arrays. Our terminology includes both
statically and dynamically allocated arrays.
Iirc, King's book mentions open arrays withing the context of Modula-2
itself?
Open arrays in classic and ISO M2 are limited to formal parameters only.

In Oberon, or at least some versions of it, there are open array types, which are dynamically allocated.

In M2R10, non-rigid arrays are called flexible arrays and they may be statically allocated

http://modula-2.net/m2r10/pmwiki.php?n=Spec.LanguageReport#ArrayTypes
Post by Gour
Post by trijezdci
I am thus confident that we will not have any issues recruiting
volunteers for the project. However, as mentioned, the important
milestone to achieve first is the bootstrap. That is going to be key.
Do you have any rough estimate when you would like to see it?
It depends on whether I can afford to spend full time on it. If I can get to that, probably three months or thereabouts.
trijezdci
2015-10-06 08:31:45 UTC
Permalink
Raw Message
Please also note that the bootstrap compiler will not do unicode because unicode support is not required for bootstrapping, it will be added after the bootstrap.
Gour
2015-10-06 09:03:47 UTC
Permalink
Raw Message
On Tue, 6 Oct 2015 01:31:45 -0700 (PDT)
Post by trijezdci
Please also note that the bootstrap compiler will not do unicode
because unicode support is not required for bootstrapping, it will be
added after the bootstrap.
I don't have problem with it - only expect unicode support in
'production' compiler.


Sincerely,
Gour
--
A person is considered still further advanced when he regards honest
well-wishers, affectionate benefactors, the neutral, mediators, the
envious, friends and enemies, the pious and the sinners all with an
equal mind.
Gour
2015-10-06 09:08:55 UTC
Permalink
Raw Message
On Tue, 6 Oct 2015 01:29:37 -0700 (PDT)
Post by trijezdci
There are ten built-in types in M2R10, two of those built-in types are CHAR and UNICHAR.
Thank you.
Post by trijezdci
Identifiers may only contain the standard identifier characters a-z,
A-Z, 0-9, foreign identifier characters _ and $, and on OpenVMS
additionally %, but never any unicode characters outside the ASCII
set.
OK.
Post by trijezdci
In M2R10, non-rigid arrays are called flexible arrays and they may be statically allocated
http://modula-2.net/m2r10/pmwiki.php?n=Spec.LanguageReport#ArrayTypes
I must admit that, after skimming the above referenced links, the
Language Report seems much more readable than expected. ;)
Post by trijezdci
It depends on whether I can afford to spend full time on it. If I can
get to that, probably three months or thereabouts.
It sounds terrific!!

I'm probably not qualified to help much with R10 at this point of time,
but will closely look what's going on in regard...


Sincerely,
Gour
--
One who works in devotion, who is a pure soul, and who controls
his mind and senses is dear to everyone, and everyone is dear to
him. Though always working, such a man is never entangled.
Martin Brown
2015-10-06 14:02:17 UTC
Permalink
Raw Message
On 05/10/2015 13:35, trijezdci wrote:

[snip all very good stuff and nothing I disagree with]

Hope you can get a bootstrap compiler going.
Post by trijezdci
IOW, to promote engineering principles, you have to wrap it in a convenience package or it won't fly.
We worked very hard to heed that lesson.
One minor plea for a small amount of syntactic sugar (I know this goes
against the hard line type safety stuff but it improves readability).

SYSTEM.VAL(TYPE,x) is too clumsy and TYPE(x) should be allowed as a
shorthand synonym even if it is only as a pragma controlled extension.

Expressions involving a mixture of INTEGER and REAL values becomes near
impossible to read otherwise.

Adding a SYSTEM.MULDIV(a,b,c) returning INTEGER a*b/c but in the way
that the hardware actually computes it so that a*b can never overflow.

Please retain CARDINALs - they are very useful for DACs and the like.
64 bit INTEGERs and CARDINALs would be nice in the final version.

I liked Topspeeds long BITSET feature too. But I don't consider it
important enough to have in any early version. Getting the core basic
TYPEs and constructs all reliably implemented is key to success.

Actually a minimal subset essential to the bootstrap...
Post by trijezdci
I am thus confident that we will not have any issues recruiting volunteers for the project.
However, as mentioned, the important milestone to achieve first is
the bootstrap. That is going to be key.
Good luck and best wishes.
Sorry I don't have time to volunteer at the moment.
--
Regards,
Martin Brown
Nemo
2015-10-06 14:57:05 UTC
Permalink
Raw Message
Post by Martin Brown
I liked Topspeeds long BITSET feature too. But I don't consider it
important enough to have in any early version.
Cryptography without these is not easy.
trijezdci
2015-10-06 15:16:30 UTC
Permalink
Raw Message
Post by Martin Brown
One minor plea for a small amount of syntactic sugar (I know this goes
against the hard line type safety stuff but it improves readability).
We provide quite a bit of syntax sugar but never compromise safety in the process.
Post by Martin Brown
SYSTEM.VAL(TYPE,x) is too clumsy and TYPE(x) should be allowed as a
shorthand synonym even if it is only as a pragma controlled extension.
We came to the conclusion that if we don't permit mixing of types in arithmetic expressions, then type conversion (safe type transfer) is of such central importance that it deserves its own dedicated conversion operator.

We thus introduced :: as type conversion operator.

real := int :: REAL;
int := real :: INTEGER;

Note that :: works between any two scalar types, whether they are built-in or user defined. This is achieved by requiring user defined scalar types to provide two conversion primitives that convert values of the user defined scalar to and from a language defined serialisation format called SXF (Scalar eXchange Format). This way any-to-any conversion is always possible via SXF.

As for casting (unsafe type transfer) we provide a pseudo-function CAST in pseudo-module UNSAFE. This is almost identical to ISO M2's CAST only that constant arguments are permitted too.

The recommended use is qualified to make the unsafe nature more explicit:

foo := UNSAFE.CAST(Foo, bar);

In M2R10, all unsafe features must either come from pseudo-module UNSAFE or from optional pseudo-module ASSEMBLER because assembly is by its very nature unsafe. No unsafe features must be permitted to reside anywhere else.

Using pragmas to enable unsafe syntax would violate our design principles.
Post by Martin Brown
Expressions involving a mixture of INTEGER and REAL values becomes near
impossible to read otherwise.
Agreed. Hence the :: operator ;-)
Post by Martin Brown
Adding a SYSTEM.MULDIV(a,b,c) returning INTEGER a*b/c but in the way
that the hardware actually computes it so that a*b can never overflow.
Our SYSTEM module is called UNSAFE and it has a wealth of low level arithmetic primitives.
Post by Martin Brown
Please retain CARDINALs - they are very useful for DACs and the like.
CARDINAL and LONGCARD are two of the ten built-in types.

I had already mentioned this in a previous post I think, but our FAQ has an entry explaining why we didn't remove cardinals:

http://modula-2.net/m2r10/pmwiki.php?n=Project.FAQ#Cardinals
Post by Martin Brown
64 bit INTEGERs and CARDINALs would be nice in the final version.
The size of the built-in cardinals and integers are implementation defined. The specification only requires TSIZE(CARDINAL) = TSIZE(INTEGER) and likewise for the LONG versions and it requires that the long versions have higher precision.

Our standard library has CARDINALxx and INTEGERxx, for xx in 16, 32, 64 and 128. If that is not enough, they are template generated, so all you need to do is kick the template engine into action and give it a value of 256

GENLIB CARD256 FROM CARDINALs FOR BitWidth = 256 END;
IMPORT CARD256;

User defined ADTs are first class, for most practical purposes they are indistinguishable from their built-in counterparts. The only difference is that built-in types do not need an import and only built-in types can be used in compile time expressions.

The implementations of the types use short names such as INT16, CARD64 etc. However, the standard library automatically defines alias types for them as INTEGER16, CARDINAL64 etc. This takes the built-in types into account. Thus, if the implementation provided built-in LONGCARD is 64-bit, then CARDINAL64 is an alias for LONGCARD, otherwise it will be an alias for CARD64 which is library.

Likewise for INTEGERxx types.
Post by Martin Brown
I liked Topspeeds long BITSET feature too. But I don't consider it
important enough to have in any early version.
Due to the first class nature of ADTs in M2R10 we do not need built-in bitset types. Our bitset types are all in the standard library. There are BITSETxx for 16, 32, 64, 128 and 256.
Post by Martin Brown
Getting the core basic TYPEs and constructs all reliably implemented is key to success.
Naturally :-)
Post by Martin Brown
Good luck and best wishes.
Thanks.
Post by Martin Brown
Sorry I don't have time to volunteer at the moment.
Not to worry. We appreciate the encouragement and moral support ;-)
trijezdci
2015-10-06 15:33:02 UTC
Permalink
Raw Message
Post by trijezdci
Note that :: works between any two scalar types, whether they are built-in or user defined. This is achieved by requiring user defined scalar types to provide two conversion primitives that convert values of the user defined scalar to and from a language defined serialisation format called SXF (Scalar eXchange Format). This way any-to-any conversion is always possible via SXF.
Perhaps I should add that SXF is radix preserving. This means that if you convert between two types that are encoded in the same radix, then there will be no rounding errors as artefacts of the conversion. For example converting from BCD to LONGBCD (from our standard library) will not go via binary but decimal to decimal while conversion between two binary encoded types is binary to binary. Rounding artefacts can only occur when converting between types that are encoded in different radixes.
Chris Burrows
2015-10-06 21:34:36 UTC
Permalink
Raw Message
Post by trijezdci
If I am not mistaken, most if not all of Wirth's compilers have been non-optimising.
Define 'non-optimising'. If you are referring to 'unsafe optimisations' then that may be true. Otherwise, yes, you are mistaken.
trijezdci
2015-10-07 04:56:01 UTC
Permalink
Raw Message
Post by Chris Burrows
Post by trijezdci
If I am not mistaken, most if not all of Wirth's compilers have been non-optimising.
Define 'non-optimising'. If you are referring to 'unsafe optimisations' then that may be true. Otherwise, yes, you are mistaken.
The terminology is well established and generally recognised by practitioners. In this day and age, if a compiler is described as optimising, it is expected to go beyond trivial optimisation techniques, aka peep hole optimisations. most of which deal with trivial cases of redundancy elimination.

An optimising compiler is generally expected to do more, typically what is known as global optimisation: non-trivial local and global redundancy elimination, loop optimisations such as invariant code motion, unrolling and pipelining, and finally register allocation and instruction scheduling.

All of these techniques can be implemented perfectly safe. They do require an abstract syntax tree though. Many of Wirth's compilers have been single-pass compilers and those do not build any AST, which means that such optimisations are out of reach for single pass compilers.

Wirth has been employing such peep hole optimisations, but to my knowledge not beyond. How many of his compilers if any at all use SSA?

This is not to say that peep hole optimisations are not effective, but if you wanted to suggest that anything Wirth doesn't do is unsafe that would bring us into the realm of religion.

Perhaps you were thinking of extremely aggressive techniques such as inter-procedural optimisations, but that is at the other end of the spectrum, most optimisation techniques lie between the trivial and the aggressive.

And if we wanted to do nit-picking, according so some authors, code optimisation is a misnomer to bein with. Michael L.Scott offers the alternative term "code improvement" in his seminal work "Programming language Pragmatics", aka PLP.
Martin Brown
2015-10-07 08:33:09 UTC
Permalink
Raw Message
Post by Chris Burrows
Post by trijezdci
If I am not mistaken, most if not all of Wirth's compilers have been non-optimising.
Define 'non-optimising'. If you are referring to 'unsafe optimisations' then that may be true. Otherwise, yes, you are mistaken.
Certainly the old Logitech 4 pass one was distinctly non optimising.
It spent a heck of a lot of time saving values to memory and then
reloading registers that already contained the same value.

JPI was the first half decent optimising compiler on the PC platform and
as I recall a single pass compiler with some limitations.
--
Regards,
Martin Brown
Nemo
2015-10-07 21:28:16 UTC
Permalink
Raw Message
Post by Martin Brown
JPI was the first half decent optimising compiler on the PC platform and
as I recall a single pass compiler with some limitations.
EPC had probably the best optimizations on Unix.

j***@gmail.com
2015-10-04 10:02:18 UTC
Permalink
Raw Message
why would anyone steal a site that attracts zero visitors per day? it takes a lot of time to hijack a site. when I look at the dns history, the domainname has been moved from registrar to registrar and from webserver to webserver.

I prefer Frank's pages since they are well maintained (thanks, Christoph) and well hosted (thanks, Frank).
trijezdci
2015-10-05 02:19:08 UTC
Permalink
Raw Message
Post by j***@gmail.com
why would anyone steal a site that attracts zero visitors per day? it takes a lot of time to hijack a site.
Ok then, if you want to call me a liar, I will return the favour to you and call you a party pooper. This is not without rationale: You have nothing to contribute, all you ever do is discredit other people. No matter what anyone might say, you have to throw mud into their face. The classic definition of a party pooper. Anyway, have a nice day. I won't respond again.
Loading...