he list (1,4,9)? And if $x happens to be a scalar
isn't it just squared? In the end we just need &map:( &closure, Set $data -->
Set) as an overload. Or perhaps &map:( &closure, Iterable ::T $data --> T).
Regards, TSa.
--
"The unavoidable price of reliability is si
disjoint operators.
This is why we have ~ for concatenation and not overloaded +.
It makes of course sense to iterate a Bag. But indexing it doesn't. We are
also not indexing into strings: "blah"[2] is not 'a'.
Regards, TSa.
--
"The unavoidable price of re
ith $three? Or is the topic the return
value of two() at that point?
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
... unless you want C to do a value-and-type check,
> in which case it doesn't exactly follow the pattern for smartmatching
> of the other builtin types (which only check value equivalence,
> not type equivalence).
This is true only if you want to distinguish 1 and True which are the
!" }
> whenever timeout() { say "Who cares what you say, time's up!" }
> whenever $override { say "Whatever, switching to automatic
> override" }
> }
Am I getting your intention to be that when honors the given and whenever just
checks truth? Couldn't we use if for this? That would avoid the new keyword.
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
> applying .reverse could result in a coercion to Sequence.
Swapping the endpoints could mean swapping inside test to outside
test. The only thing that is needed is to swap from && to ||:
$a .. $b # means $a <= $_ && $_ <= $b if $a < $b
$b .. $a # means
rations that is usable for type checking. But the where clause
is now only a closure that is called when needed. So { $_ < 10 } is not a
subtype of { $_ < 20 }. So no predicate dispatch either.
Someone should explain the dispatch algorithm to you. I don't remember
exactly how the voting ther
arameter irrespective of its use. E.g. you can declare a
read/write attribute of that type.
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
e object directly.
That is, in the scope of the binding the object goes kind of
naked.
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
ith an
Int, of course.
From a Huffman POV the roles for generic integers and rationals must be
short, so the Numeric and Rational roles in S32 are going in the wrong
direction.
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
iguous type conversion on Dogwood. So I change the
proposal such that a juxtaposition means Dog[::T:] Wood[T] which
nicely gives the Dogwood implementation of bark as requested by the
two roles.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"
opose to have a Dogwood class
and two auxiliary proxy classes for the Dog and Wood roles? Isn't that
too much effort? OTOH, a conversion routine could indeed return such
a proxy if the original shall be kept unchanged.
Regards, TSa.
--
"The unavoidable price of reliability is si
p. But then other non-Dogwood
Dog doers are excluded unless they have a Dogwood coercion routine.
Or they use the Dogwood class directly.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follo
m which does Real.
The default Rat is then just Rat[rat64:] for example. And the
instanciating class might also be defaulted lexically. Essentially
all types are then denominated in this form which uniquely identifies
a role/class combination by means of the colon in brackets after the
name.
low arbitrary role combinations without conflict.
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
ile---this is what you call wearing a role hat. We
should keep the class dispatch as simple as possible and not mix in
the environment of the call into the meaning of an object!
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does no
he primary concept. The object influences how it is done or what
is the output. The method can of course call mutating methods on the
object but this is a secondary concern.
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
utomatic procedure
and some nice syntax. But it looks to me as code analysis of T1
and T2 is needed to generate the wrappers in C.
One point I don't like in the paper is that freezing methods
can be used to erase methods from a role. This is diametrically
opposed to the intent of roles to ma
equivalent to '<='.
This last one is !after and !before is '>='.
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
't a
> stringifying version. :) That said, it may not be good for much more
> than that.
Yeah, sometimes orthogonality of features is too much of a good thing!
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
vector spaces of arbitrary dimension where one intersects hyperspheres
around two points. One can also generalise to non-euclidean metrics,
of course. Perhaps even a string distance function might work.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R.
x27;aaa' ~~ 'aa'..'az'. I find this
quite natural. Note that order is not a prerequisite for a notion of
range and range iteration. I think of ranges more like set and set
iteration. I'm going to post my take on the complex case elsewhere in
this thread.
Regards, TSa
nto-trouble examples involve $x++,
so we'll need to be careful with that particular monad^Wside effect.
Actually not. Every code object invocation is a get-into-trouble
example unless it is purely functional code.
Regards, TSa.
--
"The unavoidable price of reliability is simplicit
mixture of signature
and statement syntax inside \(). E.g. the question is if
\($x + $y is copy) is valid.
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 +
ad thing.
We should have my $x = 1; foo($x++,$x,$x++); to call foo(1,2,2)
and not foo(1,3,2) or even foo(2,3,1). The capture creation for
the foo call should be strictly left to right and capturing the
value at that moment.
Regards, TSa.
--
"The unavoidable price of reliability is simpl
ently overridden. Ones with an
implementation produce a warning if the composing class overrides
it without some extra syntax. This bites only the case where the
role provides a default implementation intended for overriding.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity
HaloO,
Jon Lang wrote:
I'd still like to get a synonym for "mandate role", though - a word
that captures the meaning of "unit of behavior".
A bit burdened with conflicting meaning but I think "mixin" is what
you are looking for.
Regards, TSa.
--
"
n use that to
switch over the xor:
given $x ^^ $y ^^ $z
{
when TooMany {...}
when TooFew {...}
when True {...}
}
A nicer set of return values would be Many, One and Zero. Numeric values
could be Many = -1, One = 1 and Zero = 0, so that they numerify nicely.
So can
refore see a single list of three values instead of
two consecutive lists of two items.
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
res the readonlyness suffices. Most of the
time not even that when the constness is known statically.
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
haps prefix:«{T}»? Note that
S14 just has methods with name T but how does that work at all.
Note that a type cast is written as a prefix call and the sub
dispatcher is not failing over to method dispatch anymore.
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
ry I believe it doesn't
pay off. IOW, objects are best kept eager.
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
is is needed
to implement the distinction between the mutating and non-mutating
interfaces of objects. Hmm, could the compiler infer this trait from
the body of the method?
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
C. Or would the code sequence above work also
with a capture instead of 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
from their lexically available definition!
So does the programmer if she bothers to look them up.
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
$x.STORE($y.FETCH);
}
Note that due to contravariance the type constraint of $lhs should
actually be the bottom type not Any. OTOH rw is invariant in general.
Only here in assignment the $lhs is write-only. But Perl 6 hasn't
specced that trait on parameters.
Regards, TSa.
--
"The unavoida
s are allowed outside of a class
scope. That is, the type constraint of the invocant inserts it into
the class. Perhaps in a non-privileged form, i.e. without access to
private attributes and methods. Does that make sense?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity
turn false if it is tested in a
subroutine, then perl6 junctions are not really modelling
quantum superpositions
I agree. We should make sure that junctions model quantum
computations.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does n
<= 0) or (0 <= +1 <= 0)" than it is to "(0 <=
-1 or 0 <= +1) and (-1 <= 0 or +1 <= 0)". The trick is to figure out
how to get this result without needing a nightmarish amount of
overhead to do it.
A structural analysis of the code that generates an auto-threading
poi
the resulting
junction any(0,0,0,0,0,1,1,1,1,1) is before the block. Thus
I'm opting for any(-4..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
TOH it collides with (+) visually.
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
eatures that Perl 6 provides which is relatively new to languages in
> general.
The concept of superimposed shapes is very well done in the Trisquirclehedron.
See http://lucacardelli.name/Topics/TheoryOfObjects/ObjectSubject.html
Regards, TSa.
--
"The unavoidable price of reliabilit
urn a code ref, i.e. &any, &all, etc.
A simple solution is to have subtypes of Junction like AnyJunction,
AllJunction, OneJunction and NoneJunction or perhaps like Junction::Any,
Junction::All, Junction::One and Junction::None.
Regards, TSa.
--
"The unavoidable price of
HaloO,
Larry Wall wrote:
Although, interestingly, if the method is exported as a multi it
should automatically add in the current role or class as a constraint
on the (former) invocant so that multi dispatch will not overgeneralize.
I would expect
class Foo
{
method bar {...}
s Num
gets the additional methods one way or another. But it seems
open classes have acquired a design smell of late. Or why is
the process called monkey patching?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede compl
ot;,
> and it would be immutable.
The only other name that comes to mind is RangeSet. But I prefer Interval
because this is the name of the concept in math.
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
dentity of an approximation closure and it is not required
from an implementation to render sin($x) == sin($x + 2*pi) even though
it is imaginable if $x contains a Num that has pi as approximation
closure so that an exact modulo can be put into the approximation
closure of sin's return value.
number
that is exact as far as relative error goes. Note that it can't
be subsumed by the other cases because that would produce 0..^0
which fails for 0 ~~ 0..^0 since that means 0 <= 0 < 0 which
is false.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" --
ve ‰ (promille) and ‱ (permyriad) as well. And when we are at
it .ppb and .ppt are common as well. At least Wikipedia has them.
There one also finds that ratios are expressed with the SI prefixes
like nano without a unit or U for uno. But I guess at the latest
this all belongs into a Ratio (standard
le
by making numeric $x ~~ $y simply mean $x == $y. What
is the benefit?
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
enforces an exact
match so there's no need for dynamic dispatch. I assume that an
'is rw' actually dispatches on the declared container type of the
lhs.
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
ical context give us a Duration?)
I guess not because 2..3 and 4..5 are equal as duration but not equal
as ranges. Here I assume that == is included in the list of operators
that S03 claims to be sensibly overloaded. That is 2..3 == 4..5 means
2 == 4 && 3 == 5 which is false.
Regard
ntics. That is if
you want to traverse a RootedTree you have to explicitly skip
the parent. But this can be easily remedied with a method with
a different name. E.g. we could introduce .nodes in RootedTree
and have a .trees method in Tree. From this we see that these
two roles should be designed
here clause parser know to default to numeric equality?
Through smart matching? Is that the default for a where clause with
no operator?
BTW, what is the supposed difference between these two forms?
I would favour the first on the footing that the where clause
belongs to the type.
Regards, TSa.
--
&qu
w. IOW, say could have the 'is pure' trait on its parameters and
on itself.
OTOH, S06 already propose an optimization hint, which should do what you
want, look for "is cached".
But that is for a completely orthogonal kind of optimization.
Regards, TSa.
--
"The unavo
mes. I know that the current design involves
dispatch to packages but I think that blurs the distinction between
packages and classes. If they are all the same anyway then why have the
module, package and class keywords? This is a bit too much redundancy for
me.
Regards, TSa.
--
"The unavo
ferent syntax to the proposed
form
class A::Foo {...}
class A::Bar {...}
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
HaloO,
pugs-comm...@feather.perl6.nl wrote:
-our Bool method getc (IO $self: *...@list)
+our Bool method getc (IO $self: Bool :async)
Shouldn't there be a sigiled :$async?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"
h is interpolated when the closure runs.
That is there are two nested interpolations! Note that you can't
use "{" to initialize a variable because it either ends in a syntax
error or as in the given example swallows some code into a string.
This works as you intent:
my $left = '
# the Capture object's named parameters, as a hash.
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
m wrong, but isn't context
just type information derived from the syntactic structure of the
source code?
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
@a I think the choice of @@a versus @a is a bit like the choice
between a @a and an anonymous array in a $ var ala $a = [] which
can be handled through $a almost like @a.
@a =!= @@a :test;
BTW, what does the :test mean there?
Regards, TSa.
--
"The unavoidable price of reliability is
27;m not
sure if the parens are necessary to pass the pair to say as argument
to be printed instead of a named argument that influences how the
printing is done.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complex
rained set of roles and types
composed of it by juxtaposition. This allows signatures to state
their requirements clearly and machine enforcable. IOW, your approach
precisely solves the problem that fat interfaces can raise errors
only lately, that is when a call is attempted.
Regards, TSa.
--
&
HaloO,
Darren Duncan wrote:
Michael G Schwern wrote:
TSa (Thomas Sandlaß) wrote:
I want to stress this last point. We have the three types Int,
Rat and Num. What exactly is the purpose of Num? The IEEE formats
will be handled by num64 and the like. Is it just there for
holding properties? Or
whether always-2 is a good
semantics, or whether one would prefer some other default.
My idea is to let a pair numify to whatever the value numifies to.
Same thing with stringification. In general I think that a pair should
hide its key as far as possible if used as non-pair.
Regards, TSa.
--
&quo
bit unperlish.
We have the pair of infix (!) operators min, max and the operator
minmax that delivers both values in one go. Copying that prior art
would simply mean to define divmod. I'm fine with that.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C
Int --> Rat) because this doesn't
need to be accompanied with a mod. That allows div on two Ints to
return an Int which complies to the general prescription for
overloading div and mod homogenously.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
x(1,0) === Int 1'? Should all these
be identical irrespective the fact that they come from three different
type domains? How is that implemented?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but
h that === compares
them.
(As you point out, you can always use something like "Weekday::Sun eq
Star::Sun" or "Weekday::Sun == 0" if you want string or numeric equality.)
Yes, these comparisons are well defined in the Str and Num domains.
Regards, TSa.
--
"The una
dispatch to the Rat versions of operators?
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
$a++;
fails when the Int 2 shall be written back into $a. I wonder if the
auto-generation of operators can be requested as follows:
enum A « :One(1), :Two(2), :Three(3) » does Int;
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"
traint on containers and in dispatch.
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
they shall become a set of lists or a set of sets.
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
e embedded closure refers to the strings
$^name. And now the dwimmyness shall make that implicit, right?
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
l unit sphere.
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
l unit sphere.
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
that to
1 ~~ Junction || 2 ~~ Junction || 3 ~~ Junction
Note that this demotion to object means that
any(1,2,3) ~~ Int
evaluates to false because the lhs is of type AnyJunction of Int.
To me this is the same as
[1,2,3] ~~ Int
which is false because there is an Array of Int not an Int.
he same analysis. Without
it the issue is left up to the runtime dispatcher. Both dispatch
targets treat the rhs different, of course. The ArrayItem case
builds an arrayref, the ArraySlice assigns the elements with
flattened @x.
Regards, TSa.
--
"The unavoidable price of reliability is sim
(1,2,3)
should be False because 2.WHAT is Int and any(1,2,3).WHAT is
Junction. Or are my expectations wrong?
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
So one()
is just another way of writing False ;)
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
d the juxtaposition Dog Cat.
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
ix:<==>(Junction,Num-->Bool)
that is not auto-threaded.
BTW, would it be useful to have auto-threading for Set as well?
That is, Junction inherits it from Set.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not prec
false because there is a one(1,0,1) junction? As
Duncan points out junctions are immutable values and as such
the % autothreads but the resulting values are assembled into
a new junction according to the general rules, i.e. one(0,1).
The number of elements in one(1,2,3) is not preserved.
Regards, TSa
h quantification.
BTW, IIRC there are signatures in rules but I can't find it in S05.
Where is 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
HaloO,
David Green wrote:
On 2008-Oct-22, at 10:03 am, TSa wrote:
Note that types have a fundamentally different task in a signature
than name and position have. The latter are for binding arguments to
parameters. The types however are for selection of dispatch target.
Names do that too; I
asier than naming
the n! sigs for a routine with n parameters. This is somewhat
unperlish. OTOH, an 'is commutative' on a six parameter multi
looks innocent whereas a routine with 720 sigs is impressive.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" --
rays that auto-flatten into a list and become real
arrays in a slice?
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
s.
But then we need a way for the programmer to specify how these approximations
shall be handled.
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
rints 1
say $x + $y; # prints 0
It is a cleaver idea to make the operator choose an appropriate
value for a Nothing value. Why having that only for meta operators?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede co
ea of using the type system to represent
trees and dispatch for transformations like CDuce does it.
See <http://www.cduce.org>.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity, but follows it.&quo
HaloO,
one nifty thing could be negation propagation in chained
comparisons: ($a ne $b ne $c) === !($a eq $b || $b eq $c).
This again insures some sanity if any of $a, $b or $c are
junctions. BTW, the boolean connectives &&, || and ^^ shouldn't
be auto-threaded through junctions.
([!==] $a,$b,$c) mean !([==] $a,$b,$c).
I have no idea how difficult such negation propagation in parse trees
is.
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 +
st. But I would
include zero and use a name like UInt that has other uses as well. Are
there pragmas that turn signature failures into undef return values?
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.R. Hoare
"Simplicity does not precede complexity
iant
typing of output parameters. Parameters with 'rw' have to be
*invariant* unless we manage to split the meaning of the type slot
in 'rw' parameter declarations between input and output.
Regards, TSa.
--
"The unavoidable price of reliability is simplicity" -- C.A.
HaloO,
Daniel Ruoso wrote:
Qui, 2008-09-18 às 18:11 +0200, TSa escreveu:
Shouldn't there be a warning in B that $!B::bar overwrites $!A::bar
without an accessor?
Actually, $!B::bar doesn't overwrite $!A::bar... the problem is simply
that $!A::bar is not visible from inside B, and
HaloO,
Carl Mäsak wrote:
I really like all the replies I got to this; thank you Moritz,
Jonathan, TSa, Larry, John and Damian.
It was a pleasure to be useful.
From the feedback I received, I will now do the following:
1. Remove "is rw" from all attributes that aren't
HaloO,
John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-vts-systems.de |Perl 6| wrote:
Is it generally foreseen that an object knows about the containers
it is stored in?
Yes. But it is not generally the case that this is the same container
as the caller is holding. Detailed specifications of
eds attribute access into dispatch and makes
base methods future proof with respect to deriving classes.
Your 100% rw observation then to me indicates that OO is more
about data sharing than method dispatch. Note that rw accessors
are particularly difficult to handle in typesafe mode.
Regards, TSa.
--
HaloO,
Moritz Lenz wrote:
TSa wrote:
The 'is rw' is on the method but I guess it is foreseen that the
result is stored in $string without preserving the identity of the
string?
No. It means that the Str object has to get hold of the container in
which it is stored, and store a mod
1 - 100 of 654 matches
Mail list logo
