Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
Chaim Frenkel wrote:
> A nice way of making a value read-only is lovely. And let it be a
> runtime error to modify it.
>
> The caller can easily do a &foo eval{$const_item} to remove the
> read-only attribute.
>
> Hmm, perhaps we should rename the attribute
> :read-only
>
Can't we make a value 'truely constant', as inlined subs do now? It would be
nice to declare data 'truely constant' and 'never aliased' to enable
appropriate optimisations (these are two separate attributes, BTW).
Modifying a constant value using eval should give the same errors as
modifying a literal--and I would have thought this would be
straightforwards, if the constant is just replaced with its value at compile
time. Aliasing a 'never aliased' value should also provide a meaningful
error.
Currently, of course, another problem with constants as inlined subs is that
the errors are horrible:
use constant AA=>6;
AA = 5;
# Can't modify non-lvalue subroutine call in scalar assignment
Ick!
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
At 05:09 PM 8/11/00 -0400, Chaim Frenkel wrote: >Hmm, perhaps we should rename the attribute > :read-only Works, though I like "constant" (or const, that's OK) just as much. Might be worth having a way to set things to read-only temporarily, too. Won't help the optimizer, but it could keep some of the more sublte "whoops"es from happening. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 10:58 AM 8/11/00 -0400, Chaim Frenkel wrote:
>> Someone on this list (TomC?) has supplied a major diatribe against const.
DS> Maybe, but I don't see what's wrong with:
DS> my $foo :const = 12;
DS> A nice, named, lexically scoped constant. The optimizer should be able to
DS> make reasonably good use of that.
Err, I was addressing the issue of having
const this
this const
sub foo ($name :const)
etc.
A nice way of making a value read-only is lovely. And let it be a
runtime error to modify it.
The caller can easily do a &foo eval{$const_item} to remove the
read-only attribute.
Hmm, perhaps we should rename the attribute
:read-only
--
Chaim FrenkelNonlinear Knowledge, Inc.
[EMAIL PROTECTED] +1-718-236-0183
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
At 10:58 AM 8/11/00 -0400, Chaim Frenkel wrote: >Someone on this list (TomC?) has supplied a major diatribe against const. Maybe, but I don't see what's wrong with: my $foo :const = 12; A nice, named, lexically scoped constant. The optimizer should be able to make reasonably good use of that. > > "JH" == Jeremy Howard <[EMAIL PROTECTED]> writes: > >JH> Dan Sugalski wrote: > >> The syntax is actually: > >> > >> my type $varname; > >> > >> This is in perl 5.6.0. Modifiers go as attributes after the colon: > >> > >> my Dog $spot : constant = new Dog; > >> >JH> Yes. But what about types and attributes within complex types? > >JH> - Constant refs vs refs to constants? >JH> - Types of hash (or 'pair') keys and elements? >JH> - Attributes (e.g. constantness) of hash keys and elements? >JH> - Ditto for arrays/lists... > >JH> I left this out of v1 of the RFC because I wanted to get some feedback on >JH> syntax. If we can flesh this out I'll incorporate it into v2. > >JH> Also, do we want to be able to specify types and attributes within a sub >JH> prototype? It would be nice to guarantee that subs don't mutate particular >JH> parameters, that certain data will not be aliased, etc, so that >appropriate >JH> optimisations can be done. > > > > > > >-- >Chaim FrenkelNonlinear Knowledge, Inc. >[EMAIL PROTECTED] +1-718-236-0183 Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
Someone on this list (TomC?) has supplied a major diatribe against const. > "JH" == Jeremy Howard <[EMAIL PROTECTED]> writes: JH> Dan Sugalski wrote: >> The syntax is actually: >> >> my type $varname; >> >> This is in perl 5.6.0. Modifiers go as attributes after the colon: >> >> my Dog $spot : constant = new Dog; >> JH> Yes. But what about types and attributes within complex types? JH> - Constant refs vs refs to constants? JH> - Types of hash (or 'pair') keys and elements? JH> - Attributes (e.g. constantness) of hash keys and elements? JH> - Ditto for arrays/lists... JH> I left this out of v1 of the RFC because I wanted to get some feedback on JH> syntax. If we can flesh this out I'll incorporate it into v2. JH> Also, do we want to be able to specify types and attributes within a sub JH> prototype? It would be nice to guarantee that subs don't mutate particular JH> parameters, that certain data will not be aliased, etc, so that appropriate JH> optimisations can be done. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
At 02:29 PM 8/11/00 +1000, Jeremy Howard wrote: >Dan Sugalski wrote: > > The syntax is actually: > > > >my type $varname; > > > > This is in perl 5.6.0. Modifiers go as attributes after the colon: > > > > my Dog $spot : constant = new Dog; > > >Yes. But what about types and attributes within complex types? What about them? Attributes can take parameters easily enough: my bigint $pi : constant : digits(7) = "3.1415926" >Also, do we want to be able to specify types and attributes within a sub >prototype? It would be nice to guarantee that subs don't mutate particular >parameters, that certain data will not be aliased, etc, so that appropriate >optimisations can be done. I'm not sure I'd sweat the optimization stuff at this point. Besides, it's unlikely that the optimizer will know anything about attributes of non-core variable types anyway, so... Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Data type and attribute syntax (was Re: RFC 89 (v1) Controllable Data Typing)
Dan Sugalski wrote: > The syntax is actually: > >my type $varname; > > This is in perl 5.6.0. Modifiers go as attributes after the colon: > > my Dog $spot : constant = new Dog; > Yes. But what about types and attributes within complex types? - Constant refs vs refs to constants? - Types of hash (or 'pair') keys and elements? - Attributes (e.g. constantness) of hash keys and elements? - Ditto for arrays/lists... I left this out of v1 of the RFC because I wanted to get some feedback on syntax. If we can flesh this out I'll incorporate it into v2. Also, do we want to be able to specify types and attributes within a sub prototype? It would be nice to guarantee that subs don't mutate particular parameters, that certain data will not be aliased, etc, so that appropriate optimisations can be done.
