Thanks for asking. ^_^ (And thanks for any patience you haven't lost! XD )
Penknife's a programming language. I have a very specific opinion of what programming languages will become (http://arclanguage.org/item?id=12993), and I'm making Penknife in the hope that it's a well-designed first foray into that world—well-designed in the gemlike sense of not being everything to everybody but being as flawless as possible for what it is. Penknife has two very specific purposes:
- To have a customizable syntax that's fine at the start but almost limitlessly excellent once it's been customized.
- To be great at code generation, so that even if you think you want to use another language, you're likely to be more productive if you generate that code using Penknife instead.
The point is for Penknife to be a language useful to as many people as possible for as long as possible, so that it can continue to be more and more useful as its library support improves. This is sort of a world domination plot, but it isn't really (I promise :-p ). Penknife will probably only dominate syntax design (not platform design, where security and performance are hot topics), and even then it'll probably only dominate sequence-of-commands-style syntax design (the kind good at REPLs, as opposed to the landscape-of-declarations style good in IDEs). Even then, there'll be people who can't stand the foundations upon which their code generators are built; you can't please everyone. That being said, I think Penknife does stand a very real chance of monopolizing a big segment of the programming experience, so I think it's important for a gemlike language to get there first, before a hackish one has the benefit of entrenchment.
To minimize the number of fiddly mistakes (and other hackishness) in Penknife, any complexity-introducing feature that's only rarely needed for the above purposes is to be left out. Two examples are reentrant continuations and concurrency. A lack of continuation support may force certain syntaxes to be implemented without the help of continuations for coroutines or backtracking, and a lack of concurrency may hobble some theorem-proving-heavy compilers, but I doubt that'll be everyday Penknife programming. When such a nightmarish situation does come up, it's probably time to use an FFI or system call, and since you can use Penknife to generate the program you're calling that way, it shouldn't be too bad. :-p
It's quite a bit arrogant of me to think Penknife will be gemlike anytime soon, let alone that it'll still be seen as gemlike in the future. I'm still in the process of adding language features I dearly hope won't make it to the final product in their current form. Still, I think I'm the person who best knows where the heck I'm going with this project, and I intend to use Penknife myself all the time, so I'm following my passion. Feedback and help are welcome, of course!
For syntax experimentation, my favorite existing language is Arc. The Arc Forum community's very particular about every little syntactic detail. :-p So it should be no surprise that Penknife's design borrows heavily from things I like about Arc, while fixing things I don't like. For instance:
- Infix syntax is now seamless with the language. Penknife infix operators follow the normal scoping rules, as shown in the example.
- Penknife syntaxes take arbitrary []-balanced textual code, not just s-expressions, as their bodies. This allows for custom syntaxes to behave the same way as built-in "literal" syntaxes like q[...]. Case in point: the example's sym macro.
- Penknife has a hygienic macro system built on top of its more general-purpose syntax system (although only this high-level macro system is exposed to Penknife for now, and I'm pretty sure it's buggy despite it currently passing every test I've come up with :-p ). It's designed to work harmoniously with a module system I've also been working on. I consider both hygiene and modules to be scoping issues, so I aim to tackle them using environments, and given that premise, I figure a module import is going to be a matter of replacing the interaction environment with a local environment that shadows it, so I generally try to minimize the idea that there's a global environment at all when I can. Thus, for hygiene's sake across modules, I have each macro capture its lexical environment like a closure, and this is why [let arcsym arc.sym [mac* ...]] works in the example.
The next step is finishing up the rest of the features needed for fundamental syntax customization, especially the module system and a standard library. Then it's a matter of developing Penknife applications and seeing what happens.
Thanks a lot for the prompt and accurate response! ^^; Within hours of the question, I'd composed most of a fairly substantial response, but since then I've been too busy and/or tired to finish it up and post it. Thanks for taking the initiative to give the short version. :)
