LWN: Comments on "Bison 3.3 released"

Bison 3.3 released

ballombe — Sun, 03 Mar 2019 14:25:14 +0000

After experimenting, bison --update change %name-prefix to define api.prefix, which breaks the API and leads to the project failing to compile anymore.
This makes this option fairly useless.

I hoped bison --update was something you could put in your Makefile to future-proof against the next bison change, but this is not the case.

Bison 3.3 released

branden — Wed, 06 Feb 2019 13:46:45 +0000

"Given the constraints of size on the PDP 11, anything but LR(1) was infeasable. But using ambiguous grammars and broadening the shift/reduce test to trest operator precedence fit right into that pattern. Another thing that I think was unique to Yacc at the time was introducing symbols that matched the empty string whose reduction caused program actions. Many similar parser systems at the time could not deal with these "empty" symbols." -- Steve Johnson

"So you're the reason (Plan 9) awk has 83 reduce-reduce conflicts (and
42 shift-reduce)." -- Rob Pike

"As I remember, the original EQN grammar had >300 S/R conflicts and 50 or so RR conflicts. But it mostly did what you wanted. I think Al Aho got faint when he looked it it, though... (It got better when precedence was added...)" -- Steve Johnson

Bison 3.3 released

mathstuf — Tue, 29 Jan 2019 21:57:48 +0000

> I am actually surprised that any developer does bother, to be honest. They can't be doing so willingly, surely (I get the "But we MUST have an iPad app" kind of forced development).

There's apparently lots of money to be had. People do lots of crazy things to get more of it.

But, I understand the sentiment.

Bison 3.3 released

quotemstr — Tue, 29 Jan 2019 17:10:45 +0000

Your comment is full of snark and says nothing. Even LALR(1) grammars can generate a token in multiple contexts, and you don't need to tolerate conflicts to do it. Any grammar you can express with conflicts you can express without them too.

Bison 3.3 released

Wol — Tue, 29 Jan 2019 16:59:33 +0000

There speaks a voice that has never worked in the real world ...

I always like to give as my example of trying to parse valid syntax

REM: REM = REM(6,2) ;* This calculates a remainder and puts it in the variable called REM

That is, if you haven't noticed, the token REM used in four different ways in the same statement - as a label, a variable, a function, and a statement. And all those uses are valid in differing dialects of the same computer language.

The option of designing the language/grammar is not always there for the poor sods trying to write the lexer/parser.

Cheers,
Wol

Bison 3.3 released

ledow — Tue, 29 Jan 2019 10:34:47 +0000

I followed the same path trying to develop for MacOS and gave up after a couple of working prototypes.

It just wasn't worth the effort trying to maintain a completely separate path that, without running the entire compilation on an up-to-date MacOS itself, wouldn't do even the simplest of things.

And I'm not prepared to pay Apple hardware prices just to run my own code.

I would have to say that, even if I made a living developing software, I would not even try to support Apple devices purely because of the developer interfaces. I am actually surprised that any developer does bother, to be honest. They can't be doing so willingly, surely (I get the "But we MUST have an iPad app" kind of forced development).

Pretty much the only way I could ever get anything to work reliably was to push XCode tools into Eclipse (which "just works" on Windows and Linux of several flavours) and run it natively on MacOS. Then, literally every time MacOS updated, compilation on un-updated machines would fail or apps couldn't be signed because things weren't up to date, which involved an OS update, which - after a while - required a hardware update.

And XCode doesn't work on any other platform, so you couldn't even go that way and just teach yourself that and move it to Windows/Linux.

Apple went out of their way to tell me that they don't want me using their platform. I took the hint, before I'd ever parted with a penny on anything they offered.

Bison 3.3 released

quotemstr — Mon, 28 Jan 2019 22:15:04 +0000

Annotating rules with expected conflicts is bogus and wrong. This approach is fragile and encourages a sloppy approach to language design. It's better to structure the grammar and add precedence rules so that these conflicts don't occur in the first place!

Bison 3.3 released

atai — Mon, 28 Jan 2019 19:08:32 +0000

Homebrew is great. Cannot be on MacOS without it

Bison 3.3 released

Cyberax — Mon, 28 Jan 2019 17:58:03 +0000

Lots of other companies have similar restrictions. For example, no consumer Amazon device ships with GPLv3.

Bison 3.3 released

zwol — Mon, 28 Jan 2019 16:05:50 +0000

Exactly. As of the original release of GPLv3, Apple's legal department believed that if they shipped any code under that license, they would have to make it possible for end users to install third-party patches to the core of iOS, because of the "anti-tivoization" language. So they didn't, and they still don't.

Source: I used to work for a company that had a contract from Apple to do maintenance on their fork of GCC. Right around the time the FSF started to circulate GPLv3 drafts for comment, Apple canceled our contract and plowed all the money into LLVM instead. This was the unofficial explanation they gave our sales lead.

Bison 3.3 released

mathstuf — Mon, 28 Jan 2019 15:29:09 +0000

I do pretty much all my actual development on Linux. I find it much easier to work with Windows and macOS by having a minimally viable editor available and git on the target machine. I'll test small fixes on the target machine, but bigger development is done in my main env and pushed around using git.

> Although if anyone knows how to do iOS dev on a Linux box, I'm all ears...

I almost had a cross-compilation setup done in 2008 or so by extracting an SDK and a using a cross compiling GCC. Ended up abandoning since I ended up just not caring about macOS at some point. Swift works on Linux now (and I suspect you could get a cross-compile capable setup pretty easily since it is LLVM-based), so that may be one way to do at least compile testing. Making the final package is probably always going to be on a macOS instance though since, AFAIK, the signing tools are macOS-specific. I assume Clang compiles Obj-C, so that may work as well.

Bison 3.3 released

ballombe — Mon, 28 Jan 2019 13:44:54 +0000

If they do not want to upgrade it, at least they could stop shipping it entirely.

Bison 3.3 released

oldtomas — Mon, 28 Jan 2019 08:55:45 +0000

I noticed that too (I think it was during that shellshock thing).

I always told people that this must be Steve Jobs's ghost haunting Apple. It still can't get over that GCC/Objective-C thing back then in NeXT times (I worked in a strange shop, where the desktop folks were Apple acolytes and the backend folks Windows worshippers).

Of course this was in jest, but sometimes I think companies do develop traits which are somehow similar to those people develop -- pathologies and all.

I'd say GPL phobia. GPLV2 they've to put up with (but they shell out quite a bit of money to get rid of that too), but GPLV3... nono. That's too much ;-)

Bison 3.3 released

josh — Mon, 28 Jan 2019 08:38:21 +0000

As far as I can tell, most FSF command line tools in macos are whatever was more or less stable in 2006

$ curl -s https://ftp.gnu.org/gnu/bison/bison-2.3.tar.bz2 | tar xjOf - bison-2.3/COPYING | head -n 2
		    GNU GENERAL PUBLIC LICENSE
		       Version 2, June 1991
$ curl -s https://ftp.gnu.org/gnu/bison/bison-2.4.tar.bz2 | tar xjOf - bison-2.4/COPYING | head -n 2
                    GNU GENERAL PUBLIC LICENSE
                       Version 3, 29 June 2007

Apple ships the last version released under GPLv2. Apple seems allergic to GPLv3 for some reason.

Bison 3.3 released

tshow — Mon, 28 Jan 2019 00:40:51 +0000

As far as I can tell, most FSF command line tools in macos are whatever was more or less stable in 2006, presumably (hopefully, I wouldn't bet real money on it...) with subsequent patches from apple. A couple of things (bash, emacs...) are 2007 snapshots. If you're stuck on macos and you need FSF tools, I'd suggest homebrew, since apple threw out the freebsd package manager.

Actually, if you need FSF tools I'd advise avoiding macos entirely, but you may be (as I am) stuck using it because it is the only point of access to a platform that pays the bills.

Although if anyone knows how to do iOS dev on a Linux box, I'm all ears...

Bison 3.3 released

ballombe — Sun, 27 Jan 2019 19:27:57 +0000

Both %error-verbose and %name-prefix are widely used settings that have already seen an interface change not so long ago (%error-verbose was YYERROR_VERBOSE, %name-prefix foo was %name-prefix=foo).

People needing to do bisections on old trees need the ability to rebuild older codebase without installing old bison releases too.

I am a bit concerned that it will be difficult to support both %name-prefix and api.prefix in the same code base, which means that bison --update will not work for this case.

MacOs still shipping bison 2.3 does not help either, though this is not bison dev fault.