Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug or feature? Probably bug with macros

0 views
Skip to first unread message

Joshua Isom

unread,
Dec 10, 2005, 6:53:57 PM12/10/05
to perl6-i...@perl.org
Since it's not documented at all that I've seen, either for or against,
I'm wondering what's the arguments to macros are supposed to be.
Consider this code.

--------------
.const int TRUE = 1
.const int FALSE = 0

.macro IfElse(conditional, foo, bar)
unless .conditional goto .$else
.foo
goto .$endif
.local $else:
.bar
.local $endif:
.endm

.sub main :main
.IfElse(TRUE,
print "True\n"
,
print "False\n"
)
.IfElse(FALSE,
print "True\n"
,
print "False\n"
)
.IfElse(FALSE, print "True\n", print "False\n")
.end
--------------
This will print True, then False, then False. Comma's aren't allowed
for any of the statements(and they can be multilined), even commented
out ones(which if this "feature" isn't a bug, that part is). By using
pir's syntax, a lot of commas are eliminated, so it's at least somewhat
of a practical thing. But since I doubt this is at all intended, is it
a bug?

Joshua

Leopold Toetsch

unread,
Dec 11, 2005, 5:14:27 AM12/11/05
to Joshua Isom, perl6-i...@perl.org

On Dec 11, 2005, at 0:53, Joshua Isom wrote:

> Since it's not documented at all that I've seen, either for or
> against, I'm wondering what's the arguments to macros are supposed to
> be. Consider this code.

> .sub main :main


> .IfElse(TRUE,
> print "True\n"
> ,
> print "False\n"
> )

This is at least astonishing. The argument lexer obiously just scans
for the next comma.

> --------------
> This will print True, then False, then False. Comma's aren't allowed
> for any of the statements(and they can be multilined), even commented
> out ones(which if this "feature" isn't a bug, that part is). By using
> pir's syntax, a lot of commas are eliminated, so it's at least
> somewhat of a practical thing. But since I doubt this is at all
> intended, is it a bug?

Or an undocumented feature. And untested. Dunno if we should keept it.

> Joshua

leo

Joshua Isom

unread,
Dec 11, 2005, 5:45:23 PM12/11/05
to perl6-i...@perl.org
It could be very beneficial for debugging. My debugger tends to be a
lot of print statements, so something like

.globalconst int DEBUG = 1
.macro IfDebug(level, code)
unless .level >= DEBUG goto .$endif
.code
.local $endif:
.endm

.IfDebug(1,
print "var = "
print var
)

would be useful, but nevertheless, pir statements that span multiple
lines is just weird to me. I think I'm most surprised about that. Is
it odd that I find the fact that it allows multiple lines more
surprising than allowing code?

Leopold Toetsch

unread,
Dec 11, 2005, 6:30:47 PM12/11/05
to Joshua Isom, perl6-i...@perl.org

On Dec 11, 2005, at 23:45, Joshua Isom wrote:

> It could be very beneficial for debugging. My debugger tends to be a
> lot of print statements, so something like
>
> .globalconst int DEBUG = 1
> .macro IfDebug(level, code)
> unless .level >= DEBUG goto .$endif
> .code
> .local $endif:
> .endm
>
> .IfDebug(1,
> print "var = "
> print var
> )
>
> would be useful, but nevertheless, pir statements that span multiple
> lines is just weird to me. I think I'm most surprised about that. Is
> it odd that I find the fact that it allows multiple lines more
> surprising than allowing code?

As said, it was surprising me too. Anyway, I think typical use cases
are debugging and I prefer a solution that boils down to no code at all
for the non-debug case, like C's assert with -DNDEBUG.

With a bit of generalization we could have some -Ddefine [1] stuff that
{en,dis}ables lexing of lines within the scope of that define.

[1] -D\d+ is used for debugging, -D[a-zA-Z\w*] is still avaiable for
define (or we change current -D)

leo

Chip Salzenberg

unread,
Dec 12, 2005, 1:55:02 PM12/12/05
to Leopold Toetsch, Joshua Isom, perl6-i...@perl.org
On Mon, Dec 12, 2005 at 12:30:47AM +0100, Leopold Toetsch wrote:
> On Dec 11, 2005, at 23:45, Joshua Isom wrote:
> >.IfDebug(1,
> > print "var = "
> > print var
> >)
>
> As said, it was surprising me too. Anyway, I think typical use cases
> are debugging and I prefer a solution that boils down to no code at all
> for the non-debug case, like C's assert with -DNDEBUG.

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.

* On the other hand, conditional compilation is cheap & helpful, so
why not?

* 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.

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
})

--
Chip Salzenberg <ch...@pobox.com>

Will Coleda

unread,
Dec 12, 2005, 2:07:41 PM12/12/05
to Chip Salzenberg, Leopold Toetsch, Joshua Isom, Perl 6 Internals

On Dec 12, 2005, at 1:55 PM, Chip Salzenberg wrote:

> On Mon, Dec 12, 2005 at 12:30:47AM +0100, Leopold Toetsch wrote:
>> On Dec 11, 2005, at 23:45, Joshua Isom wrote:
>>> .IfDebug(1,
>>> print "var = "
>>> print var
>>> )
>>
>> As said, it was surprising me too. Anyway, I think typical use cases
>> are debugging and I prefer a solution that boils down to no code
>> at all
>> for the non-debug case, like C's assert with -DNDEBUG.
>
> 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.
>
> * On the other hand, conditional compilation is cheap & helpful, so
> why not?
>
> * 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.
>
> So I guess we just need a robust multi-line quoting convention (to
> pass multiple lines of code to macros).

That sounds suspiciously like a HEREDOC.

See: http://rt.perl.org/rt3/Ticket/Display.html?id=37600, which was
marked as rejected.

Chip Salzenberg

unread,
Dec 12, 2005, 2:14:32 PM12/12/05
to Will Coleda, Leopold Toetsch, Joshua Isom, Perl 6 Internals
On Mon, Dec 12, 2005 at 02:07:41PM -0500, Will Coleda wrote:
> On Dec 12, 2005, at 1:55 PM, Chip Salzenberg wrote:
> >So I guess we just need a robust multi-line quoting convention (to
> >pass multiple lines of code to macros).
>
> That sounds suspiciously like a HEREDOC.
>
> See: http://rt.perl.org/rt3/Ticket/Display.html?id=37600, which was
> marked as rejected.

That's worth reconsidering. I still think heredocs were a botch for
Perl, which is generally not line-oriented. But PIR is definitely
line-oriented, so it's not quite as much of a botch there.
--
Chip Salzenberg <ch...@pobox.com>

Roger Browne

unread,
Dec 12, 2005, 2:58:32 PM12/12/05
to perl6-i...@perl.org
On Mon, 2005-12-12 at 10:55 -0800, Chip Salzenberg wrote:

> Forbidding commas in the expanded code is not OK

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.

The same rule can apply for the closing right-parenthesis.

So we can have:

.IfDebug(stuff1, stuff2)

or

.IfDebug(1,
multi,line
stuff,with,commas
,
stuff_with_{braces}
stuff(with)parentheses
)

With this convention, there's no need for extra syntax such as braces.

Regards,
Roger Browne

Joshua Isom

unread,
Dec 12, 2005, 3:54:39 PM12/12/05
to perl6-i...@perl.org

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

Larry Wall

unread,
Dec 12, 2005, 5:53:28 PM12/12/05
to Perl 6 Internals
On Mon, Dec 12, 2005 at 11:14:32AM -0800, Chip Salzenberg wrote:
: I still think heredocs were a botch for

: Perl, which is generally not line-oriented.

Hmm, well, the point is not so much whether Perl is line-oriented,
but whether the *data* is line-oriented. The orientation of Perl
is to go the extra mile to accomodate the data in whatever form is
convenient to the user. See also Vicarious Suffering.

That's not to say that Perl 5's heredocs can't be improved, of course...

Larry

0 new messages