Live data from Hacker News

Modern Pascal is still in the race (2022)

blog.synopse.info

111–120 of 160 posts

Re: Modern Pascal is still in the race (2022)

#111
post #66

Earlier quoted context omitted.

I'm surprised that you draw a sharp distinction between C and Pascal syntax. They have a shared lineage and are really very close to each other. Yeah, curly braces won over "begin" and "end", but that's not a matter of some huge conceptual rift, just convenience. There are numerous languages today, including Haskell and Ocaml, that are far more removed from the Algol lineage than these two. Heck, the differences betw…

One huge difference between C and Pascal grammars us that Pascal is LR(1), so it can be parsed easily, which helps one-pass translation. It also helps humans read it. C, on the other hand, has needlessly complicated syntax; a function definition is hard to detect, and a pointer to a function is hard to interpret, because it's literally convoluted: https://c-faq.com/decl/spiral.anderson.html Sadly, this is a general s…

You misremember. Pascal's grammar is "easy" because it is LL(1), not LR(1)!

C is almost LR(1), if we allow prior declarations to decide how some tokens are classified, like whether an identifier is a variable or type name.

Declarations like

  void (*signal(int, void (*fp)(int)))(int);
are LR(1).

LR(1) sentences are harder to read than LL(1) because you have to keep track of a long prefix of the input, looking for right reductions (if you follow certain LR algorithms). LR parsing algorithms use a stack which essentially provides unlimited lookahead, in comparison to LL(1). Both LL(1) and LR(1) have one symbol of lookahead, but qualitatively it's entirely different because the lookahead in LR is happening after an indefinitely long prefix of the sentence which has not been fully analyzed, and has been shunted into a stack, to be processed later. Many symbols can be pushed onto the stack before a decision is made to recognize a rule and reduce by it. Those pushed symbols represent a prefix of the input that is not yet reduced, while the reduction is happening on the right of that. So it is backwards in a sense; following what is going on in the grammar is bit like understanding a stack language like Forth or PostScript.

An LL(1) grammar allows sentences to be parsed in a left to right scan without pushing anything into a stack to reduce later. Everything is decidable based on looking at the next symbol. Under LL(1), by looking at one symbol, you know what you are parsing; each subsequent symbol narrows it down to something more specific. Importantly, the syntax of symbols that have been processed already (material to the left) are settled; their syntax is not left undecided while we recognize some fragment on the right.

Under LR(1) it's possible for a long sequence of symbols to belong to entirely unrelated phrase structures, only to be decided when something finally appears on the right. A LALR(1) parser generator outputs a machine in which the states end up shared by unrelated rules. The state transitions then effectively track multiple parallel contexts.

Re: Modern Pascal is still in the race (2022)

#113
post #66

Earlier quoted context omitted.

One huge difference between C and Pascal grammars us that Pascal is LR(1), so it can be parsed easily, which helps one-pass translation. It also helps humans read it. C, on the other hand, has needlessly complicated syntax; a function definition is hard to detect, and a pointer to a function is hard to interpret, because it's literally convoluted: https://c-faq.com/decl/spiral.anderson.html Sadly, this is a general s…

You misremember. Pascal's grammar is "easy" because it is LL(1), not LR(1)! C is almost LR(1), if we allow prior declarations to decide how some tokens are classified, like whether an identifier is a variable or type name. Declarations like void (*signal(int, void (*fp)(int)))(int); are LR(1). LR(1) sentences are harder to read than LL(1) because you have to keep track of a long prefix of the input, looking for right…

> C is almost LR(1),

Does that include the C preprocessor?

Somehow, I recall someone here (maybe it was user walterbright) suggesting that implementing a C preprocessor was a lot of work - maybe months - so one might consider using Facebook's MIT licensed preprocessor:

https://github.com/facebookresearch/CParser

Re: Modern Pascal is still in the race (2022)

#114

I def have a soft spot for Pascal. And I think Niklaus Wirth deserves more recognition in broader circles for his foundational work with pcode, compilers, Oberon, etc. I learned Pascal like many of us growing up in the early PC era and never could look at BASIC the same way again (or respect Gates for his love of it, lol). I think having such a highly structured language at a young age did wonders. But these days fol…

> But these days folks are mostly used to the C style syntax. And I'm not even arguing that it is a better language than C or others. But the whole industry has gone overall into believing that anything newly 'invented' is good and anything that's been around a while is passé Problem of the Pascal syntax is that it prevents adoption of certain constructs, which are just not nice. A few examples - lambda expression: `…

> - lambda expression: `begin` ... `end`, say goodbye to nice one liners;

If there's one thing I would eliminate from programming, despite their benefits, is the one liner lambda expressions. It has turned clean, readable Python code into muddy statements I need to pause to compile in my head to understand.

I am not a fan.

Re: Modern Pascal is still in the race (2022)

#116

Earlier quoted context omitted.

> They are error prone, you can forget to unlock That's not a problem with mutexes but with resource management in some languages. In Rust mutexes use RAII and unlock automatically - you cannot accidentally forget to unlock.

Yes but it is very easy to hold mutexes locked longer than needed because you usually don't think about when stuff is dropped in Rust, you just let it go out of scope. I have gotten really annoying deadlocks because of this in the past.

Fair point, but in order to make a deadlock, you need a reference back to the object that holds the lock. And back references in Rust are hard to make. Most of the time if you unlock too late, you get a performance problem, not a deadlock.

Re: Modern Pascal is still in the race (2022)

#118

Earlier quoted context omitted.

Delphi was great but a major deal breaker was that is was not free to use.

For students and hobbyist, yes and was probably a dumb MBA lead decision because it stops the developer pipeline. OTOH, As many tool vendors will tell you its foolish to dismiss a tool simply based on price. If your paying your developers $100 an hour even tiny improvements in productivity can easily pay for a $1000 or more tool. Just the compilation speed alone vs C/etc is probably worth the 5+ mins a day in savings…

It is, but it stops a large number of people from being conversant with your tool and that in turn almost guarantees market failure. I've got a super luxurious toolchain on my computer because of the free software movement and it may not be as flashy as what you can get commercially but it suffices for all of my needs.

Re: Modern Pascal is still in the race (2022)

#119

I have lingering distain for Pascal, unlike other people here... In 1980 I was a freshman at UCSC, and the professors did not like C. So most classes used UCSD Pascal. While it apparently pioneered some cool ideas, it was not at all ready for industry use. The free function was just a suggestion, it didn't deallocate anything. Arrays were fixed size, and an array of size 80 was a different type than size 255 (and 255…

I think you meant Modula-2, in many ways a successor to Pascal.

https://en.wikipedia.org/wiki/Modula-2

Re: Modern Pascal is still in the race (2022)

#120

“In the race” What a terrible habit we have of speaking about our tools like they’re in competition with each other! I don’t think I’ll ever meet a carpenter who talks about their hammer or even their manual crank drill being “still in yhe race”. Tools have contexts where they might be used. Sometimes one tool will supersede another for all the day’s tasks, but tomorrow’s tasks will be different in unknown ways and w…

That's because it's a zero sum game and one of the reason why you see advocates for new languages fighting for market share attacking older languages because they know that only so much software gets written.
Post reply on HN