Author: chip
Date: Mon Mar 13 15:41:32 2006
New Revision: 11894
Modified:
trunk/docs/pdds/pdd03_calling_conventions.pod
Log:
Undeprecate the MAYBE_FLAT bit, which (contrary to my mistaken memory) is
not unused, but is in fact very often used for Perl 6.
New features: (1) When a hash value is
Author: chip
Date: Sun Apr 16 20:33:54 2006
New Revision: 12283
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Log:
* Added requirement that ."load_library"() throw an exception on
failure. Also noted that the exception is only covering for the lack of a
universal error PM
Author: chip
Date: Sun Apr 16 21:21:53 2006
New Revision: 12284
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Log:
* Documented clearly & consistently that all namespace opcodes start their
search in the HLL root namespace, *not* at the global root.
* Added a second namespace metho
Author: chip
Date: Mon Apr 17 08:35:24 2006
New Revision: 12289
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Log:
Rename name() method to get_name() for consistency and
to allow for eventual possibility of set_name().
Modified: trunk/docs/pdds/pdd21_namespaces.pod
Author: chip
Date: Tue May 16 13:27:30 2006
New Revision: 12706
Modified:
trunk/docs/pdds/clip/pdd02_vtables.pod
trunk/docs/pdds/clip/pdd15_objects.pod
Changes in other areas also in this revision:
Modified:
trunk/docs/ROADMAP.pod
trunk/docs/vtables.pod
trunk/src/ops/ops.num
Author: chip
Date: Tue May 23 11:06:17 2006
New Revision: 12774
Modified:
trunk/docs/pdds/clip/pdd23_exceptions.pod
Log:
Half-done. The new opcodes and directives are certain,
and can be the basis of implementation work immediately.
Modified: trunk/docs/pdds/clip/pdd23_exceptions.pod
Author: chip
Date: Fri Jun 30 13:10:33 2006
New Revision: 13070
Modified:
trunk/docs/pdds/clip/pdd23_exceptions.pod
Log:
Overhaul.
Take _that_, Coke!
Modified: trunk/docs/pdds/clip/pdd23_exceptions.pod
==
--- trunk
Author: chip
Date: Fri Jun 30 13:12:26 2006
New Revision: 13071
Added:
trunk/docs/pdds/pdd23_exceptions.pod
- copied unchanged from r13070, /trunk/docs/pdds/clip/pdd23_exceptions.pod
Removed:
trunk/docs/pdds/clip/pdd23_exceptions.pod
Log:
Rename pdd23 into docs/pdds.
Author: chip
Date: Sat Jul 1 11:26:02 2006
New Revision: 13092
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Log:
* Exception handlers are now closures (or just plain subroutines),
not continuations.
* Eliminate the C opcode, as the handler returning is enough
of a clue that the next
Author: chip
Date: Sat Jul 1 11:26:44 2006
New Revision: 13093
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Log:
oops, restore namespace on exception class in example code
Modified: trunk/docs/pdds/pdd23_exceptions.pod
Author: chip
Date: Sat Jul 1 11:30:02 2006
New Revision: 13094
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Log:
rename 'caught' opcode to 'handled' for obscure reasons
Modified: trunk/docs/pdds/
Author: chip
Date: Sat Jul 1 12:27:31 2006
New Revision: 13097
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Log:
Consistently describe namespace identifiers accepted by namespace opcodes as
either key constants or string arrays, since both of those work in all cases
(or should
Author: chip
Date: Sat Jul 1 13:00:41 2006
New Revision: 13098
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Log:
Specify new compiler methods, compiler.'parse_name'(), which allows parsing
foreign language names using the foreign language's rules. (per Allison)
Author: chip
Date: Wed Jul 5 17:31:15 2006
New Revision: 13170
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Changes in other areas also in this revision:
Modified:
trunk/include/parrot/global.h
trunk/include/parrot/hll.h
trunk/src/builtin.c
trunk/src/global.c
trunk/src
Author: chip
Date: Thu Jul 6 13:05:47 2006
New Revision: 13183
Modified:
trunk/docs/pdds/pdd00_pdd.pod
Changes in other areas also in this revision:
Modified:
trunk/README
trunk/README.win32.pod
trunk/RELEASE_INSTRUCTIONS
trunk/compilers/imcc/README
trunk/docs/debug.pod
Author: chip
Date: Tue Sep 5 10:42:07 2006
New Revision: 14416
Added:
trunk/docs/pdds/pdd07_codingstd.pod (contents, props changed)
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Move pdd07 out of clip
Added: trunk/docs/pdds/pdd07_codingstd.pod
Author: chip
Date: Tue Sep 5 10:42:52 2006
New Revision: 14419
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
About 25% done with update of pdd07.
Modified: trunk/docs/pdds/pdd07_codingstd.pod
Author: chip
Date: Tue Sep 5 15:00:42 2006
New Revision: 14432
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Move pdd07 out of clip
Modified: trunk/docs/pdds/pdd07_codingstd.pod
Author: chip
Date: Tue Sep 5 15:01:18 2006
New Revision: 14435
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
About 25% done with update of pdd07.
Modified: trunk/docs/pdds/pdd07_codingstd.pod
Author: chip
Date: Tue Sep 5 15:01:35 2006
New Revision: 14436
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Added:
trunk/editor/parrot.el (contents, props changed)
Modified:
trunk/ (props changed)
trunk/editor/README.pod
Log
Author: chip
Date: Wed Sep 6 15:57:05 2006
New Revision: 14452
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Move pdd07 out of clip
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
Author: chip
Date: Wed Sep 6 15:57:18 2006
New Revision: 14453
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
Author: chip
Date: Wed Sep 6 15:57:40 2006
New Revision: 14454
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
Author: chip
Date: Wed Sep 6 15:57:46 2006
New Revision: 14455
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
About 25% done with update of pdd07.
Modified: trunk/docs/pdds/pdd07_codingstd.pod
==
Author: chip
Date: Tue Oct 3 12:36:36 2006
New Revision: 14840
Removed:
trunk/docs/pdds/clip/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Remove redundant pdd07 (closes: #40419)
Author: chip
Date: Fri Nov 10 11:12:20 2006
New Revision: 15330
Modified:
trunk/docs/pdds/pdd03_calling_conventions.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
trunk/compilers/imcc/imcc.l
trunk/compilers/imcc/imcc.y
trunk/compilers/imcc
Author: chip
Date: Tue Nov 14 09:40:26 2006
New Revision: 15527
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
Incremental improvement to pdd07 "coding standards":
* Prefer "char
rking with RPM and not against it, I had good success.
Chip
--
Chip Turner [EMAIL PROTECTED]
[EMAIL PROTECTED]
ed once? This seems like the best
choice, assuming GC issues are manageable.
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Sun, Nov 13, 2005 at 11:33:07AM +0100, Leopold Toetsch wrote:
> On Nov 13, 2005, at 4:45, Chip Salzenberg wrote:
> > $P0 = callframe 1
>
> We already have this kind of introspection: $ grep caller t/pmc/sub.t
OK, the Interpreter PMC interface is certainly flexible enoug
pshots is welcome but not mandatory.
Once you've experimented enough to know for sure that your changes are
an overall improvement (and specifically that they don't break the
architectures that work now), you could commit your work to the trunk.
Thanks muchly for asking...
--
Chip Salzenberg <[EMAIL PROTECTED]>
7;s bad about how it works now? <- not a rhetorical question
[*] an inode may have as few as zero or as many as USHORT_MAX[**] names,
and finding them all requires scanning a disks's entire directory tree
[**] your mileage may vary
--
Chip Salzenberg <[EMAIL PROTECTED]>
*] http://paginas.terra.com.br/informatica/paulobarreto/WhirlpoolPage.html
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Wed, Nov 16, 2005 at 12:44:36PM -0800, Chip Salzenberg wrote:
> * The SHA-2 family (including SHA-256 and other variants) is showing no
>signs of weakness AFAIK.
> * Whirlpool [**] seems strong enough too; Bruce Schneier describes it
>as "a good choice".
Not to
less clunky. Meantime, I'm
glad the fix was so straightforward.
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Thu, Nov 17, 2005 at 08:10:59AM -0800, jerry gay wrote:
> it seems we're missing an op (freopen) that would make this
> possible. we've already got fdopen, getfd, getstdout, getstderr, so
> we're mostly there.
Sounds more like you want fdreopen.
--
Chip Salzenberg <[EMAIL PROTECTED]>
always found the
polarity hard to remember.
I like grep.
--
Chip Salzenberg <[EMAIL PROTECTED]>
ons of NIST's recent
> hash workshop.
I think we've been reading the same blog. :-)
--
Chip Salzenberg <[EMAIL PROTECTED]>
uter(do_add3)
$P0 = fetch_lex '$a'
$P1 = $P0 + 3
.return ($P1)
.end
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Tue, Nov 22, 2005 at 09:32:37AM -0800, Chip Salzenberg wrote:
> $P0 = fetch_lex '$a'
I meant "find_lex", of course.
PS: fetch_*, get_*, find_*, ... so many naming conventions, so little
reason for them.
--
Chip Salzenberg <[EMAIL PROTECTED]>
pile error? runtime error? warning only, and error on lexical
> access in inner sub?
I'd call this correct but silly, kind of like assigning to a register
that doesn't get used afterwards.
--
Chip Salzenberg <[EMAIL PROTECTED]>
e already
use the perfectly serviceable comma for analogous cases.
> I'd prefer to ask for mappings explicitly, e.g. something like this:
>
>.HLL "Tcl", "tcl_group"
>...
>$P0 = new Integer # really Integer
>$P1 = new_mapped Integer # really TclInteger
Hm. Why?
--
Chip Salzenberg <[EMAIL PROTECTED]>
exical, the sequence is
$P1 = find_lex 'a'
followed by some mutating operation on $P1.)
Is this a problem for Tcl implementation? If so, how?
--
Chip Salzenberg <[EMAIL PROTECTED]>
language
and getting the programmers to write ASTs.
--
Chip Salzenberg <[EMAIL PROTECTED]>
namic query on
a Sub. (Continuations just make it worse.)
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Wed, Nov 23, 2005 at 10:49:18PM +0100, Leopold Toetsch wrote:
> On Nov 23, 2005, at 19:08, Chip Salzenberg wrote:
> >You keep confusing static and dynamic call information.
>
> Not confusing actually, maybe abusing the static sub structure by
> adding a dynamic field 'c
m. That would allow us to connect the running &bar
_Closure_ to the &bar _Sub_ it was created from. (The reason we
would need that connection is that the Sub &baz's outer_sub
attribute points only to the static Sub &bar.)
OK so far?
If so I'll follow up with design docs.
--
Chip Salzenberg <[EMAIL PROTECTED]>
cloned the leaf Closure.
* Therefore, we have outer_sub for the relationship of non-Closure
Subs, and caller_ctx for Closure (cloning) relationships.
* And thus there should be no need to modify a Sub after compilation,
nor a Closure after cloning.
Does this describe the current situation and its features?
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Thu, Nov 24, 2005 at 08:54:54AM +0100, Leopold Toetsch wrote:
> On Nov 23, 2005, at 19:08, Chip Salzenberg wrote:
> >You keep confusing static and dynamic call information.
>
> While at static objects like subroutine PMCs - there is some code
> around that is setting
mes I really do wish for C++ again. This is such a
template thing.)
--
Chip Salzenberg <[EMAIL PROTECTED]>
bad. Matches up with get_results. But the direction isn't
entirely clear when you read it: Is it setting or getting results?
# (b)
catch_label:
.get_results ($P0)
Better, I think.
# (c)
catch_label:
($P0) = @EXCEPTION # or some other magic word
Ew. I still like (b).
--
Chip Salzenberg <[EMAIL PROTECTED]>
uot;lexpad";depth]
> unless_null lexpad, got_lexpad
>
> # try again
> inc depth
> goto get_lexpad
> got_lexpad:
> variable = lexpad[variable_name]
> .return(variable)
> .end
>
>
--
Chip Salzenberg <[EMAIL PROTECTED]>
ion to take a depth parameter and just grab the right LexPad on
the first try. But you find it more convenient to loop up the call
stack rather than have to calculate the depth everywhere. (Right?)
Also: If it weren't for the fact you want to search lexicals and
globals every time, you co
ive_pbc
> | +---op
> | +---perl
> | +---pmc
> | +---run
> | +---src
> | +---stress
> | +---tools
> +---tools
> | +---build_tools # moved from build/
> | +---dev
> | +---docs
> | +---editor # moved from editor/,
the tests to even refer to imcc? IMHO Parrot
> ability to digest PIR is whats really being tested. However unlikely,
> it's worth keeping in ind that Parrots internal PIR compiler may be
> replaced someday.
Oh, one other thing for the renaming game:
IMC vs. PIR
Two names enter
One name leaves
/me giggles
--
Chip Salzenberg <[EMAIL PROTECTED]>
you really only want N. How about:
exception:
.local pmc except
.param except
.param $P0 :slurp :ignore# don't bother constructing Array
if_null $P0, always # it's always Null
Hm. Seems like a pretty ugly kludge for a rare case.
--
Chip Salzenberg <[EMAIL PROTECTED]>
ifies S0, NO MATTER WHAT '...' IS
I0 := ... # ILLEGAL
I0 = ... # assignment: modifies I0
N0 := ... # ILLEGAL
N0 = ... # assignment: modifies N0
Comments? Fresh or rotten vegetables?
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Tue, Nov 29, 2005 at 12:14:24PM -0800, Brent 'Dax' Royal-Gordon wrote:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> >P0 := P1 # aliasing: P0 and P1 point to same PMC
> >P0 := opcode # aliasing: P0 points to PMC returned by opcode
> >
On Tue, Nov 29, 2005 at 02:18:17PM -0600, Patrick R. Michaud wrote:
> On Tue, Nov 29, 2005 at 12:08:01PM -0800, Chip Salzenberg wrote:
> >P0 := P1 # aliasing: P0 and P1 point to same PMC
> >P0 := opcode # aliasing: P0 points to PMC returned by o
On Tue, Nov 29, 2005 at 03:25:13PM -0500, Matt Diephouse wrote:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > Therefore, I propose requiring people to spell aliasing as ':='.
>
> "And the Lord did grin. And the people did feast upon the lambs and
&
On Tue, Nov 29, 2005 at 12:36:03PM -0800, Chip Salzenberg wrote:
> On Tue, Nov 29, 2005 at 02:18:17PM -0600, Patrick R. Michaud wrote:
> > P0 = P1[S1]# supported?
>
> Yes, it means to fetch a PMC and make P0 an alias to it. Perl 6
> equivalent should be, more or
On Tue, Nov 29, 2005 at 12:38:55PM -0800, Brent 'Dax' Royal-Gordon wrote:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > On Tue, Nov 29, 2005 at 12:14:24PM -0800, Brent 'Dax' Royal-Gordon wrote:
> > > I'm not sure about the last two (
hus, since I and N registers are not
pointers, they can't support the semantics implied by := .
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Tue, Nov 29, 2005 at 04:27:28PM -0500, Matt Diephouse wrote:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > On Tue, Nov 29, 2005 at 03:25:13PM -0500, Matt Diephouse wrote:
> > > Or, perhaps more accurately, `P1 := ...\n assign P0, P1`?
> >
> > No, PIR doesn
On Tue, Nov 29, 2005 at 11:13:05PM +0100, Leopold Toetsch wrote:
> On Nov 29, 2005, at 21:36, Chip Salzenberg wrote:
> >I'm planning a flag day sometime in December. I'm also planning to
> >create a simple "handles most cases" translator.
>
> That'
r Science is merely the post-Turing Decline of Formal Systems Theory."
But how can you STKO[*] with an infinite tape?
[*] Stretch Tape and Kill Operator
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Tue, Nov 29, 2005 at 10:45:12PM +, Roger Browne wrote:
> On Tue, 2005-11-29 at 12:08 -0800, Chip Salzenberg wrote:
> > Therefore, I propose requiring people to spell aliasing as ':='.
>
> Is some different symbol possible, to avoid confusing people who use
>
nother. In other words, aliasing. I and N
registers cannot alias.
And aliasing is getting its own operator.
--
Chip Salzenberg <[EMAIL PROTECTED]>
rot calling convention, so it may not be necessary to do this yet.
Autrijus, what do you think about READONLY aliasing in get_params
vs. outline pbc? Is core support premature?
--
Chip Salzenberg <[EMAIL PROTECTED]>
that work for you? For that matter, did you know that
your code dies when parameter counts are enforced?
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Wed, Nov 30, 2005 at 12:49:13PM -0500, Joshua Juran wrote:
> On Nov 29, 2005, at 5:16 PM, Chip Salzenberg wrote:
> >Excellent. Now if only I knew a good language for text filters...
>
> How about sed or awk?
Hm. If only we had a pir2xml, I could use XSLT.
--
Chip Sal
>
> Isn't this what :slurpy is for?
Well, :slurpy is good if you do (or might) want to examine the extra
parameters. If you just want to throw them away, there should be a
way to say that.
--
Chip Salzenberg <[EMAIL PROTECTED]>
vil. An evil that has been in abeyance since the
defeat of IP over XML-RPC.
That is not dead which can eternal lie
And with strange aeons, even XML may die
--
Chip Salzenberg <[EMAIL PROTECTED]>
, would you be so kind as to rescind the parameter passing error
flags, and make mismatches always throw? Unless/until we have :last,
users can use :slurpy on an unused register to mean "extra params OK".
--
Chip Salzenberg <[EMAIL PROTECTED]>
't like that, but I didn't know you'd fixed it. Are
there any remaining limitations on the placement of the pdd03 opcodes?
--
Chip Salzenberg <[EMAIL PROTECTED]>
an that it
needs to be replaced with a real LexEnv.
> (As an aside is there interest in having the names of the invoke ops
> more consistent, say: callcc and callcc_method; or invokecc and
> invokecc_method?)
I'm not planning to rename any opcodes ATM. As Allison correctly
observes, PIR is an assembly language, not an HLL. So the barrier
to cosmetic cleanups is higher.
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Wed, Nov 30, 2005 at 03:58:28PM -0800, Jonathan Sillito wrote:
> On 11/30/05, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > On Wed, Nov 30, 2005 at 12:02:08PM -0800, Jonathan Sillito wrote:
> > > 2. Should we provide a way for a compiler to provide depths to the
>
g convention opcodes as being not for human
consumption. PIR macros like .param are the way to go. "PIR is for
humans. Pasm is for silicon-based life forms." - me
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Thu, Dec 01, 2005 at 01:45:49AM +0100, Leopold Toetsch wrote:
> While strict argument checking is and was always in the pdd03, it was
> not enforced and is only checkable since today. Therefore I'd like to
> keep current settings until after the release.
Works for me.
--
C
od thing; just include a note about
its not being mandatory. If I were a new contributor and I submitted
a spelling patch, I wouldn't request or expect a CREDITS entry. Thanks.
--
Chip Salzenberg <[EMAIL PROTECTED]>
s
and even {nested} braces
goes
here
})
--
Chip Salzenberg <[EMAIL PROTECTED]>
ether we can count on reproducible hashes from
successive compilations of the same source file.
--
Chip Salzenberg <[EMAIL PROTECTED]>
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 HE
On Tue, Dec 13, 2005 at 07:01:01PM +, Nicholas Clark wrote:
> On Mon, Dec 12, 2005 at 10:08:24AM -0800, Chip Salzenberg wrote:
> > Neat - this is a fine approximate solution until we have real pbc
> > hashing, and *may* continue to be necessary even with hashing,
> > de
that point).
Hm. If you say 'contents => undef', you might get a copying of
metadata _only_. Neat.
Come to think of it, Perl 5 could use one of these. And somebody
should check with the p6 guys to see what they think of it ... they
might be in a mood to (re)specify filesystem manipulation.
--
Chip Salzenberg <[EMAIL PROTECTED]>
system call in Mac OS X?
--
Chip Salzenberg <[EMAIL PROTECTED]>
quot;, for
convenience, and in keeping with common usage, I like "FS". Today,
anyway.
PS: If some class is named "Filesystem" someday, the "S" shouldn't be
capitalized: "filesystem" is an established single term in CS.
"Filesys" maybe as a short form?
--
Chip Salzenberg <[EMAIL PROTECTED]>
there's
no point in me trying to dictate anything for them.
--
Chip Salzenberg <[EMAIL PROTECTED]>
ging, can do anything, up to and including spawning nethack.)
If the callee wanted to be flexible he would have to use :optional, and
I can imagine that e.g. Perl 5 translations would always have to use it.
> Thanks for clarification,
Glad to help
--
Chip Salzenberg <[EMAIL PROTECTED]>
ain if the user
doesn't say .param himself. Then the errors can be left on always.
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Fri, Jan 20, 2006 at 11:41:45AM -0800, jerry gay wrote:
> i suppose we need a design decision on this.
We need a PIR version of get_params '()'. I'm OK with .no_params.
--
Chip Salzenberg <[EMAIL PROTECTED]>
number of registers passed to get_params, so mixing in a few
entries that must be ignored for arg count purposes wouldn't be any big
deal. True?
--
Chip Salzenberg <[EMAIL PROTECTED]>
e Reference type we're going
to have to make work just for e.g. the Perl backslash operator?
(Actually, I'm still a little fuzzy on actual usage patterns for this
kind of thing. Otherwise I'd probably know those answers.)
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Tue, Jan 24, 2006 at 03:52:39PM -, Jonathan Worthington wrote:
> "Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
> >The trick is to keep references to registers in a way that notices
> >when the register set is gone, or alternatively, that keeps the
> >regi
jeepers I mangled this paragraph
On Tue, Jan 24, 2006 at 10:31:50AM -0800, Chip Salzenberg wrote:
> What I had in mind, was imitating whatever a closure does to hold onto a
> context chain. I would detail that here except it's not on the top of my
> brain except (1) the point is
rter can use type() to choose with add_* interface to use
> if necessary. It *is* possible.
Indeed, for any given HLL "L", no one is in a better position than L's
exporter to know which of L's objects are more function-like than
variable-like. That's why the idiom is
source.export_to(target)
rather than
target.import_from(source)
--
Chip Salzenberg <[EMAIL PROTECTED]>
attern recognition; if
wildcards are supported, they will be quite limited, and I'll make that
clearer. Anything more interesting will be implemented by HLLs' customized
namespace PMCs. I'll put that in the pdd.
> OTOH there isn't any 'import' hook that might be necessary to deal with
> type mismatches, interop issues, and whatnot.
That's the purpose of the typed interface on the target namespace.
--
Chip Salzenberg <[EMAIL PROTECTED]>
Following up to myself, I just had an idea about expanding the typed
interface:
On Tue, Jan 24, 2006 at 12:26:30PM -0800, Chip Salzenberg wrote:
> The Perl namespace's typed interface will have to figure out what kind of
> variable it thinks it's getting. That decision could be
On Tue, Jan 24, 2006 at 08:49:55PM -, Jonathan Worthington wrote:
> "Chip Salzenberg" <[EMAIL PROTECTED]> wrote:
> >I'd prefer to reuse something in the engine already for those callbacks.
> >If a lightweight callback mechanism, with parameter, doesn'
On Tue, Jan 24, 2006 at 08:29:45PM -0500, Matt Diephouse wrote:
> Chip Salzenberg <[EMAIL PROTECTED]> wrote:
> > Say, that gives me an idea. Python-like untyped namespaces are a
> > significant subpopulation.
> >
> > Matt: How about a standard namespace me
1 - 100 of 429 matches
Mail list logo
