Re: Compile-time checking of assignment to read-only variables (Re: MMD distances)
Patrick (>), Carl (>>), Patrick (>>>): >> > But yes, I expect that it will be caught as >> > a compile-time error. >> >> And do you agree it's reasonable to expect this of every compiler? > > Reasonable to expect it, yes -- but whether or not this rises to the > level of being a "requirement in the spec" may be a different matter. > > I could envision the possibility that some otherwise-very-capable > Perl 6 implementation might be better served by having such checks > performed at runtime (they have to be done there also) and leaving > compile-time checking as an optimization. I suspect this is what > Pugs did. Or an implementation might not have a clear-cut notion > of "compile time". > > So, as long as the assignment is properly prevented, I think that > may be sufficient. (If the language designers decide otherwise, > that's okay with me too. :-) I agree, to the extent that I understand your caveat. What we seem to agree on is that a compiler should disallow (obvious) assignments to read-only variables, provided that it is not compiler-architecturally unreasonable for it to do so. The reason I think this is important is that I consider this feature low-hanging fruit. It should be the job of the compiler-writer to please the end-programmer as much as possible (in this case by not letting code through that will die at runtime). Similarly, it should (IMHO) be the job of the language designer to spec the ways in which a compiler can be expected to please the programmer. // Carl
Re: Compile-time checking of assignment to read-only variables (Re: MMD distances)
Carl Mäsak cmasak-at-gmail.com |Perl 6| wrote: Pm (>): In Rakudo's case, we just haven't implemented read-only traits on variables yet. Goodie. I guessed as much. But yes, I expect that it will be caught as a compile-time error. And do you agree it's reasonable to expect this of every compiler? // Carl I think that is the point of declared types. But, something like no strong_type_check :rw in scope can turn that off, in case you want to play dirty tricks.
Re: Compile-time checking of assignment to read-only variables (Re: MMD distances)
On Fri, May 09, 2008 at 05:09:31PM +0200, Carl Mäsak wrote: > Pm (>): > > In Rakudo's case, we just haven't implemented read-only traits > > on variables yet. > > Goodie. I guessed as much. > > > But yes, I expect that it will be caught as > > a compile-time error. > > And do you agree it's reasonable to expect this of every compiler? Reasonable to expect it, yes -- but whether or not this rises to the level of being a "requirement in the spec" may be a different matter. I could envision the possibility that some otherwise-very-capable Perl 6 implementation might be better served by having such checks performed at runtime (they have to be done there also) and leaving compile-time checking as an optimization. I suspect this is what Pugs did. Or an implementation might not have a clear-cut notion of "compile time". So, as long as the assignment is properly prevented, I think that may be sufficient. (If the language designers decide otherwise, that's okay with me too. :-) Pm
Re: Compile-time checking of assignment to read-only variables (Re: MMD distances)
Pm (>): > In Rakudo's case, we just haven't implemented read-only traits > on variables yet. Goodie. I guessed as much. > But yes, I expect that it will be caught as > a compile-time error. And do you agree it's reasonable to expect this of every compiler? // Carl
Re: Compile-time checking of assignment to read-only variables (Re: MMD distances)
On Fri, May 09, 2008 at 03:02:28PM +0200, Carl Mäsak wrote:
> TSa (>):
> > sub bar ($x)
> > {
> >$x = 3; # error, $x is readonly
> >foo($x); # error, could hit rw Str
> > }
>
> By the way, I hope it's possible to make the assignment `$x = 3` to
> the read-only variable $x a compile-time error.
>
> In fact, I hope this to such a degree that I would like it to be part
> of a spec somewhere that a conforming Perl 6 compiler disallows
> assignments to read-only variables. I find nothing to this effect in
> S04 (but my grep-fu is imperfect, so I may just have missed it).
>
> Pugs currently dies with a run-time error on this. Rakudo r27392 runs
> it fine and sets $x = 3 as if $x wasn't read-only.
In Rakudo's case, we just haven't implemented read-only traits
on variables yet. But yes, I expect that it will be caught as
a compile-time error.
Pm
Re: Compile-time checking of assignment to read-only variables (Re: MMD distances)
HaloO, Carl Mäsak wrote: By the way, I hope it's possible to make the assignment `$x = 3` to the read-only variable $x a compile-time error. I hope so, too. The variable and its read-only constraint is known at compile time and *not* dependend on the value inside. How it came in there in the first place is left to the runtime binding ;) Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Compile-time checking of assignment to read-only variables (Re: MMD distances)
TSa (>):
> sub bar ($x)
> {
>$x = 3; # error, $x is readonly
>foo($x); # error, could hit rw Str
> }
By the way, I hope it's possible to make the assignment `$x = 3` to
the read-only variable $x a compile-time error.
In fact, I hope this to such a degree that I would like it to be part
of a spec somewhere that a conforming Perl 6 compiler disallows
assignments to read-only variables. I find nothing to this effect in
S04 (but my grep-fu is imperfect, so I may just have missed it).
Pugs currently dies with a run-time error on this. Rakudo r27392 runs
it fine and sets $x = 3 as if $x wasn't read-only.
// Carl
Re: MMD distances
HaloO,
John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
It's called overload resolution. Perl 6 can't do
that at compile time unless *all* targets are
available as rw and readonly variants.
I don't follow that statement. Can you give an example?
multi sub foo (Int $i) {...}
multi sub foo (Int $i is rw) {...}
multi sub foo (Num $n) {...}
multi sub foo (Num $n is rw) {...}
# OK so far
multi sub foo (Str $s is rw) {...} # not OK
sub bar ($x)
{
$x = 3; # error, $x is readonly
foo($x); # error, could hit rw Str
}
I must admit though, that my statement was a bit lax.
All targets readonly is fine. But the first rw
requires the insertion of rw targets for all
other variants. Perhaps you can get away with
less than all if you can prove that they'll never
be in the candidate set together with an rw. Note
that such a prove might be falsified subsequently
by introducing an Any sub like bar above.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: MMD distances
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: It's called overload resolution. Perl 6 can't do that at compile time unless *all* targets are available as rw and readonly variants. I don't follow that statement. Can you give an example?
Re: MMD distances
HaloO, John M. Dlugosz wrote: - const int& is preferred over int/int&. - const int* is preferred over int*. You mean when in each case both versions are defined as overloads only the preferred ones are ever called? C++ is the other way around. For an int* argument the int* version is preferred if both are available. For a const int* the int* is not applicable, thus not choosen. Now I understand your motivation to mangle the traits into the (dynamic) dispatch rules. But note that I would not call the C++ compile time choice dispatch. I think the standard doesn't either. It's called overload resolution. Perl 6 can't do that at compile time unless *all* targets are available as rw and readonly variants. Regards, TSa. -- "The unavoidable price of reliability is simplicity" -- C.A.R. Hoare "Simplicity does not precede complexity, but follows it." -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
MMD distances
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote: Coming back to how C++ handles static overloading. How is the sort order of (int *), (int &), (int), (const int *), (const int &), (const int), (int * const) and (const int * const)? I'm too lazy to look up the details, sorry. Without looking anything up in the standard, int and int& are indistinguishable. int* is a different type from int, and won't be confused. const vs const int don't matter to the caller. - const int& is preferred over int/int&. - const int* is preferred over int*. --John
