On Dec 12, 2005, at 12:55 PM, Chip Salzenberg wrote:
Hm. Pondering... * PIR is primarily a compiler target, not a human language. (Pasm, in contrast, is an entirely non-human language.) So convenience is not paramount.
But people will write in it. There are programmers who write their code only in assembly, such as at <http://www.int80h.org/>, and there's an operating system written solely in assembly. Just because it's not intended doesn't mean it won't happen. And since so few languages as of yet target parrot, and many libraries are written in pir, wouldn't it be helpful to easy development of pir?
* On the other hand, conditional compilation is cheap & helpful, so why not?
Since it's a macro, it's still compiled, it's just not executed depending on debug level for this example. The IfElse example, for instance, translates into the expected if else statement in pir for if the register is a true value. As a result, readability is improved.
* Forbidding commas in the expanded code is not OK. And requiring backwhacked commas isn't OK either: too ugly, too much work to add and remove conditionals around existing code.
Forbidding commas as macros are defined is to be expected. The biggest issue with commas that I've seen is that inside a comment, the commas are not commented out in regards to parsing the macro. Escaped commas wouldn't necessarily be a horrible idea because a lot of pir code doesn't require them, but having to backslash them if added into a macro and taking out those backslashes if taken out of the macro would be prone to forgetfulness. Plus since no other part of pir allows backslashing except inside a string, I think it'd also add a level of confusion.
So I guess we just need a robust multi-line quoting convention (to
pass multiple lines of code to macros). (Musing while typing:) How
about using braces as balanced delimeters when an open brace is the
first character:
.IfDebug(1, {
multi,line
stuff,with,commas
and even {nested} braces
goes
here
})
It reminds me of passing an anonymous subroutine in perl, which is almost what the macro effect is... But it's still a little odd looking.
On Dec 12, 2005, at 1:58 PM, Roger Browne wrote:
So why not treat the comma as a delimiter only when either (1) It is on the same line as the start of the macro call, or (2) it appears alone on a line.
Then it'd also need (3) it begins a line, and any others on that line. But under the current syntax, at the end is allowed to, although to be accurate, they're allowed anywere.
I like the ability to pass code into a macro, since it adds a lot. I've attached a set of file to demonstrate adding HLL constructs to PIR easily. A note, since newlines are included in what's passed to the macros, any conditional needs a comma following it, not a newline.
hllmacros.pir
Description: Binary data
