I was already talking to Leo offline a bit about refactoring some of the IMCC syntax. We have incrementally added some features at different times that could be handled with a more compact syntax if we rework it.
1) Combine .pcc_sub and .sub and go back to using the single keyword .sub.
*This means we will have to add extra qualifiers so IMCC knows what sort of sub it is.
Examples might be:
# Prototyped, continuation calling convention
# Continuation calls (or standard Parrot call as we could call it) should
# probably be the default in absence of the keyword
.sub foo pcall prototyped# Non-prototyped, standard stack call .sub bar stdcall
2) Given a subroutine's call convention based on a) Its prototype b) The default in absence of a prototype
we should be able to generate whatever specific code
for that calling convention without making the PIR look
much different for each one3) Keep PIR syntax as simple as possible with as few directives
and features.We should at least have an on-list discussion about how the new syntax should look before we rework it.
-Melvin
At 08:36 AM 10/12/2003 -0700, Gregor N. Purdy wrote:
Is there any good reason why prototyped PCC subs shouldn't be callable with IMC syntax that looks like a macro call, without having to make a macro wrapper manually? (I know its not the way it works now, but you can almost simulate it with a PCC sub def and a macro, and it seems to me it would be nice if it was free instead) It would make code more readable...
.pcc_sub _howdy prototyped .param str who print "Hello, " print str print "!\n" .end
...
_howdy("partner")
It would be better still if it could handle at least single return values, too. It would make the IMC stuff I'm writing much more readable and easier to write, too...
If that wouldn't be considered a mis-feature, does anyone have a good feeling for how hard it would be to adjust the IMC syntax and update the compiler?
Regards,
-- Gregor
-- Gregor Purdy [EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
