In a library (languages/lua/lib/luastring.pir), I declare a global variable
("mt_string"):
.namespace [ "Lua" ]
.HLL "Lua", "lua_group"
.sub init :load, :anon
...
.local pmc _lua_mt_string
_lua_mt_string = new .LuaTable
global "mt_string" = _lua_mt_string
...
In a PMC met
Francois PERRAD wrote:
In a library (languages/lua/lib/luastring.pir), I declare a global
variable ("mt_string"):
.namespace [ "Lua" ]
.HLL "Lua", "lua_group"
.sub init :load, :anon
...
.local pmc _lua_mt_string
_lua_mt_string = new .LuaTable
global "mt_string" = _lua_mt_stri
Hi all,
now the following should work:
.HLL "Foo", "Foo_group"
.HLL_map .Sub, .FooSub
.sub foo # typeof gives 'FooSub'
...
(given that the HLL 'Foo' has defined a 'FooSub', which C Sub [1])
Closures and coroutines should be mappable too now.
There is one test[2], which is
On Mar 8, 2006, at 14:30, Leopold Toetsch wrote:
2)
Default Namespace
The default namespace PMC will implement Parrot's current
behavior.
The current implementation allows a nested namespace and a variable to
have the same name (via the hack of prepending "\0" to namespace
n
On Fri, Mar 10, 2006 at 05:33:01PM +0100, Leopold Toetsch wrote:
> >a) Parrot's default namespace is untyped (raw). This means that a
> >variable/subroutine can't have the same name as a namespace. This
> >could break existing code.
> >
> >b) Otherwise, Parrot's namespace is (half-)typed, at leas
On Mar 10, 2006, at 17:45, Chip Salzenberg wrote:
Ah, well, I'm sorry to report that (a) was the correct answer; Parrot's
default should be entirely untyped.
Sorry I didn't catch this earlier, but I'm actually on the road today,
so
it's a good thing I caught it now before users could start co
I've implemented a fair amount of pdd21, mostly the invisible internals
part currently. Before I start with the final changes (and possibly
start breaking existing code), I'd like to summarize the planned
behavior.
Code snippet # NameSpace::name
.sub main
Leopold Toetsch wrote:
> .HLL "perl5"," # new top-level namespace
> .sub 'x' # perl5::x
Will there be a way to get back into the default top-level namespace?
e.g.:
.HLL ""
or
.HLL "parrot"
My Amber compiler is currently adding a few extra su
On Mar 10, 2006, at 23:09, Roger Browne wrote:
Will there be a way to get back into the default top-level namespace?
e.g.:
.HLL ""
or
.HLL "parrot"
My Amber compiler is currently adding a few extra subs to some of the
standard parrot PMCs, and I won't be able to do this if I'm in the
