On Fri, Aug 22, 2008 at 11:06 AM, via RT Klaas-Jan Stol
<[EMAIL PROTECTED]> 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
>
--
Will "Coke" Coleda
