On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
Relative is the usual apposite to absolute, but we have a three-way
logic here, so appositives don't really work. I think that hll is the
best I can think of, and given the existing .HLL directive, its meaning
is immediately
On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
Relative is the usual apposite to absolute, but we have a three-way
logic here, so appositives don't really work. I think that hll is the
best I can think
On Mon, Jul 10, 2006 at 02:53:15PM -0700, Chip Salzenberg wrote:
On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
Relative is the usual apposite to absolute, but we have a three-way
logic here, so
Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Mon, Jul 10, 2006 at 02:53:15PM -0700, Chip Salzenberg wrote:
On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
Relative is the usual apposite to absolute, but
Chip Salzenberg wrote:
Hrm. Relative is the usual apposite to absolute, but we have a three-way
logic here, so appositives don't really work. I think that hll is the
best I can think of, and given the existing .HLL directive, its meaning
is immediately clear:
I like that.
Seems to me
On Mon, Jul 10, 2006 at 06:57:06PM -0700, Matt Diephouse wrote:
Patrick R. Michaud [EMAIL PROTECTED] wrote:
I really like both of these suggestions. We also noted on #parrot that
get_hll_global would really simplify things for the Tcl folks, which
currently go through a macro to achieve the
On Mon, Jul 10, 2006 at 07:22:21PM -0700, Allison Randal wrote:
Chip Salzenberg wrote:
I think that hll is the best I can think of, and given the existing
.HLL directive, its meaning is immediately clear:
I like that.
Great!
Seems to me that we should have get_namespace patterned just
On Thu, Jul 06, 2006 at 05:39:45PM -0700, jerry gay wrote:
am i silly to think that if i'm looking for globals from the current
namespace, they're just as likely to be found closer to the namespace
root, than further away? perhaps something like
.namespace [ 'Foo'; 'Bar' ]
$P0 =
{ Language implementors, please know I'm going to do everything I can to
make every commit break nothing. I did pretty well when I made namespace
[''] stop being [] -- I fixed all the HLLs in the selfsame patch, except
two bits of code generation in TGE and PGE, which I fixed when they were
Chip Salzenberg [EMAIL PROTECTED] wrote:
{ Language implementors, please know I'm going to do everything I can to
make every commit break nothing. I did pretty well when I made namespace
[''] stop being [] -- I fixed all the HLLs in the selfsame patch, except
two bits of code generation
Chip Salzenberg wrote:
Well, I see a lot to like about this, but (and you knew there was a but
(but that's my job now :-))), in descending order of difficulty:
And you do it so well. Thank you. :)
* The division into two categories (global and symbol) leaves the third
category (current
Matt Diephouse wrote:
So for the runtime (this is the HLL runtime, not the PIR runtime, btw)
we're all set. Arrays fill the need perfectly and let us access the
root HLL namespace. That makes me think that we don't need any new
opcodes.
Chip's latest simplification eliminates the need for
Chip Salzenberg wrote:
--- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED --
On the other hand, we could extend the key PMC to represent emptiness,
i.e. zero dimensions. This seems useful for namespaces and could even prove
useful for real keys. And this makes keys even more compatible
On Thu, Jul 06, 2006 at 01:21:08AM -0700, Allison Randal wrote:
The problem is really that we're trying to simultaneously a) refer to
the root HLL namespace directly, and b) pretend that it doesn't exist.
I don't think (b) is quite true. It's more that we're avoiding explicit
re-coding of a
Allison Randal wrote:
I had a much longer reply, but I'm going to let it steep overnight and
see what percolates.
I ran through a number of possibilities, but so far my favorite is:
find_global and store_global are truly 'global', that is, they always
require a fully specified namespace,
Chip Salzenberg wrote:
On Thu, Jul 06, 2006 at 01:21:08AM -0700, Allison Randal wrote:
The problem is really that we're trying to simultaneously a) refer to
the root HLL namespace directly, and b) pretend that it doesn't exist.
I don't think (b) is quite true. It's more that we're avoiding
On Thu, Jul 06, 2006 at 12:11:47PM -0700, Allison Randal wrote:
It's essentially the linguistic problem of being able to refer to
something both by its full name and by the pronoun it. (Otherwise known
as topic.) Only, currently it isn't represented by a word.
Well, we have three distinct
{ All you HLL implementors and other PIR users out there, please be assured
that I'll be providing as easy a transition as possible when/if these global
opcodes are adjusted. }
On Thu, Jul 06, 2006 at 11:53:59AM -0700, Allison Randal wrote:
I ran through a number of possibilities, but so far
On 7/6/06, Chip Salzenberg [EMAIL PROTECTED] wrote:
So here's an illustrative suggestion, which I think is a variant on one of
your also-rans, albeit one that leaves the common HLL case unmarked:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_cur_global 'x'
Allison Randal [EMAIL PROTECTED] wrote:
Chip Salzenberg wrote:
--- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED --
On the other hand, we could extend the key PMC to represent emptiness,
i.e. zero dimensions. This seems useful for namespaces and could even prove
useful for real keys.
On Sat, Jul 01, 2006 at 03:04:05PM -0700, Matt Diephouse wrote:
Chip Salzenberg [EMAIL PROTECTED] wrote:
.namespace # no key
means the HLL root.
That resolves the other ticket I opened yesterday (good). But I'd
prefer to have C .namespace [] so that we could also have the
matching C
21 matches
Mail list logo
