Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC SC approves inclusion of Algol 68 Front End

gcc.gnu.org

Post reply on HN
Print view View original

71–80 of 115 posts

Re: GCC SC approves inclusion of Algol 68 Front End

#71

Post by inkyoto »

adrian_b wrote: post #70
inkyoto wrote: post #65

Earlier quoted context omitted.

* was the usual infix multiplication operator in BCPL, and it was not used for pointer arithmetic. The BCPL manual[0] explains the «monadic !» operator (section 2.11.3) as: 2.11.3 MONADIC ! The value or a monadic ! expression is the value of the storage cell whose address is the operand of the !. Thus @!E = !@E = E, (providing E is an expression of the class described in 2.11.2). Examples. !X := Y Stores the value of…

The BCPL manual linked by you is not useful, as it describes a recent version of the language, which is irrelevant for the evolution of the B and C languages. A manual of BCPL from July 1967, predating B, can be found on the Web. The use of the character "!" in BCPL is much later than the development of the B language from BCPL, in 1969. The asterisk had 3 uses in BCPL, as the multiplication operator, as a marker for…

I take no issue with the acknowledgment of being on the losing side of a technical argument – provided evidence compels.

However, to be entirely candid, I have submitted two references and a direct quotation throughout the discourse in support of the position – each of which has been summarily dismissed with an appeal to some ostensibly «older, truer origin», presented without citation, without substantiation, and, most tellingly, without the rigour such a claim demands.

It is important to recall that during the formative years of programming language development, there were no formal standards, no governing design committees. Each compiled copy of a language – often passed around on a tape and locally altered, sometimes severely – became its own dialect, occasionally diverging to the point of incompatibility with its progenitor.

Therefore, may I ask that you provide specific and credible sources – ones that not only support your historical assertion, but also clarify the particular lineage, or flavour, of the language in question? Intellectual honesty demands no less – and rhetorical flourish is no substitute for evidence.

Re: GCC SC approves inclusion of Algol 68 Front End

#72

Post by adrian_b »

inkyoto wrote: post #71
adrian_b wrote: post #70

Earlier quoted context omitted.

The BCPL manual linked by you is not useful, as it describes a recent version of the language, which is irrelevant for the evolution of the B and C languages. A manual of BCPL from July 1967, predating B, can be found on the Web. The use of the character "!" in BCPL is much later than the development of the B language from BCPL, in 1969. The asterisk had 3 uses in BCPL, as the multiplication operator, as a marker for…

I take no issue with the acknowledgment of being on the losing side of a technical argument – provided evidence compels. However, to be entirely candid, I have submitted two references and a direct quotation throughout the discourse in support of the position – each of which has been summarily dismissed with an appeal to some ostensibly «older, truer origin», presented without citation, without substantiation, and, m…

What you say is right, and it would have been less lazy for me to provide links to the documents that I have quoted.

On the other hand, I have provided all the information that is needed for anyone to find those documents through a Web search, in a few seconds.

I have the quoted documents, but it is not helpful to know from where they were downloaded a long time ago, because, unfortunately, the Internet URLs are not stable. So for links, I just have to search them again, like anyone else.

These documents can be found in many places.

For instance, searching "b language manual 1972" finds as the first link:

https://www.nokia.com/bell-labs/about/dennis-m-ritchie/kbman...

Searching "martin richards bcpl 1967" finds as the first link:

https://www.nokia.com/bell-labs/about/dennis-m-ritchie/bcpl....

Additional searching for CPL and BCPL language documents finds

https://archives.bodleian.ox.ac.uk/repositories/2/archival_o...

where there are a lot of early documents about the languages BCPL and CPL.

Searching for "Wirth Euler language 1966" finds the 2-part paper

https://dl.acm.org/doi/10.1145/365153.365162

https://dl.acm.org/doi/10.1145/365170.365202

There exists an earlier internal report about Euler from April 1965 at Stanford, before the publication of the language in CACM, where both indirection and address-of were prefix, like later in BCPL. However, before the publication in January 1966, indirection has been changed to be a postfix operator, choice that has been retained in the later languages of Wirth.

http://i.stanford.edu/pub/cstr/reports/cs/tr/65/20/CS-TR-65-...

The early IBM PL/I manuals are available at

http://bitsavers.org/pdf/ibm/360/pli/

Searching for "algol 68 reports" will find a lot of documents.

And so on, everything can be searched and found immediately.

Re: GCC SC approves inclusion of Algol 68 Front End

#73

Post by vintagedave »

ofalkaed wrote: post #22
j2kun wrote: post #14

Earlier quoted context omitted.

> I'm pretty excited for this Aside from historical interest, why are you excited for it?

Personally, I think the whole C tangent was a misstep and would love to see Algo 68 turn into Algo 26 or 27. I sort of like C and C++ and many other languages which came, but they have issues. I think Algo 68 could develop into something better than C++, it has some of the pieces already in place. Admittedly, every language I really enjoy and get along with is one of those languages that produced little compared to t…

Wouldn't that be some form of Pascal?

Re: GCC SC approves inclusion of Algol 68 Front End

#74

Post by Levitating »

0xpgm wrote: post #23

In my mind this highlights something I've been thinking about, the differences between FOSS influenced by corporate needs vs FOSS driven by the hacker community. FOSS driven by hackers is about increasing and maintaining support (old and new hardware, languages etc..) while FOSS influenced by corporate needs is about standardizing around 'blessed' platforms like is happening in Linux distributions with adoption of Ru…

You don't think the movement to rust is driven by hackers?

Re: GCC SC approves inclusion of Algol 68 Front End

#75

Post by psychoslave »

themafia wrote: post #40
adrian_b wrote: post #39

Earlier quoted context omitted.

C had 3 major sources, B (derived from BCPL, which had been derived from CPL, which had been derived from ALGOL 60), IBM PL/I and ALGOL 68. Structs come from PL/I, not from ALGOL 68, together with the postfix operators "." and "->". The term "pointer" also comes from PL/I, the corresponding term in ALGOL 68 was "reference". The prefix operator "*" is a mistake peculiar to C, acknowledged later by the C language desig…

> it should have been a postfix operator, like in Euler and Pascal. I never liked Pascal style Pointer^. As the postfix starts to get visually cumbersome with more than one layer of Indirection^^. Especially when combined with other postfix Operators^^.AndMethods. Or even just Operator^ := Assignment. I also think it's the natural inverse of the "address-of" prefix operator. So we have "take the address of this value…

A dash instead of a dot would be so much more congruent with the way Latin script generally render compounded terms. And a reference/pointer (or even pin for short) is really nothing that much different compared to any other function/operator/method.

some·object-pin-pin-pin-transform is not harder to parse nor to interpret as human than (***some_object)->transform().

Re: GCC SC approves inclusion of Algol 68 Front End

#76

Post by svat »

chuckadams wrote: post #61
InfamousRece wrote: post #53

Will it compile Knuth’s test? https://en.wikipedia.org/wiki/Man_or_boy_test

That test is short enough to just paste it in here: begin real procedure A(k, x1, x2, x3, x4, x5); value k; integer k; real x1, x2, x3, x4, x5; begin real procedure B; begin k := k - 1; B := A := A(k, B, x1, x2, x3, x4) end; if k ≤ 0 then A := x4 + x5 else B end; outreal(1, A(10, 1, -1, -1, 1, 0)) end The whole "return by assigning to the function name" is one of my least favorite features of Pascal, which I suppose…

Yeah that's one of the things the test was designed to catch: at that point, B is a reference, to the B that is being defined. Here's a C++ translation from https://oeis.org/A132343 that uses identity functions to make the types consistent:

    #include 
    #include 
    using cf = std::function;
    int A(int k, cf x1, cf x2, cf x3, cf x4, cf x5)
    {
        int Aval;
        cf B = [&]()
        {
            int Bval;
            --k;
            Bval = Aval = A(k, B, x1, x2, x3, x4);
            return Bval;
        };
        if (k
So in the expression `A(k, B, x1, x2, x3, x4)`, the `B` there is not called, it simply refers to the local variable `B` (inside the function `A`), that was captured by the lambda (by reference): the same B variable that is currently being assigned.

Re: GCC SC approves inclusion of Algol 68 Front End

#77

Post by samus »

0xpgm wrote: post #23

In my mind this highlights something I've been thinking about, the differences between FOSS influenced by corporate needs vs FOSS driven by the hacker community. FOSS driven by hackers is about increasing and maintaining support (old and new hardware, languages etc..) while FOSS influenced by corporate needs is about standardizing around 'blessed' platforms like is happening in Linux distributions with adoption of Ru…

Rust is by no means allowed in the core yet, only as drivers. So far, there are only a few drivers. Currently, only the Nova driver, Google's Binder IPC and the (out of tree) Apple drivers are of practical relevance.

Re: GCC SC approves inclusion of Algol 68 Front End

#79

Post by LeFantome »

themafia wrote: post #49
adrian_b wrote: post #43

Earlier quoted context omitted.

The "natural inverse" relationship between "address-of" and indirect addressing is only partial. You can apply the "*" operator as many times you want, but applying "address-of" twice is meaningless. Moreover, in complex expressions it is common to mix the indirection operator with array indexing and with structure member selection, and all these 3 postfix operators can appear an unlimited number of times in an expre…

> You can apply the "*" operator as many times you want, but applying "address-of" twice is meaningless. This is due to the nature of lvalue and rvalue expressions. You can only get an object where * is meaningful twice if you've applied & meaningfully twice before. int a = 42; int *b = &a; int **c = &b; I've applied & twice. I merely had to negotiate with the language instead of the parser to do so. > and all these…

I do not think that is what they meant.

**c is valid but &&b makes no sense.

Re: GCC SC approves inclusion of Algol 68 Front End

#80

Post by dribblecup »

ALGO 68 (dc) was the go to language for Burrough's [6-8]x00 variants.

These were fairly popular for awhile and supported advanced features like multiprocessing. The demand for exercising the full range of capabilities was kind of niche but an "amateur", like myself, could make a few bucks if you knew ALGOL.

I used to have the grey manual for the Burrough's variant - I'll have to poke around to see if it's in the attic somewhere.

Post reply on HN