Reversing the associativity makes sense, but having equal precedence for
operators with differing associativity sounds -- as you say -- like madness.
Even having non-associative mixed with either-sided-associative sounds like
a problem.
In general, perhaps we should forbid equal precedence with
Hmmm, what about just implementing mmap-as-string?
Then, assuming the parsing process is somewhat stream-like, the OS will take
care of swapping in chunks as you need them. You don't even need anything
special to support backtracking -- it's just a memory address, after all.
-Martin
On Thu, 14
On Wed, 19 Sep 2012, GitHub wrote:
> Log Message:
> ---
> Add expmod and is-prime as built-ins in Int
> +Returns True if C<$x> is known to be a prime, or is likely to be a
> +prime based on a probabilistic Miller-Rabin test. (The optional
> +argument tells how many times to iterate
On Thu, 22 Mar 2012, Carl Mäsak wrote:
> Jonathan Lang (>>), Daniel (>):
> >> 1, 2, 4 ... 100 # same as 1,2,4,8,16,32,64
> >
> > That last one doesn't work on Rakudo :-(
>
> And it never will. Note that 100 is not a power of 2, and that the goal
> needs to match exactly. This is because smartmat
> Damian:
> > The whole point of having BUILD() is to separate allocation
> > concerns from initialization concerns.
On Thu, 2 Feb 2012, yary wrote:
> And that's not so good, because it forces BUILD to be used for
> initialization, and precludes initializing private attributes anywhere
> else, lik
Out of curiosity, I followed this and read through "Str".
When I got to the section on "sprintf", I found a few things I think need
attention.
1. There isn't any description what the flags do, in particular 'v', which
seems to be a P6 enhancement.
2. Not mentioned are 'hh' (native char), 'j' (na
On Fri, 9 Sep 2011, Carl Mäsak wrote:
> Patrick Michaud said something (I think AFK) that seems essential to
> me: the non-rw-ness of these objects isn't a trait of *the object
> itself*, it's a trait of *the context in which the object is used*.
In one sense that is true, but if that's the only
On Wed, 17 Nov 2010, Richard Hainsworth wrote:
> Once a number has been generated, viz., by obtaining a duration, that number
> can be manipulated however necessary. The interpretation of the number is a
> matter for the programmer, not the language designer.
All true.
However I'd argue that you
On Thu, 28 Oct 2010, Damian Conway wrote:
> The apparent paradox ... is due to the assumption (employed in the
> second interpretation) that < is identical to !>=. Certainly that is
> true for simple scalar numbers, but not always for vector types such
> as tuples, sets, bags, complex numbers...or
I have to admit to feeling uneasy about the whole action-at-a-distance
effect that junctions are capable of producing. They sit around pretending
to be a scalar, only to pop up and wreak havoc with ones expectations of
linearity when you're not expecting it.
That unexpected-action-at-a-distance i
On the one hand, I've had 25 years of being annoyed about the idiom
if foo() == True ...
So I'd be delighted if P6 were to treat that case as a fatal compile-time
error.
And given that "==" are "!=" are just funny ways of writing "!xor" and
"xor", that prohibition could reasonably be ext
On Wed, 28 Jul 2010, Darren Duncan wrote:
> I think that a general solution here is to accept that there may be more
> than one valid way to sort some types, strings especially, and so
> operators/routines that do sorting should be customizable in some way so
> users can pick the behaviour they wan
On Wed, 7 Apr 2010, yary wrote:
> 2010/4/6 Larry Wall :
> > Set(Read | Write) # bogus, R|W is really 3 sets, R, W, and RW!
> > Set(Read & Write) # okay, can only represent RW
>
> Set(A | B) doesn't seem so bogus to me, if what you want is the power
> set
Hmm, surely a power-set would be
> On Mar 27, 2010, at 15:43 , Darren Duncan wrote:
> > For example, say you want to define a graph of some kind, and for
> > elegance you have a separate container and node and side classes,
On Sat, 27 Mar 2010, Brandon S. Allbery KF8NH wrote:
> This sounds like a hackaround for an incomplete impl
On Mon, 15 Mar 2010, Mark J. Reed wrote:
> > Anything that can be made into a list is discrete.
>
> Not quite, since you can create lists whose members belong to
> continuous sets, e.g. real numbers. Anything that naturally forms a
> list, maybe.
A discrete non-finite set is isomorphic to the se
On Sun, 14 Mar 2010, Jon Lang wrote:
> Ruud H.G. van Tol wrote:
> > Did you consider "discrete"?
>
> I think that "Discrete" could work quite well as the role that
> encapsulates the ways in which Integer and Gauss are alike. It may
> even be genralizable beyond that, although there might be some
On Tue, 17 Nov 2009, pugs-comm...@feather.perl6.nl wrote:
> +++ docs/Perl6/Spec/S02-bits.pod 2009-11-17 18:37:41 UTC (rev 29113)
> @@ -2735,10 +2735,11 @@
>
> =item *
>
> -Complex literals are similarly indicated by writing an addition of
> +Complex literals are similarly indicated by writi
On Wed, 21 Oct 2009, Ben Morrow wrote:
> The most important detail here is that the *class* gets to pick which
> imported methods need to be wrapped.
[but]
> What this doesn't fix is that some other code (outside the class) will be
> expecting C::x to have T1::x semantics, and some will be expectin
On Wed, 19 Aug 2009, Timothy S. Nelson wrote:
> ..but Perl is more magic than bash :). Seriously, I can see both
> sides of the argument, and I'm leaning towards the $*CWD = chdir idea (as an
> option if people want to use it), but I realise that a lot of people are
> leaning the other way.
On Thu, 2 Jul 2009, TSa wrote:
> Martin D Kealey wrote:
> > This solves both the human expectation ("Would you like wine or beer or
> > juice?" "Beer and juice please" "Sorry...") and the associativity
> > problem: (a ^^ b) ^^ (c ^^ d) == a
On Wed, Jun 24, 2009 at 10:35, John Macdonald wrote:
> Which means that short-circuiting is not right here - it must
> go through the entire list to determine whether there are zero
> true selections, find the first of exactly one true selections,
> or die if there are more than one true selection
On Fri, 19 Jun 2009, Martin D Kealey wrote:
> To that end I would propose that:
> - parameters should be read-only AND invariant by default, and
> - that invariance should be enforced passing a deep immutable clone
>(*5) in place of any object that isn't already immutable.
> Matthew Walton wrote:
> > If a user of your API contrives to make it change while you're
> > running, that's their own foot they've just shot, because they can
> > look at the signature and know the semantics of the parameter
> > passing being used and know that if they change the value external
On Wed, 1 Apr 2009, John Macdonald wrote:
> If I understand correctly, (which is by no means assured) a function
> call with a junction as an argument generally acts as if it were
> autothreaded. So:
>
> $x = any(1,2,3);
> $y = f($x);
>
> should work like:
>
> $y = any( f(1),
On Wed, 1 Apr 2009, Richard Hainsworth wrote:
> A closer examination of Martin's message indicates that he tends to think
> that hitting a junction ought to thread the entire program throughout the
> rest of the lifespan of said junction
Yes -- and well put, thank-you.
The trick is that since con
On Mon, 30 Mar 2009, Jon Lang wrote:
> Here's another useful one:
>
> any($x) eqv all($x) eqv one($x) eqv $x
>
> but:
>
> none($x) !eqv $x
>
> That is, applying any, all, or one to a one-item list produces the
> equivalent to a single item. For an empty list: any() eqv all() eqv
> (). But
On Mon, 9 Mar 2009, Larry Wall wrote:
> the only difference between C and C is that you can only use
> C at the start of a statement. But we're more liberal about where
> statements are expected in Perl 6, so you can say things like:
>
> my @results = do for @list -> $x {...};
> my @resul
On Thu, 26 Feb 2009, pugs-comm...@feather.perl6.nl wrote:
> +The exceptions are:
> +
> + Signal Action R Comment
> + --
> + ControlExceptionSigHUPTerm? Hangup detected on controlling terminal
> or death
On Thu, 26 Feb 2009, Martin D Kealey wrote:
> On Wed, 25 Feb 2009, Timothy S. Nelson wrote:
> > I'm in favour of retaining the $[ functionality, but lets give it some
> > name like $*INDEX_BEGINNING or something like that, so that it's quite
> > long for pe
On Thu, 26 Feb 2009, Jon Lang wrote:
> asin is not the inverse function of sin, although it's probably as close
> as you can get. And even there, some sort of compiler optimization could
> potentially be done, replacing the composition of asin and sin (both of
> which have the potential to intensi
On Wed, 25 Feb 2009, Timothy S. Nelson wrote:
> I'm in favour of retaining the $[ functionality, but lets give it some
> name like $*INDEX_BEGINNING or something like that, so that it's quite
> long for people to type :).
Surely the interpretation of the index should be up to each array-type?
r
On Wed, 25 Feb 2009, I wrote:
> $y + ±5 # same as ($y - 5) | ($y + 5) (also same as $y - ±5)
> $y ± 5# same as ($y - 5) .. ($y + 5)
A further question: should such ranges be [closed], (open) or [half-open)?
I would argue for half-open because then exactly one of a set of consecutive
r
On Tue, 24 Feb 2009, Jon Lang wrote:
> $y ± 5 # same as ($y - 5) | ($y + 5)
> $y within 5 # same as ($y - 5) .. ($y + 5)
I suspect that we're running against Huffman here, given the likely
usage -- ranges *should* be used at pretty much every floating point
"equality" test, whereas "any(-
On Mon, 23 Feb 2009, Timothy S. Nelson wrote:
> I have a quick question here. S16 claims to be about IPC, IO, and
> Signals. So far, it's mostly about IO. My question is, is it intended
> that IPC and/or signals be part of the core, or should they be converted
> to addons like Form.pm?
Conceptu
On Mon, 23 Feb 2009, Timothy S. Nelson wrote:
> > > > Renamed Temporal::Instant to Temporal::DateTime
> > >
> > > Hmm. We had some mailing list discussion about this, and agreed on
> > > Instant. I'd like to see your reasons in favour of DateTime.
> >
> > Because DateTime makes sense and is a c
On Fri, 20 Feb 2009, Dave Rolsky wrote:
> > > Renamed Temporal::Instant to Temporal::DateTime
> >
> > Hmm. We had some mailing list discussion about this, and agreed on
> > Instant. I'd like to see your reasons in favour of DateTime.
>
> Because DateTime makes sense and is a clear description of
On Wed, 18 Feb 2009, Timothy S. Nelson wrote:
> I'll try and design an API that does what DateTime does, but:
> 1. Uses more variables, of which I expect the getters and setters to be
> overridden.
Please let's NOT have setters on "time" objects. They're a source of subtle
bugs in such client co
On Tue, 17 Feb 2009, TSa wrote:
> I fully agree that immutability is not a property of types in a signature.
> But a signature should have a purity lock :(Int $i is pure) that snapshots
> an object state
[...]
> Note that this purity lock doesn't lock the outer object. It is only
> affecting the i
On Mon, 16 Feb 2009, Jon Lang wrote:
> if there's any doubt about the matter (e.g., conclusively proving or
> disproving purity would be NP-complete or a halting problem), then
Deciding whether you have a halting problem IS a halting problem... :-)
-Martin
On Fri, 13 Feb 2009, Jon Lang wrote:
> In reading about functional programming, I ran across the concept of
> the "pure function" - i.e., a function that doesn't produce side
> effects.
[...]
> It occurred to me that this business of marking functions as pure could be
> done in perl by means of tra
On Wed, 21 Jan 2009, Damian Conway wrote:
> > Maybe something in all caps. For what it's worth, :OK<> can be typed
> > with one hand while the other holds down the shift key. :)
>
> Typical right-hander fascism!
On the other hands we have :QA ... which also so happens to be an apposite
abbreviati
On Tue, 25 Nov 2008, Dave Whipp wrote:
> Brandon S. Allbery KF8NH wrote:
> > Still misunderstanding, I think. Yes, it will fail anyway, but in the
> > general case you're checking to see if as a privileged process it is safe to
> > operate on a given file.
>
> I'd actually been thinking that one w
On Tue, 30 Sep 2008, Patrick R. Michaud wrote:
> Just for pedantic clarity, what C< $directive ne 'VAR' & 'LOOP' & 'IF' >
> really gives is
>
> all( $directive ne 'VAR', $directive ne 'LOOP', $directive ne 'IF' )
>
> In other words, the result of the expression is an all() Junction. In
> boole
I would like to chip in in favour of the "list is value, array is container"
side of the argument. However I think that needs clarifying.
A reference is a value; the thing it refers to is a container.
An anonymous container is a container with no references from any symbol
table. It can lose it
On Tue, 11 Feb 2003, Michael Lazzaro wrote:
> What is the utility of the perl5 behavior:
>
> \($a,$b,$c)
>
> meaning
>
> (\$a, \$b, \$c)
>
> Do people really do that? ... Can someone give an example of an actual,
> proper, use?
Yes, I've used it like this:
for (\($a,$b,$c)) {
On Thu, 2002-11-21 at 20:11, Brent Dax wrote:
> Are you suggesting this?
>
> if($error) {
> use visible '&croak';
> require Carp;
> import Carp: 'croak';
> croak($error);
> }
No - that would be pointless as well as error-prone.
On Thu, 2002-11-21 at 06:57, Mark Biggar wrote:
> Martin D Kealey wrote:
> > I want Perl to run 128 times faster on a 128 CPU machine... now I know
> > that's not entirely realistic, but it should be able to run at least say
> > 60 times faster.
>
> Amdahl&#x
On Wed, 2002-11-20 at 15:01, Brent Dax wrote:
> We need that capability if we're going to have lexically-scoped exports:
Whilst it would be useful for pragmatic modules to access anything and
everything in the current compilation scope, I submit that access to
dynamic scope should (in general) be
On Mon, 2002-11-18 at 18:10, Dave Whipp wrote:
> Why do we need to use preemptive threads? If Parrot is a VM, then surely
> the threading can be implemented at its level, or even higher.
And what about *lower*? Like down among the CPUs?
I want Perl to run 128 times faster on a 128 CPU machine...
On Fri, 25 Oct 2002, I wrote:
> > why not simply extend pattern-matching in a similar way to substr, making it
> > an L-value, so that one gets
> >
> > $str ~ /[aeiou]+/ = "vowels($&)"
> >
> > or
> >
> > $str ~ /\d/ {hyper-symbol}= (0) x {size-of-LHS-array};
On Thu, 24 Oct 2002, Larry Wall
On Tue, 29 Oct 2002, Larry Wall wrote:
> Maybe we should just say that you can put it anywhere that makes sense,
> and let the perl parser sort out the sheep from the goats. The basic
> rule is that for any op, [op] is also expected in the same place.
It would be nice to have a fully generalized
On Tue, 29 Oct 2002, Larry Wall wrote:
> Logically entangle nouns *are* more basic than grade school. Kids are
> even sophisticated enough to disambiguate "xor" from "or" by context,
> despite the fact that English has no "xor" operator:
>
> Which do you want? A popsicle or a Mickey Mouse ha
On Tue, 29 Oct 2002, Damian Conway wrote:
> Or one could define a copy-the-invoke method call operator (say, C<+.>):
As a rule I prefer to see "safe" operations have short names and
"dangergous" operations with longer ones. In this context that means "copy"
gets the short name and "in place" g
On Thu, 24 Oct 2002, Larry Wall wrote:
> It's possible the syntax for substitution should be wrapped around the syntax
> for matching, whatever that turns out to be.
That strikes me as promising...
Going back to Perl5 for a moment, we have
substr($str,$start,$len) = $newstr
why not simply ext
54 matches
Mail list logo
