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

[perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const

2 views
Skip to first unread message

Leopold Toetsch via RT

unread,
Jul 11, 2006, 4:32:34 PM7/11/06
to perl6-i...@perl.org
Re more powerful constant creation:

There's already a VTABLE method for constructing PMCs from STRINGs, e.g:

=item C<PMC new_from_string(STRING *rep, INTVAL flags)>

Class method to construct an array from the string representation C<rep>,
which is a string I<"(el0, el1, ...)">.

used for creating param/args signature arrays inside
src/pmc/fixedintegerarray.pmc.

Autrijus Tang

unread,
Jul 11, 2006, 4:12:57 PM7/11/06
to bugs-bi...@rt.perl.org
# New Ticket Created by Autrijus Tang
# Please include the string: [perl #39792]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39792 >


Currently :immediate in PIR serves two purposes: Running loadlib for
type lookups, and for initializing
PMC constants that cannot be expressed in .const syntax. Note that
both are independent of environment.

I propose a new pragma, .loadlib, that implements the first need.

The .const syntax can be extended to express structured constants,
perhaps in a restricted set of
semantics that allows only PMC initialization and give it explicit
names, instead of the current
dubious use of a subroutine name as a constant PMC name.

The win here is that 3rd-party tools, as well as humans, can see hich
libs a .pir is loading, and
which constants it's playing with, _without_ running Parrot
instructions that can rm-rf the hard disk.

If this proposal is accepted, we can convert existing :immediate uses
to use it. We can then leave
:immediate alone with clear wording saying "deprecated, use .loadlib
and .const -- if you think you
have a legitimate use to it, let us know, and we can un-deprecate
it", instead of removing it outright.

The reason for deprecation is that unlike Perl 5, where BEGIN and
INIT are often run in the same
process, Parrot has a much better design that makes .pbc platform-
independent. In that case, any
runtime-environment-dependent code in :immediate will be referring to
the _COMPILING_
instance, not the _RUNNING_ instance, and the mistake of writing
BEGIN when one should be
writing INIT (that is, :immediate instead of :init) is costly.

The drawbacks of the current :immediate implementation include:

- Nobody has a use of PIR :immediate for any unbounded (i.e.
interacting-with-environment) evaluation
- As an intermediate language, the languages targeting it should
handle BEGIN in that level, not PIR level
- It destroys the assumption of the same .pir compiling to the
same .pasm
- There is no way to "merely assemble" .pir into .pbc without the
potential of rm -rf.
- It makes writing a transformer/analyzer for full .pir impossible in
other languages

Thanks,
Audrey

PGP.sig

Chip Salzenberg

unread,
Jul 11, 2006, 7:31:36 PM7/11/06
to perl6-i...@perl.org
Leaving :immediatein PIR doesn't actually introduce any problems that we
didn't already have (and can't escape anyway).

There's a PIR file already in svn somewhere in Parrot where a :immediate
function is used to build a large table programmatically at compile time, so
that at runtime it's already completely available. That's neat.

Now think about the alternatives if your goal is to have the table ready to
go at runtime without any computational overhead at all, e.g. a CRC table.

It could be done with a separate program running outside Parrot to generate
source code, the traditional approach for such things. The form of the
output could be your DSL or not, doesn't matter. The point is, that table
has to be generated at compile time, somehow, and that takes running code
that the user wrote. User code that may have side-effects.

Thus, the key inescapable attribute of any build process that includes the
compile-time preparation of application-specific data, whether it's inside
Parrot or a Perl script called from 'make', is this:

** a user-written program is running at compile time **

and you simply cannot escape that. If you kill :immediate {and don't tell
me "deprecate", you want to kill it} the same things happen that you
complain about, they just happen outside the Parrot VM where I think you
think you can ignore them, but they're still there, still part of the whole
compilation process. Any program-generating script has all the
disadvantages you list for :immediate, and it's less convenient to boot.

Ergo, :immediate is not actually creating any problems for you in your
functional-modeling problem. The problems are inherent to user code running
at compile time. If you need to start and stop a new Parrot VM each time,
well, that's no different in principle from a programmer typing "make
distclean" to remove all the intermediate products of autoconf or op2c.pl or
whatever.
--
Chip Salzenberg <ch...@pobox.com>

Audrey Tang

unread,
Jul 11, 2006, 9:59:12 PM7/11/06
to parrotbug...@parrotcode.org

在 2006/7/11 下午 7:33 時,Chip Salzenberg via RT 寫到:

> Now think about the alternatives if your goal is to have the table
> ready to
> go at runtime without any computational overhead at all, e.g. a CRC
> table.

And if we can restrict :immediate using some security principal in
the future so
it can only do things that are not destructive -- and always yield
the same result
-- in other words, do not depend on the environment, then this use
would be totally fine.

Your example is well within the realm of pure evaluation, and does
not make use of
unbounded (environment-dependent) evaluation. But I think this
ticket can be morphed
into "once the security sandboxing is here, prevent :immediate to do
something silly".

Would you agree with that? I can create another ticket for .loadlib.

Thanks,
Audrey

PGP.sig

Leopold Toetsch

unread,
Jul 11, 2006, 10:03:40 PM7/11/06
to Chip Salzenberg, perl6-i...@perl.org
On Tue, Jul 11, 2006 at 04:31:36PM -0700, Chip Salzenberg wrote:
>
> There's a PIR file already in svn somewhere in Parrot where a :immediate
> function is used to build a large table programmatically at compile time, so
> that at runtime it's already completely available. That's neat.

Yep. It'll probably doesn't effect the bench time much, but it's used in
examples/shootout/revcomp.pir:

# create tr table at compile-time
# tr{wsatugcyrkmbdhvnATUGCYRKMBDHVN}
# {WSTAACGRYMKVHDBNTAACGRYMKVHDBN};

.sub tr_00_init :immediate
...
.return(tr_array)
.end

> Now think about the alternatives if your goal is to have the table ready to
> go at runtime without any computational overhead at all, e.g. a CRC table.

I think tha main problem are side-effects and compile-time vs. run-time
differences in e.g. math libs. Maybe we can sanitize the evil thing a bit :-)

My mind is split WRT :immediate, heck, I did implement it, OTOH I can forsee
a lot of answers:
- "I'm reading a file within an :immediate Sub" -
- "Don't do that then"

leo

Chip Salzenberg

unread,
Jul 12, 2006, 12:22:06 AM7/12/06
to Audrey Tang, parrotbug...@parrotcode.org
On Tue, Jul 11, 2006 at 09:59:12PM -0400, Audrey Tang wrote:
> ?b 2006/7/11 ?U?? 7:33 ???AChip Salzenberg via RT ?g???G

> >Now think about the alternatives if your goal is to have the table ready
> >to go at runtime without any computational overhead at all.

>
> And if we can restrict :immediate using some security principal in the
> future so it can only do things that are not destructive -- and always
> yield the same result -- in other words, do not depend on the environment,
> then this use would be totally fine.

But that's impossible, as you know well if you just think it through.

'Dependence on the environment' may not be a characteristic of mathematically
perfect functional models, but it *is* a characteristic of *all* real
programs running in the real world on real hardware. It cannot be avoided,
no matter what changes we make and how carefully we try to create 'pure and
ideal' computation.

For example: What if the IEEE FP of the compilation machine differs slightly
from the target machine, so that you get -0 instead of 0 or Inf instead of
NaN? What if the Parrot versions of compiler and runtime differ slightly so
that the C code behind multi sqrt(Float) isn't the same on the compiler as on
the target machine? What if the CPU's been upgraded and the new Pentium
suddenly knows how to do long division? What if we alter the hash ordering
so the data structure building code produces different results?

You think :immediate is a bug. It isn't. It's a messenger of Eris, and
Fred Brooks is singing in its choir. I hear him now:

"90% of debugging is answering various forms of the question,
'Which program is this?'"

In short, to say that :immediate is unpredictable is to make a null
statement, because in practice, all computation is unpredictable.
--
Chip Salzenberg <ch...@pobox.com>

Chromatic

unread,
Jul 12, 2006, 12:39:20 AM7/12/06
to perl6-i...@perl.org, Audrey Tang
On Tuesday 11 July 2006 21:29, Audrey Tang wrote:

> Yes. And it is the designer's choice to introduce unpredictability into
> the PIR level. If the designer allows rand() inside :immediate, it's
> the designer's call; if the designer allows rm -rf, it's again the
> designer's call.

I'm sorry, but that's a *stupid* argument.

If I write that code by hand with :immediate and compile it myself to PBC, it
runs on my system. Damage to the universe: fairly minimal.

If I write that code in :init and compile it myself to PBC, it doesn't run on
my system. It runs on every system that runs the PBC I distribute. Damage
to the universe: slightly greater.

To follow this argument logically, I don't see alternatives besides
removing :init or sandboxing all potentially destructive operations -- and I
have plenty of Perl 5 code that legitimately deletes files in BEGIN blocks as
evidence that this potential sandboxing is a fairly undecidable operation.

Please discard the histrionics; you're poisoning the well.

-- c

Audrey Tang

unread,
Jul 12, 2006, 12:29:04 AM7/12/06
to Chip Salzenberg, parrotbug...@parrotcode.org

在 2006/7/12 上午 12:22 時,Chip Salzenberg 寫到:

> In short, to say that :immediate is unpredictable is to make a null
> statement, because in practice, all computation is unpredictable.

Yes. And it is the designer's choice to introduce unpredictability into


the PIR level. If the designer allows rand() inside :immediate, it's
the
designer's call; if the designer allows rm -rf, it's again the
designer's

call. There are degrees of unpredictability, and currently there is no
evidence that we require any of it in hand-written PIR code.

You ruled that we wait to see if a use case come up; that is fine
with me.
And hey, even if we reach consensus, there is no security model yet to
implement any of this on, so I prefer to have this discussion when
Parrot
can actually tell rm-rf apart from rand().

Thanks,
Audrey

PGP.sig

Audrey Tang

unread,
Jul 12, 2006, 12:45:53 AM7/12/06
to parrotbug...@parrotcode.org

在 2006/7/12 上午 12:40 時,chromatic via RT 寫到:

> To follow this argument logically, I don't see alternatives besides
> removing :init or sandboxing all potentially destructive operations
> -- and I
> have plenty of Perl 5 code that legitimately deletes files in BEGIN
> blocks as
> evidence that this potential sandboxing is a fairly undecidable
> operation.

I would like to see a single one example of that code.

> Please discard the histrionics; you're poisoning the well.

No. If you think PIR is a language for people to write manually to
code applications in,
_and_ it has some legitimate use for deleting files in :immediate
blocks, then your argument
may make some sense. As you failed to produce even one example, I
cannot see your point.

Thanks,
Audrey

PGP.sig

Chromatic

unread,
Jul 12, 2006, 12:57:39 AM7/12/06
to perl6-i...@perl.org, Audrey Tang
On Tuesday 11 July 2006 21:45, Audrey Tang wrote:

> If you think PIR is a language for people to write manually to
> code applications in, _and_ it has some legitimate use for deleting files
> in :immediate blocks, then your argument may make some sense.

Come on, Audrey! That's a strawman argument. The point is emphatically NOT
that people should be able to delete files in :immediate blocks.

As I said in my previous message, the same problem potentially exists
with :init -- and saying "OH NO THE PARROT DESIGNERS WANT TO REMOVE YOUR HARD
DRIVE!! THEY ARE EVIL AND WRONG (and they break static analysis)" is not
productive.

Please stop it.

-- c

Audrey Tang

unread,
Jul 12, 2006, 1:07:23 AM7/12/06
to chromatic, perl6-i...@perl.org

在 2006/7/12 上午 12:57 時,chromatic 寫到:

No. With :init, the step of .pir->.pbc, as well as all tools that
works with
.pir without running it -- including the very important "parrot -o"
-- are safe.

The :init is part of the run time. We already know that the runtime
needs a
sandbox at some point. What we don't know is that why the PIR
compiler --
supposedly something that's run only when HLL compilation is done --
would
need a special feature for hand-written code alone, and very error-
prone at that.

I can see use cases for :init to interact with the user's
environment; I cannot
see use cases for :immediate to interact with who-knows-what's
environment,
and break the otherwise intact "same .pir compiles to the same .pbc
on the same
environment" property.

Allison and Chip already elected to wait a while and see if someone
finds a
use for it, that actually requires unbounded evaluation. I now agree
with them.

> Please stop it.

Er, that's what I'm planning to do.

Thanks,
Audrey

PGP.sig
0 new messages