[Idea Bin] Port bash to Parrot

ChrisDolan on 2008-01-30T05:04:41

I'm going to use the "[Idea Bin]" flag to indicate ideas or projects that I would love to develop if I had more time, but realistically admit that I'll never finish. If you choose to use one of these ideas, you have my permission and best wishes.

An implementation of bash on Parrot would be a great test of Parrot's I/O capabilities. The source code for bash is fairly readable considering how arcane are some of its supported operations. Bash has a rather healthy test suite that could be reused during development.

I spent many commutes pondering possible names for such a port, but never came up with a great one. I wanted "posh" to work, but never came up with the right words for the acronym. "bashup" = bash-under-parrot felt too forced.

If such a parrot implementation would enable you to call out to other languages via namespace prefixes on functions, this could let shell be a better glue language than ever. You could incrementally port hairy shell scripts to more expressive programming languages.

Then you could switch all of your /etc/rc scripts to run under parrot by just changing the sharp-bang.

Furthermore, I've been a csh/tcsh user for 15 years and have always envied the power of bash, but never bothered learning more than the rudiments. This would be an excuse to learn it deeply.

---

Don't go sneaking away from the Java stuff

Alias on 2008-01-30T09:41:09

I saw that comment on perlbuzz! :)

As one of the only people with solid Java/Eclipse experience, who as also hacked PPI and Perl::Critic and has some idea of what things are actually possible, when do we get to see the journal entry that contracts the toolsets and suggests the bits that could be done for Perl reasonably.

Re:Don't go sneaking away from the Java stuff

ChrisDolan on 2008-01-30T13:49:20

I wrote up my Java tooling ideas last week on the Perl::Critic mailing list, but it was Warnocked.

I summary, I think perlcritic6 should split into two tools: one that analyzes byte code (and is thus language-agnostic) and one that analyzes source code. The former is easier, because the compiler has to do all of the worrying about optional grammars and BEGIN blocks.

Re:Don't go sneaking away from the Java stuff

Alias on 2008-01-31T04:55:35

I certainly agree that they are two different classes of tools...

If you look at something like the linting backend of Komodo, it does the whole "perl -c code" thing repeatedly.

Perhaps the problem with that sort of proposal is that it's easy for humans to understand what sorts of policies you can write for PPI-based stuff, because it "parses" the same way that humans do.

It's trickier to mentally understand how you do the same thing for bytecode, because many less people understand the code at that level.