s I would like to define + and * to
be listfix and commutative, that is independent of order. Note that
this is orthogonal to the definition of evaluation order.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
no relation at all. And Bivariance
means both!
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
And what is a protoinvocation of a sub? When is it evaluated?
Finally I wonder why we didn't give a meaning to Type<>? Does that
look too much like C++, C# or Java templates?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
g!
To address this, I propose using a positive way to declare generic
parameters rather than having them implicit based on not previously
existing. I propose the triple colon, :::, for this purpose:
:::T $x;
Which is ugly.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
hat does a structural inspection.
Would that be worth an addition to Perl 6? We already have
'can' for single methods.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
ise
that binding cannot be overloaded and this really is
where the type checker kicks in. But what exactly is
it supposed to do then?
I guess the generic answer is that there will be installable
pairs of dispatcher and binder. Which then raises the question
what the standard set will be :)
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
two delegations at work
these would be @?USA and @?GERMANY. I really love the linguistic power
of Perl 6 :)
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
foo; # syntax error or special type meaning
foo ; # calls foo with @_[0] :=
foo .; # calls foo with @_[0] := $CALLER::_.
foo::; # pulls out a from lexical namespace of foo
The last line uses postfix:<::> not sigil:<::>.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
the value type?
You mean capturing the sigil? I guess using $ is as generic as one could
get. @, @@ and % essentially are type constraints. So
sub (::Container[of => ::ValType] @x)
already constrains ::Container to Positional.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
y be Real^NaN^Overflow^...
so that if you wanted a non-exceptional type you could use Real.
Note that this implies that Num is *unordered* and the order-ops
actually act on the Real type.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
++; }
&f = &foo.new; # or also foo.new?
say f(); # 0
say f(); # 1
say f(); # 2
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
HaloO,
I wrote:
sub foo () { my $x = 0; yield $x++; }
I meant:
sub foo () { my $x = 0; yield $x++ while 1;
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
t; Int is expected. I love this self contradiction of Perl ;)
Well, and you can't neither use foo nor bar to denote the arrow type.
Note that I consider myself a knowledgeable bystander with the
knowledgeable being debatable ;)
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
Num <: Item <: Seq which is a cycle!
Dealing with cycles is not within the reach of type system because
these need <: to be transitive.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
else considered
harmful but useful). But I don't see much use for it offhand.
Does that imply that multiple assignment is second-class, too?
And that with a language that provides the concept of eternal
equality with ===, or checking of referential identity with =:=.
Big surprise that is.
Re
se
classes will be checked for applicability rather than arbitrarily
taking the leftmost.
Indeed, I would hope that order of inheritance doesn't matter.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
bsumes Item. But that has problems of its
own---see my reply there.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
t the item positionally with prefix @ or .[]. Note that Captures
are immutable and therefore nicely covariant. Except of course that
containers are captured as containers and can be mutated. But Larry
revealed that single assignment semantics are aspired and mutability
is a historic artifact or so.
Re
terpret that sort of
intensionally as being worse than an outright violation. That
is already the tendency of violation means second-class ;)
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
ing type errors.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
HaloO,
John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
"Candidate set" would be a better term. It is a subset of all long names
of a multi in a lexical scope.
List, not set, because it is ordered. nextsame/nextwith/etc. are
described as invoking the next
same
implementation. In both cases C is OUTER::C. The "magic" should
happen when an invocation of foo is created. That is the moment when
the scope of OUTER::C can be bound by 'my C $b' through $x and $y
respectively.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
ually clearer to bind a namespace ref
than calling a magic function. It sort of amounts to the same
outcome, though.
I will also have to say something about the usefulness of the
concept of virtual class. Stay tuned.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
7;.
Side question: how binary can M be when compiling P? In C++ e.g. the
template code of D has to be available. Are there interface files in
Perl 6?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
$y; # syntax error or 5 in type position?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
ype system as part
of the runtime environment. That is there is a type computation going
on in parallel to a value computation. The meta object system is largely
part of the value system. The things the type system does at runtime is
checking assignments, checking bindings, selecting dispatch targets and
instanciating parametric types.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
; she has to cast that
to Str: ("10" as Str)--. So we have "10".HOW === Str but "10".WHAT ===
Num Str.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
HaloO,
I wrote:
subset Five of Int where {$_ == 5}
is the corresponding type
my Five $x; # effectively a constant
my 5$y; # syntax error or 5 in type position?
Would
my :(5) $z;
work as a type literal?
Regards, TSa.
--
"The unavoidable price of reliabili
quot;;
}
else
{
say $x;
}
}
foo(inf8 127); # prints "transfinite"
foo(127); # prints 127
foo(int8 127); # prints 127
and type unions only sweep
the problem under the rug of multiple dispatch, and you still have
to teach the newbies.
I agree with that.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
th something that delegates class methods and overrides
stringification etc. The things you can call on them are different. They
could not be implemented as the same object.
How would Str be implemented then? It is more concrete than a role but
more abstract than a class.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
me around that one. Of course it needs more
to implement a type. In addition to the ThreeChars subset constraint
it needs a whole bunch of multis to handle it and some meta level
infrastructure to support it value-wise.
Regards, TSa.
--
"The unavoidable price of reliability is simpl
# do it the old way, I just ported my program.
$x++ :field # I'm interested in preserving lengths of runs
$x++ :num # Preserve meanings of things that look like numeric
literals
$x++ :order # I'm interested in preserving comparison order
Just an idea, especially the first one.
This is a very good idea. But I would replace :field with :length.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity"
-- C.A.R. Hoare
HaloO,
John M. Dlugosz wrote:
for @foo {...}
is actually short for:
for @foo <-> $_ {...}
Ups, I missed that one. Do we also have the fill-me idiom
for @foo <- $_ {...}
And again the question if this is the same as
for @foo -> $_ is ref {...}
Regards, T
apply to assignments after the binding was done?
I think the only reasonable way is to enforce their logical and written
with type juxtaposition.
my A B $c;
$c = $x; # checks $x ~~ A && $x ~~ B
$a = $c; # OK
say $b; # prints value of $x
In summary I think that $a :=
This is very useful to interface between typed and untyped code.
With rthe 'like' the role Point has to be *nominally* available
in the argument. There's no problem with 'like'-types beeing more
expensive than a nominal check.
Regards, TSa.
--
"The unavoidable pric
information
to find the *named* concept Point. The FoxPoint in John's
example doesn't have that and thus nominally fails the
Point test. The idea is now to also have
sub foo (Point $p) {...}
to mean
$capture[0].^like(Point)
which does a *structural* analysis.
Regards, TSa
h applicable
signature. Then I think that we have
%h.does(Point) === False;
%h.like(Point) === True;
with the second test being more elaborate and hence more expensive.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
em signals an error if it can't find a
suitable solution given the constraints. E.g. on the value level
my Int $x; $x + $x == 7;
is unsolvable. The same can happen on type level.
Hope that helps, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1
at the typed code remains typed and the feature is
implemented as a trait that can be used to any object, thus leaving the
fragile type inference to the code calling the method and not to the
method that wants a stronger typing...
I don't understand what you want to say here.
Reg
John M. Dlugosz wrote:
> I wrote a complete treatment of Inf support.
> Please take a look at "24.26 Infinite" on pages 116-119, and
> "3.11.3 Infinities" on pages 26-27.
I have a lot to say to that. Please give me time.
Regards, TSa.
--
"The unavoidable
n we must read different versions of S03. Mine has the
sentence "Two values are never equivalent unless they are
of exactly the same type."
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
mean does the
meta object system know about the constraints of all bindings
and stored references to an object?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
HaloO,
just to deepen your understanding of co- and contravariance
you should digest <http://www.pps.jussieu.fr/~gc/papers/toplas95.pdf>
The important point to get from it is that dispatch-relevant
parameters are also covariant.
Regards, TSa.
--
"The unavoidable price of rel
HaloO John,
interesting to note that you are now nailing down things that
I'm advocating for quite a while. Are you sure that Perlkind
is following? E.g. $Larry hasn't written 'isa' into S12 yet.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity&qu
rder typing is the idea,
and I'm just trying to work out the ramifications and details that are
in-tune with the orthodox documentation and discussions here.
Hmm, I always had the impression of strong headwind.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
are
defined outside of the class or object system. There is an inheritance
order on HOW space and a subtyping order on WHAT space. Class based
dispatch goes along the former, type based dispatch along the latter.
The object that changes class should not be eqv or === to itself before
the transition
ype system is part of the language
core. As such 'isa' and 'like' or assignment and binding semantics
need a definition.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
HaloO,
John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
multi infix:<=> (Any $lhs, A $rhs)
{
$lhs.STORE($rhs.clone); # or .cow if that's not automatic
}
$lhs.VAR.STORE.
I guess I also forgot the is rw to get a binding to the caller'
er ( mysub &f ) {...}
sub yoursub does mysub {...}
mysubuser( &yoursub ); # OK
sub blahh (Int $x) does mysub {...} # composition error
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
HaloO,
John M. Dlugosz wrote:
Hmm, I always had the impression of strong headwind.
How so?
Take e.g. my supertyping proposal. I guess it was regarded as
a curiosity rather than an innovative feature.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.
relax the
syntax if that were possible because e.g. '3 == log:base(2) 8' looks
more natural than '3 == log 8 :base(2)'. Or '3.001 ==:eps(0.1) 3.01'.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
blished
concept elsewhere in the language.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
to accomplish. Then
refactor that into a set of real features that span the target feature set.
I think that invariance of rw or ref parameters is a too tight
constraint.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
and let go CGI instances wherever a CGI::Simple is expected.
As added value you can get a compiler check with
CGI does:strict CGI::Simple;
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it.&qu
s well. Getting at methods through an object is a very good
implementation strategy for single dispatch that's all. For MMD that
simply breaks down and the method is up front.
Now the other important feature of classical OO is privileged access
to internal or hidden data---encapsulation for sho
e HOW or WHAT of CGI this operation is a no-op.
I'm actually not sure that you can have 'CGI does CGI::Simple', since
CGI::Simple is not a role...
An intermediate, anonymous class is a mere implementation detail ;)
Regards, TSa.
--
"The unavoidable price of reliability is
and 'is copy' fit in your sort order? My reading is
that the parameter traits are *not* dispatch relevant. Therefore
your two multis are an error because of indistinguishable signature.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
&quo
tibility of CGI with CGI::Simple this
amounts to creating a WHAT that has SGI::Simple in its does-list
and leave the HOW with CGI.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A
back to a declared emulation. What else should be in this check
sequence?
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
# $b.m($b.new) works the same
}
Note that the body of Base::m could be shared, but Derived::m might
be a different entry point that binds "virtual" names differently.
An interesting question is if BEGIN, CHECK and INIT blocks of m should
run once in every scope.
Regards, TSa.
--
&quo
h would be to allow trait annotations
only on the proto or make differing traits an error in subsequent
multi declarations.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J. Per
n't thought that through but it might even be possible to
drop & as a sigil and get it as a prefix op.
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
rge at any given point in time. Other Orwellians are the compiler,
the namespace manager, the grammar engine, the dispatcher etc.
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
in order to actually bootstrap the system, but that's not what
the type system is.
Would you be so kind to enlighten me what the type system is, if
not a type calculation overlaid over a value calculation?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.
utes the
implementations from the input types then you can eagerly call
that at compile time or lazily at runtime. In the latter case you
can cache the implementations if you like. But you can also forget
them as needed because they can be re-computed. Thus dispatch is
just an implementation st
eq it is Str. Both map 1:1 to their respective WHICH sets. The
=:= checks binding of names so it is an equivalence relation
on a set of names. But I'm unsure if such a set is denoted with
WHO or VAR. But I tend to think it's the latter.
Regards, TSa.
--
"The unavoidable price of r
so get a nice name, e.g. Abs. This in turn would
make the abs multi method/sub kind of redundant.
I guess that the standard set of functions/methods mustn't contain
a norm as extension to the above.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A
nner and bar::inner classes as in
class foo
{
our class inner { has $.x = 3 }
}
class bar
{
our class inner { has $.x = 4 }
}
say inner.new.x; # error: no inner in scope
My personal idea is to unify class and sub by allowing sub to do
Package.
Regards
HaloO,
Jon Lang wrote:
My thoughts:
.HOW returns information concerning the implementation type; .WHAT
returns information concerning the value type.
My addition to these thoughts is that the WHAT and HOW are
cascaded. Let's say we start at level 0 with the objects,
thingies or however we want
lt; 8. But note that it handles the two Ds as As instead of Cs
as in single dispatch.
Dispatch has to go to the single most capable implementation
*not* to the least misfit! The call above has to be brought
to the attention of a programmer.
Regards, TSa.
--
"The unavoidable price of relia
.
That's it.
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
me analysis what the programmers might have meant?
So Perl 6 requires AI?
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
there is *no*
*Main::inner class at all. In particular there should be no
re-definition error in bar. This is exactly the behavior I want for
subs as well.
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
want to point out
remains, though. The two Ds are handled as As where a C
treatment was available. The point is that metric MMD here
either fails on E or D to be most specific.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity d
int * const)?
I'm too lazy to look up the details, sorry.
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
exception catching might simply result
in an abortion.
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
.
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 fol
ust
return the base type. Probably a .where method would return extra
constraints, if any.
Note that constraints are special closures that always return either
True or False, never throw exceptions and have no side effects. To
use them for type checking is easy. You just call them with a value.
B
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?
mul
t from C
without adding additional roles are incomparable to C as far
as WHAT is concerned but all of them will eventually end up as
subtypes of A&B in their WHAT if containers and the dispatcher
use automatic type re-assignment.
Regards, TSa.
--
"The unavoidable price of reliability is s
o you missed transfinite ordinals which can be very useful.
I'll be offline for two weeks, 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
n 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
I missing something?
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
say $f; # prints 1
$f.resume while $f != -1;
say $f; # prints -1
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
{
yield $inch = $.mm * 25.4;
self.mm = $inch / 25.4;
}
}
Would you regard that as elegant?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it."
HaloO,
Dave Whipp wrote:
TSa wrote:
class Length
{
has Num $.mm is rw = 0;
method inch
{
yield $inch = $.mm * 25.4;
self.mm = $inch / 25.4;
}
}
Would you regard that as elegant?
That looks functionally incorrect to my eyes: if the
3 = 4' to
infix:<=>:(Int is rw, Int) with an anonymous container for 3. Thus
you get the side-effects and no error!
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
write-out of rw params not dispatched through
infix:<=>?
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
called
Min and Max respectively. IOW, the whole type based aproach to Inf
is reduced to mere notational convenience.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it." -- A.J.
t very reason I gave here, IEEE-754 distinguishes
-0 and +0 just like it distinguishes -Inf and +Inf. And there are
contexts where -Inf === +Inf makes sense just as -0 === +0 makes sense
and some where it doesn't. Now, how are these contexts distinguished?
Regards, TSa.
--
"The unavoidabl
to detect that failure is another
question. But a good enough optimizer makes bad enough programs
reveal their realness or lack thereof ;)
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows
t alter
the object of concern in any way. Note that the where blocks are
executed from within the type-checker or the dispatcher where no
assumptions of the call environment other then the object should
be made.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C
ition of
Perl 6?
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
te that I make the conceptual unifications
of class and sub definition on the one hand and an object and an
invocation on the other. In the object case the self built-in refers
to the object. Would that work in a STORE or FETCH block of a sub
as well?
Regards, TSa.
--
"The unavoidable pr
itches from Item to List and back.
This would save lots of overloads in Any in favor of a handful of
standard coercions. These need proper anchorage in the dispatch
system, of course. That to me means we need some definition of
"conversion quality" and "conversion distance".
Regar
0;
$x++;
say $x; # int 314159265358979323847
# or int 31415926535897931
# or num 3.141592653589794e20 for 64bit float?
The last two options above are because $x.step == 1e5.
The exact value would need a float with 22 digits mantissa,
i.e. a quad precision.
Regards, TSa.
, ++$x
== $x.
Hmm, for this last case we could make '$x++' mean '$x += $x.step max 1'
so that for large native nums ++ makes progress. If I got Larry
correctly then Num is automatically extending precision so that the step
size remains 1.
Regards, TSa.
--
"The unavoidabl
{ $^a <=> $^b };
Is that the adverbial block syntax? If not how
would it look?
my @s = sort @a :{ $^a <=> $^b };
Or with a comma after @a?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, b
short everything that falls
out of the finite range of these types and is captured in Int or Num.
BTW, with an infinite precision Num I see no need for the Rat type!
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does no
business. But why
should it be necessary here?
foo(1, 2.5, 3.4); # Ambiguous dispatch error, or 3 because only one with
arity match?
Yeah, only #3 in the applicable method set.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does no
301 - 400 of 657 matches
Mail list logo
