[perl #58252] [TODO][PIR] finalize open issue with "pmc" type in .const definitions

Klaas-Jan Stol via RT parrotbug-followup at parrotcode.org
Sat Nov 29 19:12:26 UTC 2008


On Fri Aug 22 14:41:39 2008, coke wrote:
> On Fri, Aug 22, 2008 at 11:06 AM, via RT Klaas-Jan Stol
> <parrotbug-followup at parrotcode.org> wrote:
> > # New Ticket Created by  Klaas-Jan Stol
> > # Please include the string:  [perl #58252]
> > # in the subject line of all future correspondence about this issue.
> > # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58252 >
> >
> >
> > The following issues are not entirely clear from PDD19:
> >
> > [1]
> > according to PDD19 (PIR) you can declare a .const as follows:
> >
> > =item .const <type> <identifier> = <const>
> >
> > Define a constant named I<identifier> of type I<type> and assign
> value
> > I<const> to it. The I<type> may be either an integer value or a
> string
> > constant. The constant is stored in the constant table of the
> current
> > bytecode file.
> >
> > <type> stands for "int", "num", "string" or "pmc". However, writing
> "pmc"
> > does not make any sense, because <const> must be some literal
> constant, such
> > as 42, 3.14 or "hello"; it doesn't make sense to write:
> >
> > .const pmc x = "hi" # what type will x be?
> >
> > THerefore, should we allow "pmc" as a type here? I see 2 reasonable
> > solutions:
> > 1: disallow "pmc" altogether
> > 2: based on the type of the constant (int-constant, num-constant or
> string
> > constant), make the variable (eh, constant) a constant of one of the
> > standard types (Integer, Float or String , respectively).
> >
> > [2]
> > you can declare a .const using a PMC class type id:
> >
> > .const .Sub x = "foo"
> >
> > AFAIU, type ids will be removed altogether (is this true?).
> 
> Yes.
> 
> > If so, then the above would be invalid.
> > Instead, we might allow for writing:
> >
> > .const "Sub" x = "foo".
> 
> I believe this syntax already works in the branch dedicated to
> destroying type ids.
> 
> > Which seems a nice enough solution, but this solution is rather
> limited, in
> > that you can't create, for instance, an Array constant:
> >
> > .const "Array" a = "foo" # doesn't make sense.
> 
> I just tripped over this description of the :immediate modifier in
> PDD19:
> 
> =item :immediate
> 
> Execute this subroutine immediately after being compiled, which is
> analogous
> to C<BEGIN> in Perl 5.
> 
> In addition, if the sub returns a PMC value, that value replaces the
> sub in
> the constant table of the bytecode file.
> 
> <SNIP>
> 
> It goes on to describe how we can use this to create an constant PMC
> of arbitrary type at compile time; I'd just advertise this method,
> then we don't need any additional sugar.
> 
> > I know the creation of Sub constants is useful, so we definitely
> should keep
> > something like this around.
> >
> > I see the following solutions:
> >
> > 1: only allow pmc types that are reasonable:
> > - .const "Integer" x = 42
> > - .const "Float" PI = 3.14
> > - .const "String" message = "hi there"
> > - .const "Sub" x = "foo"
> >
> > and report an error message if you would do something weird as
> ".const 'Env'
> > e = 10".
> >
> > 2: extend syntax for other variants, for instance, to initialize
> arrays and
> > hashtables:
> > - .const "Array" a = (1, 2, 3, 4) # creates a constant array with 4
> > elements, nrs 1 to 4
> > - .const "Hash" h1 = {"x"=>42, "y"=>10} ## using syntactic sugar
> form that
> > is used for named arguments as well
> > - .const "Hash" h2 = { 42 :named("x"), 10 :named("y") } ## to be
> consistent
> > with the above, using syntax well-known in named-arguments.
> >
> > Not sure if this would be helpful/possible, but just some thoughts.
> >
> > comments welcome.
> > kjs
> >
> 
> 
> 

Conclusion:

+ type ids are gone (user-visible anyway)
+ no additional sugar needed; apparently using :immediate on a sub 
returning some PMC does the trick (see docs on :immediate modifier)

I agree on Coke's replies on my initial issues. I propose to close this 
ticket. 

kjs






More information about the parrot-dev mailing list