senting everything else. For example,
"(Mu but True).perl" could yield the string "Mu". The bug is that .perl
produces output so broken that .EVAL errors.
-zefram
senting everything else. For example,
"(Mu but True).perl" could yield the string "Mu". The bug is that .perl
produces output so broken that .EVAL errors.
-zefram
d to do more than identity comparison, and equality
comparison of .WHICH values must always behave the same as ===.
-zefram
d to do more than identity comparison, and equality
comparison of .WHICH values must always behave the same as ===.
-zefram
Brian S. Julin via RT wrote:
>Fixed in 2017.6 or thereabouts.
Specifically commit c6b03c45c7173e21be6c53fc629fa27f2676c76a, dated
2017-06-15.
-zefram
Brian S. Julin via RT wrote:
>Fixed in 2017.6 or thereabouts.
Specifically commit c6b03c45c7173e21be6c53fc629fa27f2676c76a, dated
2017-06-15.
-zefram
et(Nil)
> Set.new(3,Nil)
set((Any) 3)
> Set.new(Nil,Nil)
set((Any))
That's pretty weird. The subject line of this ticket still seems
applicable.
> you'll note List.new wont transcribe
>Nil either.
That looks like a separate bug.
-zefram
et(Nil)
> Set.new(3,Nil)
set((Any) 3)
> Set.new(Nil,Nil)
set((Any))
That's pretty weird. The subject line of this ticket still seems
applicable.
> you'll note List.new wont transcribe
>Nil either.
That looks like a separate bug.
-zefram
t;).WHICH === Set.new("a\\0Str|b").WHICH
True
The way in which Set.WHICH could be confused by innocently-constructed
elements that are Sets no longer occurs, because of the hashing.
-zefram
t;).WHICH === Set.new("a\\0Str|b").WHICH
True
The way in which Set.WHICH could be confused by innocently-constructed
elements that are Sets no longer occurs, because of the hashing.
-zefram
s. See [perl #128943] (Set, and in which I sketched out how
to fix it) and [perl #128947] (Pair, just like your Pair example).
>we have no choice than to either use an escape character quoteish
>construct, or prepend a length:
The former would be much nicer to work with.
-zefram
cument that the operation will fail
if the right answer is too big to represent, but in this case the right
answer is very small.)
-zefram
cument that the operation will fail
if the right answer is too big to represent, but in this case the right
answer is very small.)
-zefram
ult to interpret but which definitely doesn't say anything
about special behaviour for Pairs. Some description of coercing behaviour
on the source-type side would be useful; at least a pointer to the Set
doc section that describes the Pair thing.
-zefram
ccount of this
syntactic feature.
-zefram
ccount of this
syntactic feature.
-zefram
Oops, this is mostly a duplicate of [perl #129015]. Sorry.
-zefram
me lingering inconsistency left over
>from when Bool had to be special-cased
I haven't noticed any such inconsistency between Bool and other enums.
That's certainly not the cause of the present inconsistent coercions,
which happen equally with Order:
> Less.Int
-1
> Less.Real
Less
> Less.Numeric
-1
-zefram
lso Exception.
-zefram
that's an undesirable principle
in the design of Perl 6.
-zefram
; @a[0] = 3
Cannot modify an immutable Nil
in block at line 1
-zefram
If you'd prefer for [] to keep the Nil manglement, it's open to Array.perl
to emit more complex code that doesn't just feed the Nil to [].
-zefram
int (and thus a nul octet in UTF-8) cannot arise from
any grapheme cluster other than a bare nul.
-zefram
enames at directory separators.
-zefram
stored.
-zefram
gle $output value could be a list of the form (True, $value)
to represent a normal evaluation result and (False, $ex) to represent
evaluation terminating by exception.
-zefram
ut got Str ("foo")
in block at line 1
Your single $output variable is too narrow to make the distinctions that
you need.
-zefram
reasonable for these error
messages to suggest calling those methods that do actually exist in Mu.
If you're getting antsy about the overridability of Mu methods, there's
an awful lot of code and documentation that should change to stop relying
on those methods, not just a couple of messages.
-zefram
essage is still wrong for those that are not (bag, mkdir).
-zefram
ed in the way that all other types can.
-zefram
This problem no longer occurs.
-zefram
This problem no longer occurs.
-zefram
).
If it's really intended to have this unique behaviour, incorporating
adjacent digits into a string part, then that needs to be documented.
There's no mention of it at present. I think more likely it was not
intended to be a unique category, and by accident has picked up a mixture
of the behaviours of intentional categories.
Point taken about me having used the wrong comparison operator.
-zefram
it should presumably yield a syntax error here.
-zefram
t; { say (.WHICH, .DEFINITE) }
(Str|U43431280 False)
(Str|U43431280 True)
> Str === "U43431280"
True
> ObjAt.WHICH
ObjAt|U43431256
> for ObjAt, ObjAt.new("U43431256") { say (.WHICH, .DEFINITE) }
(ObjAt|U43431256 False)
(ObjAt|U43431256 True)
> ObjAt === ObjAt.new("U43431256")
True
-zefram
h your mention of the status flag as explanation,
is that you regard this flag as being closely tied to the zero value,
which it is not.
-zefram
escribing what a floating point zero,
in isolation, represents.
-zefram
Brandon Allbery via RT wrote:
>Zefrem and I both misspoke on this,
In which aspect did I misspeak?
-zefram
Will Coleda via RT wrote:
>as of b5aa3c5, these both output 287369 now.
For clarity, that's still bad rounding, then.
-zefram
operly supporting signed zeroes.
-zefram
but got Pair (:c(2))
in block at EVAL_15 line 1
in block at line 1
Invoking Pair.perl would fix this too.
-zefram
Additional: this also happens with Complex literals, where the real or
imaginary parts suffer this as Nums.
-zefram
Additional: the same problem arises with Complex.perl, where the real
or imaginary parts suffer this problem as Nums. Fixing this for Num
won't automatically fix it for Complex, because Complex.perl doesn't
invoke Num.perl.
-zefram
Additional: the same problem arises with Complex.WHICH, in cases where
the real or imaginary parts suffer this problem as Nums.
-zefram
There was an attempt to fix this in 4d85cde9, and it does avoid clashes
between class objects, but it's introduced a new kind of .WHICH clash:
> Int.WHICH
Int|29060856
> for Int, 29060856 { say (.WHICH, .DEFINITE) }
(Int|29060856 False)
(Int|29060856 True)
> Int === 29060856
True
-zefram
on the question of whether the language's main scalar containers
should be reified.
-zefram
wonder whether .VAR is actually Perl 6 as opposed to Rakudo.)
It's mentioned in the specs. S12 specifically advertises using it to
get at Scalar objects. Scalar containers themselves are mentioned in
a few places, but not much elaborated on. As I said, it looks like
intentional reification.
-zefram
hidden
behind a MONKEY-SEE-NO-CONTAINER pragma then I'll accept that they're
not part of the supported language.
-zefram
3; my $A = $a.VAR; my $b = Pair.new($A.VAR, "z"); say $b.WHICH; $a =
> 5; say $b.WHICH
Pair|Int|3|Str|z
Pair|Int|5|Str|z
It would be better to reject the Scalar-as-key case entirely, rather
than unwrap.
-zefram
Brandon Allbery via RT wrote:
> *Scalar is not what you think it is*. It is
>*precisely* the implementation of mutable containers,
That's what I think it is. I'm mystified as to what you think I think
it is.
-zefram
n inconvenience for the Pair.WHICH implementor that
looking inside a bound container is the default behaviour.
-zefram
Additional: the Pair.key method also returns the content of a Scalar key,
rather than the key itself:
> my $a = 3; my $b = Pair.new($a.VAR, "z"); $a = 5; say $b.key.WHICH
Int|5
-zefram
outcome is what Liz then pointed out would be incorrect, though it
was never what I intended.
-zefram
ng a
sequence of object identities and strings. Individual classes should
only have to present the right elements that will go into an identity,
not put it together themselves.
-zefram
Additional: this also happens with submethods:
> (submethod { /foo/ })(2).perl
submethod /foo/
-zefram
08575457088".
-zefram
ership purposes.
That would be perfectly sensible if .WHICH reliably indicated identity.
-zefram
I wrote:
>> 3 === 3
>True
>> 3.WHICH.WHERE == 3.WHICH.WHERE
>False
Additional:
> 3.WHICH === 3.WHICH
True
> { my class Aa {} }().WHICH === { my class Aa {} }().WHICH
True
This seems to confirm that the string is the thing that matters.
-zefram
content of an
ObjAt. All the construction expressions are just wrapping up a string.
So eq does seem to be the appropriate way to compare ObjAt values.
-zefram
ing relying on decimal.
-zefram
# writable scalar references
my sub ref_to(Mu $a is rw) { my @s; @s[0] := $a; @s }
my sub read_ref(@s) { @s[0] }
my sub write_ref(@s, Mu $nv) { @s[0] = $nv }
# floating-point utilities (imitating most of Perl 5 Data::Float)
my @powtwo = (2e0,);
my @powhalf = (0.
ture on a
few builtins.) Perl 6, on the other hand, frequently has operations
silently pass through a container. (Named method calls on the Scalar,
where not handled by the Scalar class, used to be passed through to the
contained value, but that seems to have stopped working.)
-zefram
write through it.
-zefram
t; (making an lvalue from
the Scalar object), though as we've seen neither of these is correct.
-zefram
gns to that variable (or fails to assign to the parameter).
It shouldn't do otherwise, of course. Some other operator is required
to store into a Scalar.
-zefram
ther.
Is there some way I missed to get access to the content of a Scalar?
Something other than exploiting this bug? That's what I was originally
after when I ran into this.
-zefram
type of
mistake in numerical computation. You need to perform rounding only
once, straight to the output length: either during the binary->decimal
conversion, or after a binary->decimal conversion that produced all the
digits necessary to represent the value exactly.
-zefram
mber of
digits following the decimal point, which the standard has just spent
half the paragraph describing. The standard does go on to make clear
that it doesn't require the rounding to be correct, though.
-zefram
09992704e0").map(*.EVAL.Int)
(1180591620717411303424 1180591620717409992704)
Perhaps the compiler is coalescing the constants based on them having
identical .WHICH values, for which see [perl #128819]. The expression
"2e0**70" doesn't get the same treatment, so the coalescing can't be
happening after constant folding, if that gets folded.
-zefram
y exhibits the arithmetic behaviour of ordinary
binary floating point. Is there perhaps some underlying design decision
for decimal floating point that hasn't been carried through?
-zefram
example doesn't invoke
any operation requiring rounding. The initial decimal literal has the
exact representable value, which gets represented correctly as a Num.
I don't then perform any arithmetic on it.
-zefram
ou: what use cases are Instant.from-posix() and friends intended
to satisfy?
-zefram
want to expose a threshold-of-the-unknown date as well,
because there's more to leap schedule knowledge than just the dates of
actual leaps. If you expose it in writable form, I'd recommend writing
via method rather than via lvalue, to avoid tying yourself to the table's
current format.
-zefram
u
s always assume
that there will be no further leaps after the last leap second
that the implementation knows about, which may not be the last
leap second that has actually been scheduled.
-zefram
having the function throw an exception for anything
past 2014.
-zefram
code("utf8-c8").perl
Blob[uint8].new(244,143,191,189,120,69,57,1)
-zefram
igned to
the variable, regardless of whether the Scalar itself satisfies the type
constraint. Type constraints that do not have definiteness qualifiers
work as expected, and so do type constraints on subroutine parameters.
-zefram
scalar-make(33)
33
> scalar-get($x)
22
> scalar-get($y)
33
> scalar-set($x, 44)
44
> scalar-get($x)
44
> scalar-get($y)
33
> $x.WHICH
Scalar|128188776
> $y.WHICH
Scalar|128188776
> $x === $y
True
> scalar-get($x).WHICH
Int|44
> scalar-get($y).WHICH
Int|33
> scalar-get($x) === scalar-get($y)
False
-zefram
tained value.
> @a[0].VAR.say
22
> @a[1].VAR.say
33
> my $x = @a[0].VAR
22
> my $y = @a[1].VAR
33
> $x.WHAT.say
(Scalar)
> $y.WHAT.say
(Scalar)
> $x.say
22
> $y.say
33
> $x === $y
True
-zefram
he introspection
would be liable to see the IterationEnd value, even if it wasn't
spelled with a regular name. Reformulating "$a =:= IterationEnd" as
"is_IterationEnd($a)" could avoid this problem for the comparisons,
but it still arises for code that returns the sentinel.
-zefram
g a sentinel-delimited API specifically because
that identity comparison is cheap.
-zefram
g
from an iterator. But map can check its output: it can look at what
the user-supplied iteration function returned, and signal an error if
that's IterationEnd.
-zefram
This has now been fixed by commit 986f98d8c6d772ac5d0b513793c521df6a343ae8
from Timo++.
-zefram
It would be ridiculous to deny significance
to this sort of clarifying clause merely because it is syntactically
contained in parentheses.
-zefram
ng the ticket doesn't make sense, unless
you're rejecting my contention that there is such a mismatch or that
the mismatch is a problem needing rectification. Are you?
-zefram
y list. Invalid stuff now accepted:
"--01-01"
"12345-01-01"
"2015-01-0\x[666]"
-zefram
found dealing with the issue there.
-zefram
Commit 895546990f6001a5999ef, attempting to fix [perl #127004], has
added some more kinds of non ISO 8601 string that are accepted as input.
-zefram
Elizabeth Mattijsen via RT wrote:
>Fixed with 895546990f6001a5999ef
With that edit, some invalid year representations are now accepted on
input, such as "-" and "12345". They add to the scope of [perl
#127002].
-zefram
to generate from
those strings. They are not in ISO 8601 format, and the documentation
doesn't say what other string formats it accepts.
-zefram
also know my overall opinion of Perl 6, and that doesn't make Rakudo
an attractive bugfixing target for me. It seems best that my involvement
remain peripheral.
-zefram
Elizabeth Mattijsen via RT wrote:
>Good point. Followed your suggestion in 8ddfff5533d4d77dbd7da65 .
You're now duplicating the delimiters for those two. For IO::Path you've
removed the superfluous pipe escaping but retain the poor factoring.
-zefram
e deparsing system (for all types other than whichever
one you're working on right now). So you don't have to do the whole
deparsing job yourself, and in fact you get better results by doing less
of the work yourself.
-zefram
sed that as the delimiter.
>Zefram: I assume you checked all .perl methods in core for this, or
>should I look at them some more?
I looked systematically through rakudo/src, and the ones I mentioned
are all that I found.
-zefram
nd of its misbehaviour is reachable with
reasonable inputs that are fairly likely to arise in substantive programs.
-zefram
ute
?? "{$.abspath.perl}.IO({:$!SPEC.perl})"
!! "{$.path.perl}.IO({:$!SPEC.perl}, {:$!CWD.perl})"
-zefram
f quotation consisting of the literal angle brackets. You could
correct your code by changing the angle brackets to parens, following
the arrangement you used for the SPEC part, ":SPEC({$!SPEC.perl})".
You got quoting right once already (Str.perl). Stop trying to do the
same job again!
-zefram
t is, any ad hoc attempt to duplicate the quoting logic
is bound to be incomplete.
-zefram
Parrot Raiser via RT wrote:
>Does a shift value longer than the word length make any sense anyway?
With bignums, yes it does.
> -123 +< 200
-197653379443855803891661337357963000110230968235283518742069248
(Also, 32 isn't really my word length.)
-zefram
ity to bypass
type constraints.
-zefram
Parrot Raiser via RT wrote:
>prima facie evidence they simply don't know about the feature.
Or that they do know about the name scoping features.
-zefram
1 - 100 of 103 matches
Mail list logo
