5 ms·

Parrot was implemented in C, and to my recollection implemented various iterations of bytecode syntaxes, notably PBC PBC was the bytecode format, the human rea

by cygx 9y ago

Parrot was implemented in C, and to my recollection implemented various iterations of bytecode syntaxes, notably PBC PBC was the bytecode format, the human readable low-level syntax was called PASM and the slightly higher-level synax was called PIR. Besides PIR, other languages still close to the metal were NQP versions (though I don't remember the exact relationship between NQP/NQP-rx/parrot-nqp) and eventually Winxed.

kbenson 9y ago
Ah, I figured that part was slightly off (since I knew PBC was bytecode and thus my waffling with "bytecode syntaxes"), but really didn't want to research the history I had already forgotten. Thanks for the correction. > Besides PIR, other languages still close to the metal were NQP versions (though I don't remember the exact relationship between NQP/NQP-rx/parrot-nqp) and eventually Winxed. I vaguely remember NQP/NQP-rx etc as being branches with reimplementations or new features, but I could be way off. I remember Winxed, but I'm not sure I realized Whiteknight implemented it at the same layer as NQP instead of on top of it. That would explain why some other new language implementations started using it instead of NQP, which I recall (e.g. I think someone started up a new Ruby on Parrot implementation after Winxed that used Winxed). I miss reading Whiteknight's blog posts on massive changes he was working on.
- cygx 9y ago
  Winxed was NotFound's brainchild, though I believe Whiteknight did push its usage. The way I remember it, the issue was that later versions of NQP moved towards greater backend independence and no longer mapped directly to Parrot VM semantics (eg 6model), so Parrot had to rely on older NQP version, making Winxed an attractive alternative.
  - kbenson 9y ago
    > Winxed was NotFound's brainchild, though I believe Whiteknight did push its usage. That's interesting. I'm not sure why I remembered it so strongly as Whiteknight's invention, but it probably has to do with how much he talked about it, and that my initial exposure to it was through his blog. > The way I remember it, the issue was that later versions of NQP moved towards greater backend independence and no longer mapped directly to Parrot VM semantics (eg 6model), so Parrot had to rely on older NQP version, making Winxed an attractive alternaive. That sounds likely. The whole situation was a clusterfuck. To my knowledge, some people are still really upset about it and how it played out (but at this point I don't really see how it could have gone any other way).
  - chromatic 9y ago
    That's close to what happened. The first relevant version of compiler tools were called PGE/TGE, written in PIR and based on the notion of attribute grammars and grammar engines. The first versions of NQP grew out of those. I believe early versions of NQP were hosted in the Parrot repo, but they started to be developed out of tree and eventually were completely hosted out of the tree. NQP was an improvement over PGE/TGE in many ways, so some of Parrot's internal tools were created in or ported to NQP. Eventually (I believe with NQP-rx), NQP forked into an incompatible version out of tree. As you mention, when the next incompatible revision of NQP was being planned, it was no longer an attractive target for Parrot, because it was: * developed out of tree * developed out of Parrot's release cycle * backwards incompatible * "backend independent" In particular, migrating existing, working Parrot tools to a new language which offered little beyond busywork to gain "backend independence" wasn't worth the effort. (Having NQP go unsupported for existing tools wasn't great either, especially given that one explanation for "backend independence" was that Parrot tools weren't evolving fast enough to support Rakudo features -- still feels like a circular argument.) I still maintain that it made little sense for Parrot to depend on an external project, evolving rapidly, offering little stability, with the express intent to obviate Parrot.

by cygx 9y ago

kbenson 9y ago

Ah, I figured that part was slightly off (since I knew PBC was bytecode and thus my waffling with "bytecode syntaxes"), but really didn't want to research the history I had already forgotten. Thanks for the correction. > Besides PIR, other languages still close to the metal were NQP versions (though I don't remember the exact relationship between NQP/NQP-rx/parrot-nqp) and eventually Winxed. I vaguely remember NQP/NQP-rx etc as being branches with reimplementations or new features, but I could be way off. I remember Winxed, but I'm not sure I realized Whiteknight implemented it at the same layer as NQP instead of on top of it. That would explain why some other new language implementations started using it instead of NQP, which I recall (e.g. I think someone started up a new Ruby on Parrot implementation after Winxed that used Winxed). I miss reading Whiteknight's blog posts on massive changes he was working on.

cygx 9y ago
Winxed was NotFound's brainchild, though I believe Whiteknight did push its usage. The way I remember it, the issue was that later versions of NQP moved towards greater backend independence and no longer mapped directly to Parrot VM semantics (eg 6model), so Parrot had to rely on older NQP version, making Winxed an attractive alternative.
- kbenson 9y ago
  > Winxed was NotFound's brainchild, though I believe Whiteknight did push its usage. That's interesting. I'm not sure why I remembered it so strongly as Whiteknight's invention, but it probably has to do with how much he talked about it, and that my initial exposure to it was through his blog. > The way I remember it, the issue was that later versions of NQP moved towards greater backend independence and no longer mapped directly to Parrot VM semantics (eg 6model), so Parrot had to rely on older NQP version, making Winxed an attractive alternaive. That sounds likely. The whole situation was a clusterfuck. To my knowledge, some people are still really upset about it and how it played out (but at this point I don't really see how it could have gone any other way).
- chromatic 9y ago
  That's close to what happened. The first relevant version of compiler tools were called PGE/TGE, written in PIR and based on the notion of attribute grammars and grammar engines. The first versions of NQP grew out of those. I believe early versions of NQP were hosted in the Parrot repo, but they started to be developed out of tree and eventually were completely hosted out of the tree. NQP was an improvement over PGE/TGE in many ways, so some of Parrot's internal tools were created in or ported to NQP. Eventually (I believe with NQP-rx), NQP forked into an incompatible version out of tree. As you mention, when the next incompatible revision of NQP was being planned, it was no longer an attractive target for Parrot, because it was: * developed out of tree * developed out of Parrot's release cycle * backwards incompatible * "backend independent" In particular, migrating existing, working Parrot tools to a new language which offered little beyond busywork to gain "backend independence" wasn't worth the effort. (Having NQP go unsupported for existing tools wasn't great either, especially given that one explanation for "backend independence" was that Parrot tools weren't evolving fast enough to support Rakudo features -- still feels like a circular argument.) I still maintain that it made little sense for Parrot to depend on an external project, evolving rapidly, offering little stability, with the express intent to obviate Parrot.