在 2006/7/12 上午 1:12 時，Allison Randal via RT 寫到：
Audrey Tang wrote:
That is a sane argument, which is why I think punt-and-see has
some merit:
as soon as there is a workaround forced to be expressed at :immediate
level, we can evaluate it and see if it's better handled
declaratively.
Ex
Audrey Tang wrote:
That is a sane argument, which is why I think punt-and-see has some merit:
as soon as there is a workaround forced to be expressed at :immediate
level, we can evaluate it and see if it's better handled declaratively.
Excellent. (Er, though you know that .loadlib isn't reall
在 2006/7/12 上午 12:57 時，chromatic 寫到：
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.
Co
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 argum
在 2006/7/12 上午 12:51 時，Allison Randal via RT 寫到：
Chip Salzenberg wrote:
[*] Just what it _is_ intended for is an open question. I think
the user
base will answer it, if we let them, in time.
To give a concrete and immediately relevant example: the fact that
people are using :immedia
Chip Salzenberg wrote:
[*] Just what it _is_ intended for is an open question. I think the user
base will answer it, if we let them, in time.
To give a concrete and immediately relevant example: the fact that
people are using :immediate to load libraries at compile-time is a good
sign t
在 2006/7/12 上午 12:33 時，chromatic via RT 寫到：
Because people might write code, by hand, that does careless things
in :immediate subs?
Yes. This is the difference between forcing syntax highlighters,
security checkers,
dependency analyzers, and refactoring browsers to run rm-rf, and let
use
在 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 potent
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, b
On Tuesday 11 July 2006 21:09, Audrey Tang wrote:
> I really cannot argue with that argument (essentially "let's punt and
> see"); therefore this ticket is probably best reserved until Parrot actually
> has a security model, in which time I'll then argue that :immediate should
> be subjected t
在 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(
On Tue, Jul 11, 2006 at 11:52:10PM -0400, Bob Rogers wrote:
>Even so, I can't see how it would help to use :immediate to compile
> Common Lisp.
That's fine; some misconceptions to the contrary, that's not what it's
intended for.[*] It's an *analogue* of Perl's BEGIN; it's not intended to
be a
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 u
So far we have been enable to produce a use case that requires
unbounded evaluation
(typo, it's "unable" above.)
PGP.sig
Description: This is a digitally signed message part
在 2006/7/11 下午 11:52 時，Bob Rogers via RT 寫到：
But by "compile time" you both unambiguously mean "PIR compile time",
not "HLL compile time," since there's no HLL involved. But an HLL
compiler always has the option of building a PIR constant at HLL
compile
time [2], so that just leaves the case
From: Audrey Tang <[EMAIL PROTECTED]>
Date: Tue, 4 Jul 2006 23:54:30 -0400
. . .
Well, I'm curious, as the only dynamic language with this feature --
Perl5 namely -- does not target Parrot, and the current users of this
feature is out of necessity for working around the dynl
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'l
在 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 o
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
Re more powerful constant creation:
There's already a VTABLE method for constructing PMCs from STRINGs, e.g:
=item C
Class method to construct an array from the string representation C,
which is a string I<"(el0, el1, ...)">.
used for creating param/args signature arrays inside
src/pmc/fixedint
# New Ticket Created by Autrijus Tang
# Please include the string: [perl #39792]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39792 >
Currently :immediate in PIR serves two purposes: Running loadlib for
type lookups, an
21 matches
Mail list logo
