Re: can a method name contain a funny character?

[Larry Wall]

On Fri, May 20, 2016 at 09:39:30AM -0400, yary wrote:
: On Tue, Apr 12, 2016 at 6:12 PM, Brandon Allbery 
: wrote:
: > I was explaining why some "symbols" are acceptable to the parser. Which
: one
: > is more appropriate is not my call,
: 
: I was thinking about what exactly are valid identifiers in Perl6/rakudo's
: implementation. The docs 
: say:
: 
: An identifier is a primitive name, and must start with an alphabetic
: character (or an underscore), followed by zero or more word characters
: (alphabetic, underscore or number). You can also embed dashes - or single
: quotes ' in the middle, but not two in a row.

At this point, "number" means only characters with a GeneralCategory
of Nd.  We could talk about generalizing that, but there are potential
issues.  We can't simply extend it to No characters, because then

pi²

would misparse as a 3-character identifier.

: Experimenting with some of the numeric codes from Wikipedia
: , some of the numeric
: codes seem inconsistent-

Note that, even if we used this table, we could not distinguish ² from ② and 
such.

: > my $_६೬ퟨ = ६೬ퟨ # "De" Devanagari, Kannada, Mathematical. "De" is all
: good.
: 666

That's fine, those work because of the Nd general property, so they're 
equivalent
to 0..9 as far as we're concerned.

: > my $x六 = 6 #  "Nu" Han number 6
: 6
: >  say 六
: ===SORRY!=== ...

Note that 六 works in identifiers by virtue of being not numeric at all,
but by being in general category Lo, that is, it's a "letter other",
so considered alphabetic.

: > say ௰  # "Nu" Tamil number 10
: 10
: > my $x௰ = 5
: ===SORRY!=== Error ...

Excluded because it's No, not Nd.

: > say ① + 3 # "Di" 1 in typographic context has value 1
: 4
: > my $b① = 44 "Di" 1 not valid in identifier
: ===SORRY!=== Error ...

① is indistinguishable from superscripts, even by "Di", and falls into
the No general category, so excluded.

: Some numeric codepoints are recognized as such, yet Rakudo isn't allowing
: them in identifiers. Especially confounding is the treatment of the "Han
: number 6" and "Tamil number 10", both of which are unicode "Nu" numeric.
: The Tamil is recognized as a number on its own but not as an identifier;
: the Han is allowed in an identifier but isn't recognized as a number!

We currently rely only on GeneralCategory.  I don't believe we use
NumericType anywhere in parsing Perl 6.

: Is there some deeper rule at work here- which could be added to the
: documentation? Or are these bugs?

Not a bug, but potentially negotiable.  It simply comes down to Nd vs
No at the moment.  One could argue that we could notice superscripts
as a separate category and treat them differently, but there are two
arguments against that.

The first is that we'd like to keep the basic identifier rules fairly
simple.  We're already pushing the state of the art here, and I don't
see much benefit in making the rules more arcane that they are.

The second argument is that we should probably reserve syntax for the
user here.  Once we get slangs fully hooked up, we can easily let users
define identifiers to include ①  and such.  But it's just as likely,
perhaps more likely, that the user will want to use ①  for a postfix,
just like we currently treat superscripts as powers.  We can't guess
(well, we *could* guess, but can't know) which way the user will want to
use these, so the conservative approach is to make neither of them work,
and let the user take an additive approach, rather than forcing them to
use a subtractive approach if we guessed wrong.

Larry

Re: state statements versus state expressions

[Larry Wall]

On Tue, Sep 11, 2012 at 10:25:03PM +0100, Nicholas Clark wrote:
: On Tue, Sep 11, 2012 at 11:11:11PM +0200, Carl Mäsak wrote:
:  Nicholas ():
:   Where in the synopses (or other documents) does it explain why these two
:   are different?
:  
:   $ ./perl6 -e 'sub foo {state @a = (3, 4); say ++@a[0];}; foo; foo;'
:   4
:   5
:   $ ./perl6 -e 'sub foo {(state @a) = (3, 4); say ++@a[0];}; foo; foo;'
:   4
:   4
:  
:  S03:4912. Each declarator can take an initializer following an equals
:  sign (which should not be confused with a normal assignment, because
:  the timing of the initialization depends on the natural lifetime of
:  the container, which in turn depends on which declarator you use).
: 
: Thanks, but if I read that I wouldn't make this jump from it:
: 
:  In other words, the parens turn the special equals sign into normal
:  assignment again.
: 
: (which I'm fine with, as a reason. Although my mental model of it was
: When it's a statement, it's special, with an implied phaser block.
: If it's part of an expression, however trivial, it can't be special)

There is no sense in which a declarator is a statement.  (Not even in
Perl 5.)  A declarator is simply a term.  The difference from Perl 5
is that in Perl 6, declarators are kinda like macros that can look for
more arguments, and the initializer argument happens to be labelled
with an '=' instead of something like :init(42).  The extra parens just
do term isolation in this case.

: So I guess my next question is where is normal assignment explained?
: Specifically, the part that would explain that you can put Cmy or Cour
: or similar within the list on the left of the C=.

Er, why would normal assignment want to explain something that isn't normal?

Anyway, normal assignment is also explained in S03, albeit somewhat diffusely.

Larry

Re: [perl6/specs] d9d8b3: refactor case mappings (again)

[Larry Wall]

On Tue, Jul 24, 2012 at 09:42:10PM +0100, Smylers wrote:
: GitHub writes:
: 
:
https://github.com/perl6/specs/commit/d9d8b35825f7abf07a9314fd90b0b5563253bd15
:Author: Larry Wall la...@wall.org
:  
:  There is no more titlecase function.  Instead there is a suite
:  of mapping functions appropriate to apply on a word-by-word basis
:  (tc, tclc, and tcuc),
: 
: Under what circumstances is tcuc useful? I'm currently suffering from a
: lack of imagination as to when somebody would ever want that rather than
: just uc.

A bare uc will do the wrong thing for the first letter of a word in
those languages that distinguish tc from uc.  Titlecase is distinguished
from other uppercase forms that are used after the inital letter, and
so doesn't care whether the next character is uppercase or lowercase.
It's simply wrongish to use uc on the first character in such a language.

Larry

Re: How to make a new operator.

[Larry Wall]

On Fri, Mar 23, 2012 at 07:14:51PM +1100, Damian Conway wrote:
: For example:
: 
: 1, 1.0001, 1.0002 ... *
: 
: won't deduce a correct arithmetic sequence either (on most hardware).

Actually, that one works fine in both niecza and rakudo, since those are Rats.

Larry

Re: eval and try should be separate

[Larry Wall]

Given that try can be used with a statement as well as a block, I'm
fine with this.  We want to discourage people from using eval anyway, 
so forcing people to use 'try eval' to get p5 behavior is okay too.

Larry

Re: Perl6 regexes and UTS#18

[Larry Wall]

On Sun, Feb 06, 2011 at 08:59:51PM +0100, Helmut Wollmersdorfer wrote:
: Tom Christiansen wrote:
:  Has anybody specifically looked at how Perl6 regexes might map to
:  the various requirements of UTS#18, Unicode Regular Expressions?
: 
:  http://unicode.org/reports/tr18/
: 
: Roughly Perl6 supports Level 2 (I did a fast check of UTS#18 and the specs).

I believe the spec now supports all of Level 2 explicitly, more or less.

:  I ask because to my inexperienced eye, quite a few perl6isms are
:  *much* better at this than in perl5 obtain, and so I wondered
:  whether this was by conscious intent and design.  Is/Was it?
: 
: Seems intended.

Well, some of it is convergent evolution (or divergent, in some cases),
but we have paid a certain amount of attention to what the unicode
folks have to say over the years.

:  I'm also curious whether there are active plans to address the
:  tr18 requirements in perl6 regexes.  It would be a wonderful
:  feather in perl6's cap to be able to legitimately claim Level 2
:  or even Level 3 compliance, since besides perl5, only ICU right
:  now manages even Level 1, with everybody else *very* far behind.

Anyone who implements all of S05 can claim Level 2.

: I would like to have:
: - all Unicode features of Perl5 (UCD, charnames, Normalize, properties)
: - most of the features of ICU (e.g. transforms, localisation)
: - normalization form, local-support and tailored $features on string
:   level (_not_ lexical context)
: 
: This means that any string can be in or can transformed into the form
: - Byte
: - NFD, NFC, NFKD, NFKC
: - NFG (Default Grapheme Clusters)
: - NFGT (Tailored Grapheme Cluster)
: 
: Tailored means, that the Graphem (NFG) needs a Language-Local (e.g.
: German-Swiss-Spelling_1996, or German-Austrian-PhoneBookCollation).
: Without a Language-Local a NFG-string is handled as NFG-string
: (default).
: 
: Tailored also means, that the user (Perl6 programmer) can tailor the
: relevant mechanisms (formatting, normalization, collation,
: properties, case folding etc.).

I think we're mostly on the same page, though I think we'll need
to thrash out how much of this info is carried in the string type,
and how much is implicit to the current language's view of strings
(where the programmer gets to choose which viewpoint to take, such as
graphemes, codepoints, bytes, etc.).  We want to give access to
strings from other viewpoints to the extent that we can, but the current
viewpoint will tend to produce different default results than other
viewpoints.  By default, for instance, Perl 6 is supposed to be warped
toward NFG semantics, and wants to view all strings through that lens
unless otherwise instructed.  The lesser strings will tend to look
more like buffers to such a view.

:  TR18 specifies three levels of support (Basic, Extended, and Tailored),
:  with each having specific, reasonably well-defined requirements:
: 
: There is a lot of work in the UNICODE standard - using it costs
: nothing, but saves time. E.g. the allowed characters for identifiers
: can be defined with the Unicode properties 'ID_Start' and
: 'ID_Continue', Grapheme with Grapheme_Base, Grapheme_Extend etc.
: 
:=Level 1: Basic Unicode Support
: [...]
: RL1.3Subtraction and Intersection
: 
: IMHO not complete

Fixed.  Now have |, , and ^ with expected precedence, and () for bracketing.

: RL1.5Simple Loose Matches
: 
: Hmm ...

Clarified.

: RL1.6Line Boundaries
: 
: can be defined

Now we have an extensible boundary syntax with a different namespace than
normal rules.  |w is a word boundary, etc.

: RL1.7Supplementary Code Points
: 
: IMHO not specced

Yes, already implicit to the NFG view of reality.

:=Level 2: Extended Unicode Support
: RL2.1Canonical Equivalents
: 
: IMHO not specced

To me, this is also implied by NFG semantics.

: RL2.4Default Loose Matches   RL2.5Name Properties
: RL2.6Wildcard Properties
: 
: IMHO not specced

Was already specced as a smartmatch, but I've made the name matching more 
explicit.

:=Level 3: Tailored Unicode Support
: 
: IMHO not specced

We've had :chars conjecturing tailoring for quite a while now.  Of course,
the actual syntax is negotiable.

: It would be easier to reference the appropriate chapters of the
: Unicode standard in the specification of Perl6. This would make
: Unicode test-cases reusable. And an implementation should always
: declare, which features of Unicode are implemented (and which not)
: in which version of Unicode.

We can certainly use a lot more work on the details, but the intent
should be clear that we want Perl 6 to be support world-class Unicode.

Larry

Re: base-4 literals

[Larry Wall]

On Tue, Nov 16, 2010 at 12:11:01PM -0800, Darren Duncan wrote:
: Carl Mäsak wrote:
: Darren ():
: While I haven't seen any prior art on this, I'm thinking that it would be
: nice for a sense of completeness or parity to have an 0a syntax specific to
: base-4 that complements the 4 that we have now for bases 2,8,16,10.
: 
: You're joking, right?
: 
: No, its a serious idea, just not so conventional. -- Darren Duncan

The lack of base 4 numbers in Real Life seems to me to justify the
convention.  Do you have a use case?

Larry

Re: requiring different vers per auth

[Larry Wall]

On Fri, Sep 10, 2010 at 06:00:30PM -0700, Darren Duncan wrote:
: With regard to http://perlcabal.org/syn/S11.html#Versioning ...
: 
: If some Perl code requires a module (or Perl version) that has
: multiple authorities and each authority uses a different
: version-numbering scheme, and the code is compatible with different
: version ranges from each authority, then how does the code express
: this?

Search for emulates in S11.

Larry

Re: Suggested magic for a .. b

[Larry Wall]

On Wed, Jul 21, 2010 at 09:23:11AM -0400, Mark J. Reed wrote:
: Strike the counter to current Rakudo behavior bit; Rakudo is
: behaving as specified in this instance.  I must have been
: hallucinating.

Well, except that we both neglected precedence.   Since ... is looser
than ~~, it must be written 3 ~~ (0...4).  :-)

Larry

Re: Command-line args (weekly contribution to P6)

[Larry Wall]

On Wed, May 26, 2010 at 07:22:36AM -0700, jerry gay wrote:
: On Wed, May 26, 2010 at 00:53, Moritz Lenz mor...@faui2k3.org wrote:
:  The spec doesn't elaborate on how the short args are specified in the
:  signature of MAIN. I see two possible approaches (that don't contradict):
: 
:  1) one renames them in the signature, so it would like
: 
:  sub MAIN(:name(:$n))
: 
:  then $n has two names, 'name' and 'n', and we could consider all one-letter
:  parameter names as short names
: 
: this is what was intended in the spec.  if you can update it to stamp
: out the ambiguity, that would be most welcome.

Yes, that was the intent.

:  2) Iterate over all named parameters and build unambiguous prefixes. If any
:  of them is just one letter short, we consider it a short name.
: 
: 
:  Anz opinions from p6l about it?
: 
: this method has too much magic.

And also too little magic, insofar as it won't guess which options
deserve precedence over another due to frequency of use.  Also, it's
a bit antisocial to get people used to using certain short switches
and then cancel them out when they get ambiguous.  If you're going
to have a mechanism for forcing short ones, then we already have #1
above, and the intermediate names are not terribly useful, because
people will tend to prefer the extremes most of the time.

And if you want a particular program to behave the other way, you
can pull in all the switches with *%args and then do your own key
matching with the *name forms, assuming it's implemented, and
plays nice in alternations, LTMishly speaking.

Larry

Re: eqv and comparing buts

[Larry Wall]

On Wed, May 26, 2010 at 11:09:49PM -0600, David Green wrote:
: On 2010-05-26, at 1:53 am, Moritz Lenz wrote:
:  The tests might need fixing too, since I'm not sure whether eqv (as used 
by is_deeply) would cover that, or whether it would take a separate test in 
bool context.
:  
:  probably the latter.
: 
: I guess it would have to -- that is, but creates an ad-hoc new class,
: so even if you take two identical objects and but them the same way,
: there's probably no good way that eqv can tell they are the same.
: At best, it could know that one or both of its operands had been
: tampered with, and report false.
: 
: (If you wanted to manipulate two or more objects the same way, then
: you'd have to make a new class with the appropriate overloaded methods
: and then eqv could compare my NumButFalse $n1 to my NumButFalse $n2.)
: 
: In order to compare two objects that were created and modified on
: the fly, you could see what roles/methods they actually have, and
: compare the values in whatever way is suitable.  I guess you could
: see whether an object has extra roles with something like:
: 
:   all($x.roles) === all ($x.WHAT.roles)
: 
: Still, it's important to be able to tell whether two things can be
: expected to work the same way, so perhaps there can be an adverb for
: eqv that says to pay attention to ad-hoc changes (or vice versa).
: Since 'but' is special syntax, maybe there's even a way to compare
: snapshots of all the types that were 'but'ed in to the base type,
: but I don't know how feasible that is.

Or going the other direction, perhaps we're missing a primitive that
can produce a data structure with the type information stripped, and
then eqv might be able to determine structural equivalence between
two canonicalized values.

Larry

Re: Parallelism and Concurrency was Re: Ideas for a Object-Belongs-to-Thread threading model

[Larry Wall]

On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote:
: After reading this thread and S17, I have lots of questions and some
: remarks.
: 
: Parallelism and Concurrency could be considered to be two different things.
: 
: The hyperoperators and junctions imply, but do not require,
: parallelism. It is left for the implementors to resolve whether a
: single or multiple processor(s) is/are used. Hence, parallelism
: could be considered to be something under the hood of perl6 and not
: directly specified.

Certainly we've put in a number of abstract constructs that, if used by
the programmer, make promises of parallelizability, even if the the
implementation makes no promises about actual parallelization.

: Given that:
: - concurrency is a topic of ongoing research
: - several models of concurrency have been tried, including two in perl5
: - there are a variety of contexts (internet, clouds, multiple cores, etc)
: - different operating systems provide different resources
: 
: then:
: How much needs to be specified and implemented in perl6 so that
: different concurrency models can be implemented in modules to take
: into account the above diversity?
: 
: The less, or rather the more abstract, the specification in perl6,
: the less likely perl6 will 'age'.

Yes, but...

We need to understand the possibilities sufficiently well to provide a
default implementation that most modules can code to, or we'll simply
end up with a mess of incompatible modules.  This goes doubly for the
standard library; if it is written in a way that violates the
constraints of a thread model, it will not be useable under that model.
(See the Perl 5 ecosystem for what happens if you bolt on threading
after the fact.)

So what we're primarily trying to understand and predict is how the
various threading models will constrain us in our normal coding
patterns, and how we can make those constraints as invisible as
possible without either violating them by accident or inducing
unnecessary overhead.  Requiring the programmer to make a few minor
accomodations to achieve this may buy us a lot of non-grief in
the future.

But as you say, this is not a simple problem to solve; our response
should not be to punt this to future generations, but to solve it
as best as we can, and hope we can make some of the hard decisions
right enough to allow future evolution.

I am very glad to see several passionate but mostly-rational
people thrashing this out here; the future is many-core, and none
of us understand the implications of that well enough yet to write
off the topic as a bikeshed, or to wish for the good old days of
single core.  Sure, it should be possible to write a Perl program in
a single-threaded mindset, but while certain popular languages cling
to the past and try to make single-threadedness a feature, Perl is
more about embracing the future and about freeing the programmer from
arbitrary restrictions.  And as Perl 5 OO demonstrated, sometimes
not picking a good default can be just about as damaging as picking
the wrong one.

Note also that the fundamental difficulty with doing threading in
Perl 5 is not the exact model chosen, but rather that the fundamental
underpinnings of locality were (for various historical reasons)
poorly designed/evolved in the first place, so we ended up with far
too much information having to be managed outside of its proper scope,
for many different definitions of scope.

This has been one of the secret sauces of the Perl 6 redesign, to
hang every piece of information on the peg where it belongs, and not
somewhere else.  And that is why threading of *any* kind will work
much better in Perl 6.

Larry

Re: Ideas for a Object-Belongs-to-Thread threading model

[Larry Wall]

Since I don't think BrowserUK subscribes here, I'll paste in the remarks
he attached to your earlier paste, just to help get the discussion going,
and on the assumption this will not be regarded as antisocial.  :)

Larry

BrowserUK wrote:
 
 -there are the interpreter processes.
 
 Inventing (overloaded) terminology will just create confusion. Very
 unhelpful in a context that suffers more than its fair share already.
 
- The interpreter implements a scheduler, just like POE.
 
 POE does *NOT* implement a scheduler. 
   It implements a state machine--with the controlling state both
 global and shared.
   It provides no concurrency. Not even the illusion of concurrency. 
 
 It does a little of this; and a little of that; and a little of
 something else; but only one thing at a time regardless of how many
 cores are available.
 
 And if one of those little bits of something hangs, the entire edifice
 hangs.
 
  -3 - The scheduler, ulike POE, should be able to schedule in
  several OS threads, such that any OS thread may raise any
  waiting process.
  
 And how are you going to implement that? 
 
 The only way would be for there to be multiple concurrent (kernel
 threaded) instances of the state-machine running sharing (as in shared
 state concurrency) their controlling state.   
 
 This re-creates all the very worst problems of: 505threads, green
 threads; and Windows3 cooperative scheduling.
 
 Besides that it would be a nightmare to implement; it would be an even
 worse nightmare to program,

Re: a more useful srand (was Re: r30369 - docs/Perl6/Spec/S32-setting-library)

[Larry Wall]

On Tue, Apr 13, 2010 at 01:29:59AM -0400, Aaron Sherman wrote:
: PRNGs are often misrepresented as frivolous, but as I'm sure you know from
: your work at JPL, high quality random sequences are much-prized, and any
: language that starts off with some poor assumptions will ultimately pay for
: it.

Actually, my appreciation for good random number generators stems from
my work even before JPL, at System Development Corporation, where
I helped rewrite their discrete event simulator (known as MODLIT).
The guys there did a lot of statistical analysis of the RNG to
make sure it didn't have various subtle artifacts.  In particular,
I worked there with Peter Montgomery, a mathematician with an Erdős
number of 1.  Pity I never published with him.  :)

The fact that early Perl just tended to pass through the system's rand
function had more to do with trying to be a glue language to existing
APIs than it did with trying to provide a good RNG.  (Plus realizing
that anyone in those days who wanted a good RNG tended to write their
own anyway.)  In any case, there weren't many standardized sources of
entropy in those days.  Back then, if I wanted a decently entropic
seed, I'd run a ps that dumped as much of the internal state of the
OS as possible (including various fast-changing internal tables),
and then hash that.  In strength it was probably somewhere between
/dev/random and /dev/urandom.

Larry

Re: a more useful srand (was Re: r30369 - docs/Perl6/Spec/S32-setting-library)

[Larry Wall]

On Mon, Apr 12, 2010 at 07:24:37PM +0200, Moritz Lenz wrote:
: Dave Whipp wrote:
:  masak wrote:
:  Modified:
: docs/Perl6/Spec/S32-setting-library/Numeric.pod
:  Log:
:  [S32/Numeric] removed method form of srand
:  
:  Overwhelming consent on #perl6 about this.
:  
:  - multi method srand ( Real $seed: )
:multi srand ( Real $seed = default_seed_algorithm())
:   
:   Seed the generator Crand uses. C$seed defaults to some combination
:  
:  I think that most serious users of random numbers (that includes me) 
:  would generally agree that it would be foolish to use the builtin RNG in 
:  most languages -- looks like Perl6 would be included in that list. I was 
:  wondering if something could be done to at least make the abstraction 
:  usable.
: 
: I agree, even though I'm only a semi serious user of RNG.

I also agree, having abused random numbers liberally in a past
(technical) life.

:  There are two main issues: the generator algorithm, and the scope of the 
:  generator.
:  
:  The issue of selecting an algorithm with sufficiently good statistical 
:  properties could be addressed simply by allowing a closure/iterator to 
:  be passed to srand to set the actual RNG algorithm, not just the seed. 
:  That should be fairly simple to implement.
:  
:  For my work, the more interesting issue is scope of the RNG. This breaks 
:  down into a couple of issues:

Yes, it's really all about scoping, and the ability to construct (at least in 
the abstract)
trees of random sequences.

:  1. do all implementations of Perl6 generate the same sequence, given the 
:  same initial seed. 
: 
: I don't think they should. If you want that, use confuse a RNG with a
: sequence generator that it is not.

While I agree that the default should be non-reproducable, the
approach taken in Perl 5 is nice to the extent that if you *do*
seed the built-in RNG with a consistent value, you get a reproducable
result.  And reproducable trees of random sequences can be generated
by controlling the seeds of each node in the tree.

To be sure, Perl 5 doesn't try very hard to help you with scoping
issues beyond that.

:  If the initial seed were a closure then of course 
:  this question becomes irrelevant. So I'd be tempted to allow closures, 
:  and then leave the default RNG as implementation-defined.
:  
:  2. seed stability across multiple generators:
:  
:  2a. If I spawn two threads (implicitly or explicitly), how do their RNGs 
:  interact? I.e. are Crand and Cpick thread-safe?
:  
:  2.b If I create multiple classes/objects, each of which generates a 
:  stream of random traffic (a common need generating random tests), can I 
:  change the implementation of one of those classes without affecting the 
:  traffic generated by the others. The standard way to deal with this is 
:  to have a distinct random generator per-object. To have that as the 
:  default behavior of Perl6 would probably be too expensive. That said, it 
:  would be nice if there were a way to define the scope/multiplicity of 
:  the internal RNG so that functions like Cpick could be used within 
:  such a traffic generator scenario.
:  
:  I think that all that is needed is to permit some sort of 
:  declaration/pragma that creates a dynamic scope for an srand: e.g. temp 
:  srand { ... };
: 
: I'd say
: 
: 1) A RNG class (don't really care what the name is, for now)
: 2) An instance of that in $*RAND (which you can temp())
: 3) rand() and srand() act on $*RAND
: 4) It should be easy to create instances of the RNG to use in your own
: class.
: 
: Would that make sense to you?

Certainly the standard approach will involve some such dynamic
variable, or possibly a dynamic *RAND function.  And the intent is
that readonly dynamic variables be optimizable by copy-in much like
environment variables are copied into processes.  So performance is
not much of an issue here, if we set up the dynamic context suitably.

This does make me wonder if there should be some support for
auto-temping some or all dynamic variables on thread creation
boundaries...hmm...  But what if you *want* to use one sequence across
multiple threads...hmm...

Of course, any give lexical scope can also set up its own lexically
scoped random functions that will override anything in the language,
if you want to do stuff cross-thread.  Or just set up a generator
outside your threads that is shared via an outer lexical.

We've got enough rope to hang ourselves differently every day of
the week, with some left over for next week.

Larry

Re: underscores vs hyphens (was Re: A new era for Temporal)

[Larry Wall]

On Sun, Apr 11, 2010 at 03:47:18PM -0700, Darren Duncan wrote:
: Damian Conway wrote:
: The relevant suggestion regarding hyphens vs underscores is:
: 
: ...to allow both characters, but have them mean the same thing.
: 
: That is, any isolated internal underscore can be replaced with an
: isolated internal hyphen (and vice versa), without changing the meaning
: of the identifier.
: 
: I am formally opposed to this idea.  I see that making underscores
: and hyphens to be equivalent is akin to having case-insensitive
: identifiers, where Perl,PERL,perl mean the same thing.  Rather
: what I want is to be everything-sensitive, as AFAIK Perl 6 currently
: is; if something looks different, it is different. -- Darren Duncan

Well, Perl 6 won't be everything-sensitive, since by default it does
string comparisons under some kind of Unicodian Normalization.

But I'm inclined to keep - and _ as unique characters, and just let
the culture evolve over time; I think the end result will be to require
(by convention) official APIs to use hyphens for all normal interfaces;
underscores anywhere in a name will come to mean this is private,
use at your own risk regardless of where underscores are used,
much like current meaning of leading underscores.  But I don't think it
should be anything tighter than a convention, or we make language
interoperability more difficult (particularly with Perl 5).

As for the horror of people having to memorize lists again or
Risk Using The Wrong Character...I'm afraid I just don't buy it.
The standard parser will likely be pointing out spelling errors and
conjecturing emendations for near misses.  Whole-program analysis can
even do this for any method names that look wrongish.  The difference
between Acme-X and Acme_X is no worse than the difference between
Damian and Damien, at least in Levenshtein distance.

Larry

Re: A common and useful thing that doesn't appear to be easy in Perl 6

[Larry Wall]

On Wed, Apr 07, 2010 at 06:33:46AM -0700, Jon Lang wrote:
: That said, don't we already have a means of assigning specific values
: to individual members of an enum?  I forget the exact syntax, but I
: believe that it involves an assignment operator within the
: enumeration.  Mind you, this is from memory:
: 
: enum Perms { Read = 1, Write = 2, Exec = 4, Fold = 8, Spindle =
: 16, Mutilate = 32 }
: 
: ...or something to that effect.  Clumsy, sure; but it seems to me that
: this is exactly the sort of thing that hyper-operators were designed
: to handle:
: 
: enum Perms { Read, Write, Exec, Fold, Spindle, Mutilate } »=« (1,
: 2, 4 ... 32)
: enum Perms { Read, Write, Exec, Fold, Spindle, Mutilate } »=» (1,
: 2, 4 ... *)
: 
: ...or something along those lines.  I'll check the exact syntax later,
: when I have more time; but I wonder if something to this effect is
: already possible with the language spec as written.

You're right, though you're reaching for the wrong meta-operator, since
hypers have parallel and run-to-completion semantics, and therefore
don't like infinite lists.  Instead, you want a nice, ordered, lazy,
zipwith.  In the currently specced syntax, that would be:

enum Perms (Read Write Exec Fold Spindle Mutilate Z= 1,2,4...*);

That just creates a list of pairs, and stops at the end of the
shorter list.  Which is exactly what we want.  The parens are
necessary because the enum declaration currently takes a single
list term which is tighter than comma, syntactically speaking.

We could make enum declarators even more like constant declarators
by using a pseudo assignment.  Then we could use = instead of parens:

enum Perms = Read Write Exec Fold Spindle Mutilate Z= 1,2,4...*;

This works because list infix is tighter than list assignment.
I've been thinking of switching enums to this form for some time,
and this may tip me over the edge.  (Presuming of course that I wasn't
tipped over the edge many years ago...)

Larry

Re: A common and useful thing that doesn't appear to be easy in Perl 6

[Larry Wall]

On Tue, Apr 06, 2010 at 08:31:24PM -0700, Damian Conway wrote:
: An issue came up in a class I was teaching today...
: 
: There doesn't seem to be an easy way to create a type that allows a set
: of enumerated bit-flags *and* all the combinations of those flags...and
: nothing else.
: 
: For example:
: 
:  enum Permissions ( Read = 0b0001, Write = 0b0010, Exec = 0b0100 );
: 
:  my Permissions $rwx = Read +| Write;# Error

I think we're getting hung up on powers-of-two here, and the low-level
implementation details of stuffing bits into numbers.  Instead, I think
we should take a hint from that ancient tongue, Pascal, and simply
make sets of small integers do the right thing with respect to bitmaps.
Then normal enum semantics can provide those small integers, and all
the powers-of-two business is implicit in the construction of the set:

   enum Permissions Read Write Exec;
   subset Perms of Set of Permissions;
   my $rwx = Perms(Read,Write);

   say $rwx.perl;  # Perms(Read,Write) or some scuh
   say ~$rwx   # Read Write
   say $rwx.elems; # 2
   say +$rwx;  # 3

That is, the numeric value would be suitable for ORin into any numeric
set of permissions.  Sets based on types that are not amenable to
representation as bitmaps would, of course, not produce a meaningful
numeric value.

Alternately, + could return the same as .elems, and a different method
could be used to get the bitmap, but then it becomes harder to write
expressions using the bitmaps.  Perhaps that's a feature.

Also, while presumably Int can hold a bitset of any size, we might also
want to play with bitsets represented as strings.  We could overload
stringification for that, but that would likely be a mistake.  The
string forms of such sets should probably remain human readable.

: I know I could use junctions:
: 
: subset BitFlag where Read|Write|Exec;
: 
: my BitFlag $rwx = Read | Write;
: 
: but it's not easy to recover the actual bitpattern from that, except with:
: 
: $bitpattern = [+|] $rwx.eigenstates;
: 
: which is suboptimal in readability (not to mention that it requires
: MONKEY_TYPING to allow access to the .eigenstates method).

To the extent that Junctions can be mapped to Sets, it's actually
only all junctions that correspond precisely to strict definition
of a set.  That is, a set is defined as all of its members.  It is
very much *not* a container for some subset of its members.  Hence,
it might be permissible to convert an all junction to a set without
invoking any monkey business.

Set(Read | Write)   # bogus, R|W is really 3 sets, R, W, and RW!
Set(Read  Write)   # okay, can only represent RW

(assuming here that the Set coercion can be passed a junction without
autothreading).

: Ideally, what I'd like to be able to do is something like:
: 
: enum Permissions is bitset  Read Write Exec ;
: 
: # The 'is bitset' starts numbering at 0b0001 (instead of the usual zero)
: # and doubles each subsequent enumeration value (instead of the usual ++).
: # It also implicitly fills in the various other bitwise-or permutations
: # as valid-but-nameless enumerated values
: 
: my Permissions $rwx = Read +| Write;# Now fine

If you really want to use +| and friends for their innate *cough*
beauty, you can still do so--presuming these bitmapping sets numerify
to the correct bitmap.  However, I suspect some people might prefer
(or come to prefer) using set operators, particularly as these get used
for collections that people think of more as sets.  In this sense,
starting out with a use case based on low-level file status bits is
perhaps not most indicative of the best way forward.

: The closest I can think of at the moment is something like:
: 
: enum NamedPermissions ( Read = 0b0001, Write = 0b0010, Exec = 0b0100 );
: 
: subset Permissions of Int where 0 .. [+|]NamedPermissions.enums.values;
: 
: my Permissions $rwx = Read +| Write;# Fine
: 
: which is still a little too constructive, too explicit (you have to get the
: bit values right), as well as being too obscure for such a common task.
: 
: 
: Of course, I could always create a macro to encapsulate the explicit
: constructive obscurity:
: 
: macro bitset ($typename, @value_names)
: is parsed(/:s (ident) '' ( ident )+ '' /)
: {
: # [build code to implement the above trick here]
: }
: 
: # and later...
: 
: bitset Permissions  Read Write Exec ;
: 
: but this is such a common requirement in engineering applications that it
: would be great if this wheel didn't constantly have to be reinvented.
: 
: 
: If anyone can think of a cleaner way to do it within the current semantics,
: I'd be very happy to hear of it. I'm jetlagged and bleary from a full day of
: teaching and I may well be missing an obvious answer.

I think Sets could do this cleanly in the current design, given a little
shove in the Pascal direction, but we could still perhaps do with a bit
more syntactic 

Re: A common and useful thing that doesn't appear to be easy in Perl 6

[Larry Wall]

On Tue, Apr 06, 2010 at 10:19:15PM -0700, Damian Conway wrote:
: Larry concluded:
: 
:  I do freely admit that most Perlfolk are not used to thinking of
:  permissions in terms of set theory.  But as I said, we're looking at
:  kind of a strange use case here, and perhaps not typical of the kinds
:  of sets of small numbers that people will be using in the future.
: 
: The reason I raised the issue is because I believe it *is* a very
: typical use-case...in certain hardware-oriented domains.
: 
: 
:  I kinda hope we can get a bit further away from the machine code
:  level of reality one of these decades.  Perl 6 should not be
:  optimized for C semantics.
: 
: Agreed. But it should at least support those who need to work at
: the machine code level, but would prefer not to have to do so in C.
: 
: That said, I'd be perfectly happy to encourage the use of proper set
: abstractions for this purpose, so long as the long-suffering hardware
: engineers can still easily convert the final set to an appropriate
: bit-pattern when it's time to pump the results out to the hardware.

Another possibility would be to go ahead and have the numbers be
powers of two, but have the sets smart enough about *those* rather
than the small integers.  Then we'd need some kind of sugar like

enum Perms of (1,2,4...*) Read Write Exec;

or with a more constant-declaring-like syntax:

enum Perms Read Write Exec = 1,2,4...*;

Alternatively, maybe there should be some way to express infinite sets.
Not sure I like the idea of an infinite junction, but something resembling:

subset PowersOf2 of Int where any(1,2,4...*)
enum Perms of PowersOf2 Read Write Exec;
say Exec;  # 4

Presumably the series in the junction would have to be sufficiently
monotonic so we can know when we've looked far enough.  Or we just
allow something like one of:

subset PowersOf2 is Set(1,2,4...*);
constant PowersOf2 = Set(1,2,4...*);

In any case, the idea is that an enum of something like PowersOf2 would
be smart enough not to use values that aren't in the 'of' type.  We've
got these silly series operators; it seems a shame not to use them
for powers of two when appropriate.

Larry

Re: r29931 - docs/Perl6/Spec

[Larry Wall]

On Sat, Mar 13, 2010 at 08:53:02PM -0800, Darren Duncan wrote:
: Basically, I found this line in Synopsis 2, in the section talking about 
unspace:
: 
: 1+3\  i;
: 
: So the question is about whether this example should be kept as
: still valid code or whether it is now invalid and a fossil?
: 
: I suspect it *is* still valid, at least if this by itself:
: 
: 3i
: 
: ... is a valid literal denoting 0+3i, but wanted to check.

Yes, both of those are still valid.  Thanks.

In fact, the \ is required if you want to use a variable:

$foo + $bar\i

Well, I suppose you could also write that as:

$foo + ($bar)i

but that could be construed as clunkier.  Or at least more typing.

Larry

Re: Functional-style pattern matching

[Larry Wall]

On Mon, Mar 08, 2010 at 12:45:44PM -0800, Little Walker wrote:
: Hi there,
: 
: I've been looking around to see if there's been any discussion of
: introducing functional programming-style pattern matching for method/
: function dispatch.  Could someone point me to any such discussions?

Why settle for discussion when you can have specs?  See the
Parameters and Arguments section of:

http://perlcabal.org/syn/S06.html

: I've seen that perl6 is taking on a lot of ideas from the functional
: world (lazy evaluation for instance).  With multi-method dispatch on
: the agenda pattern matching seems inevitable but I haven't been able
: to find information about this or any related discussions.
: 
: This is a contrived example of what I'm referring to:
: 
: sub traverse([Leaf $a]) {
:   # do something
: }
: 
: sub traverse([Tree $left, Tree $right]) {
:   traverse($left);
:   traverse($right);
: }
: 
: my $t = Tree(...);
: traverse($t);

That's almost exactly the example from:

http://perlcabal.org/syn/S06.html#Unpacking_tree_node_parameters

In fact, a grep of the specs for any of 'Tree', 'traverse', or
even 'left.*right' would have found it.

If any of you wants a greppable version of the specs, use svn to checkout

http://svn.pugscode.org/pugs

and then look in docs/Perl6/Spec.

Larry

Re: r29976 - docs/Perl6/Spec

[Larry Wall]

On Wed, Mar 10, 2010 at 10:10:29AM +1100, Timothy S. Nelson wrote:
: On Mon, 8 Mar 2010, Carl Mäsak wrote:
: 
: Meanwhile, the uncanny similarities between Perl 6 and Algol 68
: continue to strike me:
: 
: http://en.wikipedia.org/wiki/ALGOL_68 (]):
: ] ALGOL 68 [...] was conceived as a successor to the ALGOL 60 programming
: ] language, designed with the goal of a much wider scope of application and 
more
: ] rigorously defined syntax and semantics.
: 
:   Algol 68 is notorious as a failure.  Let's hope things are
: different here.

Algol 68 would have done much better had it been Open Source software
written in some other ubiquitous language.  But back then people
thought you could sell computer languages, or at least proprietary
compilers for computer languages.  And there was no language
sufficiently ubiquitous and sufficiently low cost to write a portable
language in until C came along later.  (You'll note that I did not,
in fact, call C a portable language. :)

Alternately, they probably would have bootstrapped Algol into its
own ubiquitous language had the Open Source movement existed back then.
History would have been much different.

Incidentally, I programmed in Algol W on a Burroughs machine once,
long, long ago in a galaxy far away...

Larry

Re: continuation markers for long literals (was Re: r29931 - docs/Perl6/Spec)

[Larry Wall]

On Wed, Mar 03, 2010 at 05:39:58PM -0800, Darren Duncan wrote:
: Damian Conway wrote:
: Surely this is not a common-enough requirement to warrant a special
: syntax.
: 
: At 80-columns, you can represent integers up to
: snip
: Surely that's enough for the vast majority of users, isn't it?
: 
: Well, 80 columns was an example, albeit the most common, but the
: principle idea was to support writing code that fit into very narrow
: spaces (such as may result from having the 80-col constraint plus a
: whole bunch of code indent levels) while being able to keep the code
: easily readable and nicely formatted.

Dealing with antediluvian displays sounds like a good spot for that
ancient technology, the preprocessor,

: I also figured that this would be a fairly simple thing to do.

Well, it will be simple, once we have macros; in fact, textual macros
can be regarded simply as scoped preprocessors, with all the rights,
privileges, and responsibilities pertaining thereto.  I think macros
will provide enough language support for this sort of hard things
should be possible escape hatch.  And remember you can always override
the grammar if you have special reasons for doing so.  That's what
Perl 6 is all about.  It's not about foreseeing every possible twinge
of misgiving that anyone may come to feel in the next 100 years...

Sure, we're trying to create a gigantic sweet spot in Perl 6, but
Willy Wonka knows you can't have the whole world, and if you could,
you can't have it now.  :)

Larry

Re: Temporal seems a bit wibbly-wobbly

[Larry Wall]

On Sat, Feb 20, 2010 at 06:20:22PM -0800, Steve Allen wrote:
: On Feb 19, 10:30 pm, la...@wall.org (Larry Wall) wrote:
:  2000 would have been a lovely epoch if only the astronomers had kept
:  their grubby hands off of civil time.
: 
: The astronomers might love to have the power to control something like
: that, but I'm afraid that none who are alive now can take credit for
: the international political situation.  The root of the problem is
: demonstrated here
: http://www.ucolick.org/~sla/leapsecs/epochtime.html
: Until the governments of the world agree on a major change in the
: status quo there will be leap seconds.

I apologize to all the living astronomers for maligning them.  :)

I now see that the most important determinant of DateTimes is
neither the Dates nor the Times themselves, but which TZ you're in.
I propose renaming Temporal to TZ, so we get TZ::Date, TZ::Time, etc,
since they're all dependent primarily on exactly where on earth you
are, which determines how civil (or incivil) your cultural time is.
It will also tend to prevent people from assuming anything universal
about such types.

Larry

Re: Temporal seems a bit wibbly-wobbly

[Larry Wall]

On Sat, Feb 20, 2010 at 10:39:20AM -0500, Mark J. Reed wrote:
: I just want to know what Perl 6 time zero is.

Well, there's no such thing as time 0 in Perl 6, in the sense that
Instant is more-or-less opaque.  But it's currently specced to the
TAI epoch, if you force it.  I could be argued into 2000, if people
can actually agree on how far that is from the TAI epoch.  But the
internals of Instant are likely to be something like the current
year plus an offset from that in any case, so it doesn't really much
matter from the standpoint of efficiency which epoch we pick.  That
says to me that if it's numerically the TAI epoch, it doesn't really
matter much that it's a very large number, and using such a large
number will tend to discourage people from using it as a number.  :)

That being said, we could easily have a user-visible constant array
with values like %Epoch[2000] and such, and then you can just pick
your epoch (if it's on a GMT year boundary).  So the first thing a
program might do is:

my Instant $unix-epoch = %Epoch[1970];

Or maybe it should be a method on Instant:

my Instant $unix-epoch .= epoch(1970);

Course, that still doesn't solve the problem that POSIX file mod times
are ignorant of leap seconds, so subtracting $unix-epoch from it will
still have the UTC vs TAI mismatch.  I can forgive dead astronomers,
but parts of POSIX just oughta die.  Some days it seems like standards
committees are even worse than governments for standing in the way
of progress...

Larry

Re: Temporal seems a bit wibbly-wobbly

[Larry Wall]

2000 would have been a lovely epoch if only the astronomers had kept
their grubby hands off of civil time.  But no, we still have to put up
with leap seconds in civil time, for no good reason that I can discern.
We should adjust civil time once a century or so, I think.  After all,
civil time is off by *minutes* anywhere but the center of your timezone
stripe.  Why should a few seconds drift off of midnight matter to anyone
but an astronomer?  But no, many millions of computers have to accommodate
to the convenience of a very few people.  And most computers still don't
know how to do even that accommodation, since POSIX time is blissfully
unaware of leap seconds...

Sorry, you pushed one of my hot buttons.  Grrr!  :)

Larry

Re: [perl #72914] [BUG] Rakudo doesn't treat ^$n at the end of an infix:... right

[Larry Wall]

On Thu, Feb 18, 2010 at 12:45:23PM -0500, Mark J. Reed wrote:
: On Wed, Feb 17, 2010 at 7:32 PM, Carl Mäsak
: perl6-bugs-follo...@perl.org wrote:
:   my @a = (4...^5); say @a.perl # should be 4 3 2 1 0 1 2 3 4, according to 
TimToady
: 
: 
: That's 4 ... ^5, right?  If so, I don't see how you get that.  I'd
: expect (4,0,1,2,3,4), without the countdown between 4 and 0.

Unlike the .. operator, the ... operator does autoreversing.  Also, it's
a list infix operator, which means it takes a list on either side.
Since ^5 can produce a list, what ... sees is, in the abstract:

4 ... 0, 1, 2, 3, 4

In reality, the right list is lazy, so ... has to .get the first value
from the iterator on the RHS and examine what it gets back.  If that
is a limit value, it tells ... how far and in what direction to keep
going with the left side.  So effectively the ... above really only
needs to know

4 ... 0

before it decides how to proceed.

Sometimes the ... has to pull two values off the RHS.  If the first
value is a * or a closure, then the first argument says how to derive
new values on the left, and the 2nd value on the right gives the limit.
To be clearer, or at least different, the programmer could write:

4, 3 ... *, ^5

This question arises, of course, because ... doesn't currently support a ...^
notation as ..^ provides for ranges, so 0...^5 doesn't do what you might
expect.  We might well fix that, or at least detect it and warn.  But it
does seem a bit odd to have to put your own epsilon:

0 ... *, 5-훜

so maybe

0 ...^ *, 5

could be forced to mean that.  Might be an argument for moving the
increment to the other side:

0, *+1 ...^ 5

We'd have to think about the ramifications of that though, which are not
all pretty.  In particular, we still need the * on the right for

1,2,4 ... *

since a missing term:

1,2,4,* ...

would be bad to parse, since we wouldn't know whether to expect a term
or an infix.  Maybe, though, that's confusing two different uses of *,
since this makes perfect sense:

1,2,4,* ... *

and admits things like

1,1,[+] ... *  # fib

And if we see

1,2,4 ... *

we can assume it means

1,2,4,* ... *

Likewise

1,2,4 ... 256

would really mean

1,2,4,* ... 256

Maybe I like it.

Larry

Re: Spec: Syntax Suggestion

[Larry Wall]

On Sat, Feb 13, 2010 at 11:59:10AM -0800, Mubed wrote:
: Sorry, if it is the wrong group to post this. I'd like to know, if it
: is possible to make some suggestions to the Perl6 syntax.

This is certainly the right place, and we try to give all ideas a
fair hearing.  Though given that we've been doing this for almost ten
years now, you need to be aware that almost anything you might suggest
has a good chance of having been discussed several times before.  :-)

Larry

Re: One-pass parsing and forward type references

[Larry Wall]

On Mon, Feb 01, 2010 at 06:12:16PM -0800, Jon Lang wrote:
: Larry Wall wrote:
:  But also note that there are several other ways to predeclare
:  types implicitly.  The 'use', 'require', and 'need' declarations
:  all introduce a module name that is assumed to be a type name.
: 
: Just to clarify: it's possible to define a module within a file,
: rather than as a file; and in fact the usual means of defining classes
: and roles is an example of this, since they are specialized kinds of
: modules.  Correct?  So if I' understanding this correctly, you should
: be able to say something like:
: 
: use Foo;
: class Bar { ... has Foo $x ... }
: class Foo { ... }
: 
: ...where the dots are stand-ins for irrelevant code.  In effect, use
: tells the compiler that Foo is a noun, so that the parser knows the
: proper way to handle it.  It also looks for the definition of Foo; but
: will it start screaming bloody murder if it can't find the definition
: right away?  Have I failed to correctly tell it where to look for the
: definition?  (i.e., do I need to say something like use ::Foo to let
: the parser know that the definition is in this file?)

You should use 'class Foo {...}' for a forward declaration of a class
in the same file, not a vacuous 'use' that implies strongly but wrongly
that the definitions are in another file.  To look at it another way,
'use' is a real predeclaration, not a pre-non-declaration such as we
mean when we talk about forward declarations.

In other words, the above should really be giving you an illegal
redeclaration of class Foo, if Foo.pm did as advertised and created
a Foo type.  You'd have to use 'augment' to do monkey typing like that.

There has been some speculation that we could allow proto and multi
classes when the intent is to scatter the definition around.  But that
hasn't yet been determined to be a Good Thing.  The compiler would like
to know that it can compose a class when it sees the trailing curly,
in case someone wants to use it in a subsequent BEGIN.  Allowing multi
classes would necessarily subvert that at least till CHECK time, if
not till first use.  You'd generally like to catch method name conflicts
no later than CHECK time.

Larry

Re: One-pass parsing and forward type references

[Larry Wall]

Please don't assume that rakudo's idiosyncracies and design fossils
are canonical.  STD does better namespace management in some respects,
particularly in accepting the approved predeclaration form:

class Foo {...}

(and rakudo might now accept this too).

You don't want to use augment for this, because augment is only for
*cheating*, and will eventually require a 'use MONKEY_TYPING;' before it.

You are correct that the one-pass parsing is non-negotiable; this is
how humans think, even when dealing with unknown names.  However, human
language has ways of telling the listener whether a new word is a noun
or a verb, and we generally choose not to require articles or verb
markers in Perl 6, so class names (nouns) are officially ambiguous
with function names (verbs).  We could, as has been suggested before,
have an optional noun marker for undeclared classes, but this tends
to insidiously creep into lots of places, when a single predeclaration
would be clearer and more efficient.

The other reason we'll stick with one-pass parsing is that you can
only do multiple pass parsing if you know exactly which language
you're parsing all the time.  This works against extensibility.
Multiple passes introduce linguistic race conditions any time you're
not sure what language you're in; see source filters for a good bad
example of why you don't want to do multi-pass parsing.

Because type names are nouns in Perl 6, we want to parse them like
other nouns, such as variables and constants, not like verbs.
Know whether something is a noun or a verb is very important in
maintaining the two-terms-in-a-row prohibition, which is the
primary way in which Perl 6 expressions are self-clocking.  Break
that clock and your error messages will turn to mush.  Some of
the smartest error messages that STD emits are actually the
two-terms message transmogrified into something more specific
by context.

Therefore, a word that is declared as a sigilless noun must change
the parsing from there on down so that we know to expect an infix
after it, not a term, which a verb functioning as a listop would
expect.

constant Int pi = 3;
pi 'foo';   # syntax error

(Notice how the fact that Int is predeclared also allows us to
correctly parse the constant declaration, since allows us to
distinguish the existing type from the name to be declared.)

Now that we have basic philosophy out of the way, on to other
arguments.  You might take the predeclaration policy as subtle
encouragement to use the late binding provided by method calls,
which don't require predeclaration.  But Perl 6 is not religiosly
OO to the exclusion of FP, so that's a weak argument, and we're not
trying to discourage people from doing cross-module function calls.

You make an analogy between type recursion and functional recursion,
which is true up to a point, but types and other unsigilled names
tend to be rarer than function names, so it makes sense, if we see
an unknown name, to assume (if we choose to assume) that it is a
postdeclared verb rather than a postdeclared noun.  We don't want to
break function recursion in order to support type recursion.  We can't
guess it both ways since we wouldn't know what to expect next.  Perl 5
did lookahead and tried to guess in some cases, but this generally
turned out to be a mistake.  It was difficult to document and only
inspired mistrust in the parser.  Plus it degrades the two-term rule.

But also note that there are several other ways to predeclare
types implicitly.  The 'use', 'require', and 'need' declarations
all introduce a module name that is assumed to be a type name.

We can also deduce that any use of Foo::Bar::baz to mean
there exists a Foo::Bar type.  STD does this already, though
perhaps only as a lexically scope name at the moment.  We might
assume it to (at least potentially) be global.

A 'use' also predeclares any types in its own space and makes the
public ones available as predeclaration.  From the standpoint of a
typical midsized application that are spread across multiple files,
most of the predeclarations should arrive like this, and not require
a yadayada predeclaration.  And in Perl 6 you shouldn't generally
be using types without a 'use' of the definitions of those types,
or you might not import some desirable multi into your lexical scope.

Of course, we have to deal with 'use' cycles.  Perl 5 simply assumes
that it doesn't need to load a module that it knows is already being
loaded, even if that loading is not complete or would result in
something not being defined that ought to be.  We could take the same
agnostic approach and require the user to break use cycles explicitly
with yada.

Or we could detect that exact situation and relax the rules slightly
to do a bit of dwimmery on type names that *start* with the
partially compiled module.  In that case, it might be reasonable,
if we've got a suspended 'use Foo', to assume:

Foo::Bar::baz   # likely a function
Foo::Bar::Baz   # likely 

Re: One-pass parsing and forward type references

[Larry Wall]

On Mon, Feb 01, 2010 at 10:10:11AM -0800, yary wrote:
: A slight digression on a point of fact-
: 
: On Mon, Feb 1, 2010 at 9:32 AM, Larry Wall la...@wall.org wrote:
: ...
:  You are correct that the one-pass parsing is non-negotiable; this is
:  how humans think, even when dealing with unknown names.
: 
: It's common for people to read a passage twice when encountering
: something unfamiliar. That's on the large level. And even on the small
: level of reading for the first time, people don't read completely
: linearly, skilled readers make regressions back to material already
: read about 15 percent of the time. -
: http://en.wikipedia.org/wiki/Eye_movement_in_language_reading (and I
: read about that elsewhere years ago, wikipedia happens to be the most
: convenient reference.)
: 
: I'm not arguing against 1-pass parsing for Perl6, just reminding that
: humans are complicated. And Larry's quote is how humans think
: whereas the research on eye jumps is about how humans read which are
: not exactly the same...

True enough; I was thinking primarily about the parsing of spoken
speech, where one generally doesn't have the option to replay beyond
what you can remember.  And Perl 6 is arguably more textual than aural.

Larry

Re: One-pass parsing and forward type references

[Larry Wall]

On Mon, Feb 01, 2010 at 03:55:15PM -0500, Solomon Foster wrote:
: On Mon, Feb 1, 2010 at 3:46 PM, Patrick R. Michaud pmich...@pobox.com wrote:
:  On Mon, Feb 01, 2010 at 05:55:47PM +0100, Carl Mäsak wrote:
:  Is it allowed to do 'class B { ... }' several times in different files
:  before finally declaring the real B? If so, then I'd consider it
:  equivalent to my proposed keyword, and thus there'd be no need for the
:  latter.
: 
:  Yes.  And declaring the real B doesn't have to be final, nor
:  does it have to occur at all (as long as none of the features needed
:  from B are ever needed).
: 
: And just to finish it off... are you allowed to do 'class B { ... }'
: even after declaring the real B?

STD does not currently allow it because you have to install the name
immediately in case of references in the traits, even before the block.
The block is too late to say whoops, didn't mean it really.  Pretty
much the same reason we changed is also to augment.  We want to
look up the name right now and know whether it should exist without
doing lookahead.

Larry

Re: One-pass parsing and forward type references

[Larry Wall]

On Tue, Feb 02, 2010 at 12:23:50AM +0100, Carl Mäsak wrote:
: Another thing I started thinking about: if Perl 6 professes to be able
: to put on the hat -- syntactically and semantically -- of most any
: other programming language out there, through the use of a simple 'use
: Language::Java' or 'use Language::Ruby' -- how will Perl 6 compensate
: for the fact that its parser is one-pass whereas most other languages
: do two passes or more? Specifically, will some programs in those other
: languages fail to compile under a Perl 6 language module due to the
: fact that a type keyword was referred to before it was declared? If
: multiple passes introduce linguistic race conditions, what about
: outright linguistic infelicities due to the Perl 6 limitation of
: one-pass parsing?

The one-pass ideal is only for standard Perl 6 and other languages
that make that commitment.  Once you switch to another language, you
should use whatever kind of recognizer you need for that language.
Since Perl is Turing complete, it can (in theory) emulate any atomaton
in the right column in the table at the end of:

http://en.wikipedia.org/wiki/Unrestricted_grammar

In short, it's simple only from the standpoint of the *user* of the
module.  Module creators, on the other hand, should be acquainted
with the concept of vicarious suffering before they begin.

Larry

Re: Counting characters

[Larry Wall]

On Wed, Jan 27, 2010 at 01:24:48PM +, Matthew Walton wrote:
: On Wed, Jan 27, 2010 at 1:19 PM, Carl Mäsak cma...@gmail.com wrote:
:  Mark (), Carl ():
:  S05 describes tr/// in terms of the .trans function, a handsome but
:  very different beast. Specifically, it doesn't seem to have a scalar
:  context, with which one could count things.
: 
:  What does trans return in numeric (+) context?
: 
:  As spec'd, it returns the numification of the string resulting from
:  the substitution, I guess.
: 
:  // Carl
: 
: 
: $str.comb(/C|G/).join('').chars might do it. It's maybe not quite as 
elegant...

Hmm, what might be more elegant?  Maybe something like...

[+] $str.comb.BagC G;

Probably does too much work building the Bag though, unless it can be
lazy somehow.  But the point is that Bags are really just histograms
with a cute name.

Larry

Re: Custom errors on subsets?

[Larry Wall]

On Tue, Jan 05, 2010 at 11:52:42AM -0500, Solomon Foster wrote:
: On Tue, Jan 5, 2010 at 11:36 AM, Ovid
: publiustemp-perl6langua...@yahoo.com wrote:
:  --- On Tue, 5/1/10, Solomon Foster colo...@gmail.com wrote:
: 
:  From: Solomon Foster colo...@gmail.com
: 
:   Is this a bug or just documented behavior that I don't
:  know about?
: 
:  fail just returns an uncalled exception.  What does
:  that do in a where block?
: 
:  I knew it returned an uncalled exception, but I'm still not expecting the 
sub call to be skipped silently due to a constraint failure.  Silent failures 
are bad :)
: 
: Good point.  :)

I think it's fine to return a failure, but we'll need to distinguish two
different kinds of constraint checks, mandatory vs discretionary.  In

my Constraint $x = 42;

the Constraint is mandatory, and should die if the constraint check
returns a failure.  In the typical multi-dispatch, however, you
just want a failure to mean look elsewhere.  (You can still
force a die there if you really want it.)

To the first approximation, a mandatory check requires a defined
where return value, while a discretionary check only requires a
true value.

(Note that a constraint on the parameter of an only sub is already
mandatory, not discretionary, at least in the sense that the call
will fail if the binding is unsuccessful.  So that probably falls
out naturally, though perhaps loses track of the failure message
currently.)

Larry

Re: r29326 - docs/Perl6/Spec/S32-setting-library

[Larry Wall]

On Fri, Dec 11, 2009 at 12:44:21PM -0800, yary wrote:
: What's the reasoning behind not using older perl convention of print
: w/no args becoming print $_ ?

In Perl 6 we're trying to get rid of all the arbitrary lists that you
have to memorize to use Perl 5, such as which symbols are magically
global everywhere, or which blocks require semicolons at the end.
One of those arbitrary lists is which functions do/don't default to $_.
Quick, does rand() default to $_ in Perl 5?  (I don't remember...)

On the other side, with the method call syntax changing from -
to dot we have the ability to indicate use of $_ explicitly with a
single character:

for @list { .print }

So the only remaining issue is making sure people don't use the old
form by accident and silently get the wrong output.  Hence the warning,
emitted by STD now as:

Potential difficulties:
   Unsupported use of bare 'print'; in Perl 6 please use .print if you want 
to print $_, or use an explicit argument at (eval) line 1:
-- for @list { print⏏ }

Larry

Re: deprecated (was Re: r29143 ...)

[Larry Wall]

On Thu, Nov 19, 2009 at 11:22:17PM -0800, Darren Duncan wrote:
 pugs-comm...@feather.perl6.nl wrote:
 @@ -1020,22 +1018,17 @@
   C prefix:int 
  -Coerces to type CInt.  Floor semantics are used for fractional
 -values, including strings that appear to express fractional values.
 -That is, Cint($x) must have the same result as Cint(+$x) in all
 -cases.  All implicit conversions to integer use the same semantics.
 +Deprecated, use the CInt() coercion or the Cfloor function.

 Why would the Perl 6 spec contain anything deprecated rather than simply 
 not having it at all?

Only because it was already implemented in earlier versions of Perl 6,
and someone might look it up here.

 Or do you mean deprecated as in the parser will explicitly recognize it 
 and die with a helpful error message, such as it does for Perl 5's =~ 
 to catch brainos?

Nope, that'll tend to either work anyway with int() or fail with two terms
in a row for int $x.  It might be worth a special message I suppose.

 If you mean the latter, is there some central place (say in Synopsis 2) 
 that talks about this, such as in a terminology section?  When the 
 Perl 6 spec uses the word ... it means ...

You must think I'm writing a *real* spec.  :)

Larry

Re: r29121 - docs/Perl6/Spec

[Larry Wall]

On Wed, Nov 18, 2009 at 03:08:59AM -0800, Ron wrote:
:  +Although most rational implementations normalize or reduce fractions
:  +to their smallest representation immediately through a gcd algorithm,
:  +Perl allows a rational datatype to do so lazily at need, such as
:  +whenever the denominator would run out of precision, but avoid the
:  +overhead otherwise.  Hence, if you are adding a bunch of CRats that
:  +represent, say, dollars and cents, the denominator may stay 100 the
:  +entire way through.  The C.nu and C.de methods will return these
:  +unreduced values.  You can use C$rat.=norm to normalize the fraction.
:  +The C.perl method will produce a decimal number if the denominator is
:  +a multiple of 10.  Otherwise it will normalize and return a rational
:  +literal of the form -47/3.  Stringifying a rational always converts
:  +to CNum and stringifies that, so the rational internal form is
:  +somewhat hidden from the casual user, who would generally prefer
:  +to see decimal notation.
: 
: Wouldn't it be better to produce a decimal number if the denominator
: equals of 2**n * 5**m for n,m unsigned int? Before displaying the
: value should be decimal-normalized by multiplying numerator and
: denominator by 2**|n-m| or 5**|n-m| depending on sign(n-m).
: Otherwise adding Rats representing dollars and cents which are
: immediately normalized could produce flapping between rational literal
: form and decimal number form.
: Aside from that the specification should be: if the denominator equals
: 10**n, with n unsigned integer, .perl will produce a decimal number.
: Otherwise 1/30 would produce a decimal number like 0.033..., which
: was probably not intended.

Good catch; I thought power and typed multiple.

I was hesitating to extend it to require factoring for the solution,
but there's actually a fast way to factor for 2's and 5's.  Just shift
off all the 0 bits on the bottom to take out all the 2's, and then
look up the remaining number to see if it's a power of 5.

So I'm inclined to make normal stringification also produce an exact decimal
by default and only failover to Num if .perl would produce the 1/3 form.
In the absence of an explicit format, I think exactness should trump
limiting the size of the resulting string arbitrarily.

Larry

Re: r28751 - docs/Perl6/Spec

[Larry Wall]

On Sun, Oct 11, 2009 at 11:47:45AM -0400, Brandon S. Allbery KF8NH wrote:
 On Oct 11, 2009, at 06:36 , Mark J. Reed wrote:
 That's not grammatical; you've just created a run-on sentence.  Why  
 not
 leave it as a colon?

 Or semicolon.  I agree comma seems wrong.

Colon is correct here because the second phrase defines what we mean
in the first phrase.  It could also be viewed as a logical consequence,
though semantically it's more like a final cause.  But in general
a colon indicates that we're explaining what we mean in the first part,
which is a tighter relationship than the mere juxtaposion of semicolon,
which leaves the reader to work out the relationship.

Larry

Re: in list context

[Larry Wall]

On Tue, Sep 29, 2009 at 03:49:31PM +0200, Christoph Bussenius wrote:
: Hi,
: 
: I read is S03,
: 
: The  and || operators are smarter about list context and return ()
: on failure in list context rather than Bool::False. The operators
: still short-circuit, but if either operator would return a false
: value, it is converted to the null list in list context so that the
: false results are self-deleting.
: 
: For , wouldn't it be a better idea to return an empty list only if
: the *first* operand is false?  In other words, I suggest that $a  $b
: behave in list context like this:
: 
: * If $a is false, return ()
: * Otherwise, return $b
: 
: Here's a use case that would benefit from this behaviour:
: 
: Suppose you want to generate an argument list for an external command.
: For some reason you have a boolean value $include_arg3 and you want to
: include $arg3 only if $include_arg3 is true:
: 
:my @args = $arg1, $arg2, $include_arg3  $arg3, $arg4;
: 
: Here you probably want to include $arg3 even if it is a false value like
: 0, provided that $include_arg3 is true.

Hmm, well, I see your point, but there are some arguments for the current
behavior as well:

* Changing  without changing || would introduce a strange asymmetry.

* Changing  to be pure conditional kinda undoes the list associative
meaning of 'return the first false value or the last value'.

* It would imply propagating list context to the left side but not
the right side, which is time-travelishly problematic in a
lazy language.

* Alternately, it would mean that the result would have to be marked
as to whether it came from the left or the right so that binding
into a list context would know whether to throw it away or not.

* Or one could return Nil instead of the left value, but then you
  lose any interesting value of false.

* If one wants it to mean

   my @args = $arg1, $arg2, ($arg3 if $include_arg3), $arg4;

  one can write it that way, since Cif already knows it's about
  control flow, not data selection, and returns Nil on false.  Or
  you can write:

   my @args = $arg1, $arg2, (if $include_arg3 {$arg3}), $arg4;

  if you want them in the other order.

* If you know you're generating *positional* arguments ahead
  of time, you probably don't want list processing anyway; you
  probably want to put the args into a parcel/capture anyway to
  delay the application of context until binding time:

my $args = \($arg1, $arg2, $include_arg3  $arg3, $arg4);

  In this case the result of the  is its own parcel/capture
  that waits until binding time to decide how to behave.

But I agree that it's a trap of sorts.  My gut feeling is that it
won't happen often enough to become a FAQ, but I could be wrong.

Larry

Re: [perl #69194] rakudo 2009-08 and when with lists

[Larry Wall]

On Sun, Sep 20, 2009 at 01:29:22AM -0400, Aaron Sherman wrote:
: On Sat, Sep 19, 2009 at 9:45 PM, David Green david.gr...@telus.net wrote:
: 
:  On 2009-Sep-19, at 5:53 am, Solomon Foster wrote:
: 
:   The one thing that worries me about this is how :by fits into it all.
: rakudo: given 1.5 { when 1..2 { say 'between one and two' }; say
:  'not'; };
: rakudo: given 1.5 { when Range.new(from = 1, to = 2, by = 1/3) {
:  makes me very leery.  I know :by isn't actually implemented yet, but what
:  should it do here when it is?
: 
: 
:  Exactly: 1.5 is between 1 and 2, but if you're counting by thirds, 1.5 is
:  not in the list(1..2 :by(1/3)).  Sure, we can stipulate that this is simply
:  how the rules work, but people are still going to get confused.  On the
:  other hand, we can get rid of the list/series/:by part of Ranges without
:  losing any power (move that capability to ... instead), and cut down on the
:  confusion.
: 
: 
: 1..2 is used abstractly to indicate a range, even though it's actually an
: iterator that will return two values. However, once you apply an explicit
: :by, I think you've gone past that abstraction, and it's no longer
: reasonable to expect that values that fall between your iterations will
: match.

Yes, I think it's fair to say that either list context OR a :by turns
a Range into a RangeIterator that matches like a list.  Hence, this
ought to match:

(1,3,5) ~~ (1..5 :2by)

Larry

Re: Synopsis 02: Range objects

[Larry Wall]

On Thu, Aug 27, 2009 at 02:21:12PM -0700, Jon Lang wrote:
: 2.5 ~~ 1..5 # true: equivalent to 2.5 ~~ 1 = $_ = 5.

Current specced behavior for Range objects.

: 2.5 ~~ @(1..5) # false: equivalent to 2.5 ~~ (1, 2, 3, 4, 5).

Not by current rules; which say the left side matches the list 1..5
as a whole.  We don't do implicit junctifying of lists anymore, and haven't
for several years.  Which points to the correct Perl 6 utterance for that:

2.5 ~~ any(1..5)# false

Wherein, as you suggest, the 1..5 in list context does in fact iterate the
range to produce individual values.

Larry

Re: Synopsis 02: Range objects

[Larry Wall]

On Tue, Aug 25, 2009 at 02:58:05PM -0700, Jon Lang wrote:
: Michael Zedeler wrote:
:  The obvious (default) choice for a step size would be the precision of
:  the more precise of the two values.  So 0.0001 in your example above.
: 
: 
:  Well... maybe. How do you specify the intended precision, then? If I want
:  the values from 1 to 2 with step size 0.01, I guess that writing
: 
:  1.00 .. 2.00
: 
:  won't be sufficient. Trying to work out the step size by looking at the
:  precision of things that are double or floats doesn't really sound so
:  feasible, since there are a lot of holes in the actual representation, so
:  1.0001 may become 1.0, yielding very different results.
: 
:  It could be really nice to come up with something dwimmy, but I can't really
:  se any really good candidates, when it comes to floating point numbers and
:  strings.
: 
: For floating point numbers, assume a default step size of 1, just like
: integers; use the :by adverb to specify a different step size, either
: by supplying a floating point number to be added in or by supplying a
: block that generates the next step when fed the current one.  So:
: 
: 1.00 .. 2.00 # 1.00, 2.00
: 1.00 .. 2.00 :by .01 # 1.00, 1.01, 1.02, ..., 1.98, 1.99, 2.00

Note that your :by adverb is malformed; it must be :by(.01), or it's
parsed as a boolean :by followed by a term.

Another note, it's likely that numeric literals such as 1.23 will turn
into Rats rather than Nums, at least up to some precision that is
pragmatically determined.

: Also, I want to second David Green's point: we're not talking Range
: and Interval here; we're talking Range and Series.  A Series
: would be a kind of Range that has the additional ability of generating
: a list.  The :by adverb would be a property of a Series, but not a
: Range.  Using Num for your endpoints would result in a Series; using
: Complex for your endpoints should result in an error: Complex numbers
: don't have a viable definition of before or after, let alone
: between.

We already make this distinction in the spec.  A Range means an
interval, possibly annotated with a step, but this is meaningless
unless the range is iterated.   An attempt to use such a Range in a
list produces a RangeIterator, which yields a series of values.

However, the name series operator is already reserved to mean
infix:... rather than infix:...  So your second example above
basically turns into this series:

1.00 ... { $_ + 0.01 if $_  2.00 };

except that 1.00 .. 0.00 produces (), not 1.00.  A more exact
translation might be

() ... - $x = (1.00-0.01) { $x + 0.01 if $x  2.00 };

I am currently assuming such loops will default to Rat rather than
Num for numbers that aren't too far off the beaten path, where
on the beaten track is defined as rats that fit into a pair of
int64s or so, that is, which can be represented with rat64.

Larry

Re: S05 (regex) Q: after

[Larry Wall]

Modifiers like :ratchet are lexically scoped, and therefore extend
into any embedded ?before... or ?after..., I think.  These days
if you find yourself saying surrounding context, you should usually
ask yourself whether you mean lexical or dynamic, and that often
indicates the direction I'll be leaning on underspecced issues,
especially if you assume I have a bias towards lexical unless dynamic
is explicitly mentioned.

I supposed it could be argued that the argument to a before or
after is hidden from the outer lexical scope, such as in

foo(arg)

but I'd say that even there, the language inside the parens is still
inherited from the surrounding language braid, which is a lexically
scoped concept.  The current outermost language is called $~MAIN (see
S02) while the current regex language is called $~Regex.  It just
has to look outward a bit further to see what the current definition
of $~MAIN is than it would have to look for $~Regex.  But all the ~
twigil variables are working together to define the current lexical
scope's language in an interwoven fashion.  Which is why we call
it a braid of languages.

Larry

Re: Rukudo-Star = Rakudo-lite?

[Larry Wall]

Rakudo Zengi would be the most (in)appropriate, I think.

Larry

Re: confusing list assignment tests

[Larry Wall]

On Tue, Jul 28, 2009 at 09:24:40PM +0200, Moritz Lenz wrote:
: sub W () { substr(eval('want'), 0, 1) }
: ...
: 
: # line 560:
: {
: my @a;
: my @z = (@a[0] = W, W);
: #?rakudo 2 todo 'want function'
: is(@a, 'L','lhs treats @a[0] as list');
: is(@z[0], 'L', 'lhs treats @a[0] as list');
: ok(!defined(@z[1]), 'lhs treats @a[0] as list');
: }
: 
: 
: This tests that
: 1) both calls to want() are in list context
: 2) @a[0] gets only the return value of the first call to W()
: 3) @z[0] gets the same thing
: 4) There's no item for @z[1]
: 
: Somehow I think this test (and many similar tests) are dead wrong.
: Here's why:
: 
: Either it's parsed as '@a[0] = (W, W)' (list assignment), then @a should
: get both elements, and so should @z.

Not according to S03, at least by one reading.  @a[0] as a scalar
container only wants one item, so it only takes the first item off
the list, and the list assignment produces a warning on the second
because it's discarded.  Since an assignment returns its left side,
only one element is available to @z from @a[0].

: Or it's parsed as '(@a[0] = W), W' (item assignment), then the first
: call should be in item context, and the second one in list context, and
: @z should still get both items.

It's not parsed like that, because only $x, $$xref, $($xref) and such
are allowed targets for item assignment.  Basically, it has to start
with a $ sigil and not do anything fancy like subscripting.   However,
if you say

@z = $x = $a, $b;

it parses as @z = ($x = $a), $b and $b ends up in @z[1] but not
in $x, which only gets $a.

: Right? Or am I completely missing something important here?

To get all the elements into $x you'd have to say

@z = $x = ($a, $b);

and @z[0] would be ($a,$b) with some type or other, whatever was
returned by the parens, quite possibly Parcel (that is, List of Thunk
or some such).

: My current plan is to write such tests as
: 
: sub l { 1, 2 } # return a short list
: {
: my @a;
: my @z = (@a[0] = l(), l());
: is @a[0].elems, 4, '@a[0] =  treats LHS as list'
: is @z.elems,4, '... and passes all elements on the right';
: }
: 
: Does this look sane, and match your understanding of assignment?

Yes, but no.  @z.elems and @a[0].elems should both be 1, I suspect.
I wish we had a way of trapping and testing warnings too so we could
see that 3 elements were discarded by the inner list assignment..

Larry

Re: confusing list assignment tests

[Larry Wall]

On Tue, Jul 28, 2009 at 01:22:28PM -0700, Jon Lang wrote:
: Larry Wall wrote:
:  Moritz Lenz wrote:
:  : Either it's parsed as '@a[0] = (W, W)' (list assignment), then @a should
:  : get both elements, and so should @z.
: 
:  Not according to S03, at least by one reading. �...@a[0] as a scalar
:  container only wants one item, so it only takes the first item off
:  the list, and the list assignment produces a warning on the second
:  because it's discarded.  Since an assignment returns its left side,
:  only one element is available to @z from @a[0].
: 
: So, do we still have p5's 'want_array' (or whatever it was called)?
: That is, the predicate that tells the you whether the function is
: being called in item or list context?  I know that the generalized
: 'want' function proved to be unworkable; but I'd expect p6 to at least
: be able to do everything that p5 can do; and that includes functions
: that are aware of whether they're being used as singular or plural.

Perl 6 is not about doing everything that Perl 5 can do.  It's about
breaking everything that needs breaking.  This is one of those things.

We *may* have something like want someday, but if so, it can only
work by time travel (read: return a type profile with lazy values,
and let the eventual binding of the type profile call back for the
actual values).  But I doubt will require such for 6.0.0 in any case.

But Perl 6 is based on knowing the types to do MMD, and we have to know
at least those types, even if we don't know the values.  That makes
it very difficult for a function that wants to return *different*
types based on the eventual dispatch, since the eventual dispatch
depends on those types in a circular sort of way.  Sanity dictates
that we make time flow forward rather than backward for most of what
Perl 6 programmers will want to do most of the time.

Larry

Re: confusing list assignment tests

[Larry Wall]

On Tue, Jul 28, 2009 at 10:42:01PM +0200, Moritz Lenz wrote:
: I guess when I initialize @a[0] = [] it's the same, because then @a[0]
: is still a scalar, right?

No, as in Perl 5 [] still produces a scalar object that hides the arrayness
from list context, so it's like:

$b = [];
@a[0] = $b;

It doesn't unwrap the scalar object to see what's in it.

: Only when I wrote @a[0] := [] I'd get all items in @a[0].

That binds the Array in place of the current @a[0] container, just as

$b = [];
@a[0] := $b;

would.

Just as $obj and @$obj default differently in list context, so do
[] and ().  To put it another way, Array and Hash objects don't
naturally interpolate into list context without some help from @ or %
syntax (or equivalent method call).  If I say:

@a = 42, [1,2,3], { foo = 1, bar = 2, baz = 3 };

then @a will always end up with exactly 3 elements, just as if I'd
said:


$a = 42;
$b = [1,2,3];
$c = { foo = 1, bar = 2, baz = 3 };
@a = $a, $b, $c;

Larry

Re: Parameter binding

[Larry Wall]

On Sat, Jul 25, 2009 at 06:50:12PM -0700, yary wrote:
: On Sat, Jul 25, 2009 at 2:04 PM, Patrick R. Michaudpmich...@pobox.com wrote:
:  On Thu, Jul 23, 2009 at 05:56:31PM +0200, TSa wrote:
:  Hmm, it seems to be the case that the binding is defined to be a
:  readonly binding to the variable. I consider this a bad 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.
: 
:  ...except that captures don't capture values -- they form references.
: 
: So we get a call to foo with three identical references to $x, which
: has the value 3, or 1? That would be interesting. Or is capture
: meant to be lazy, and any postincrement is only called the first time
: foo dereferences that parameter? That would be very interesting! Which
: I would fully support in a language whose code I never had to
: maintain, but would not have to want to explain to anyone with a
: straight face.

Yes, I think think you're probably right that the correctest answer
to this will be to make the operation of binding $x++ trigger
the autoincrement lazily.  But I don't think you'd have to explain
anything for ordinary calls, since there is a one-to-one correspondence
between capture formation and binding, and the binding happens almost
immediately after capture composition (perhaps only notionally, since
capture composition an obvious optimizer target).  The only time it
would be difficult to explain is if you say something like:

my $capture := \($x++);
foo(|$capture); # increments $x
bar(|$capture); # increments $x again

But perhaps \($x++) can be explained by analogy to { $x++ }.  It's
basically just a thunk, and the eventual binding and/or evaluation is
what prevents it from degrading into the morass of call-by-name-ness.
So it's very much like the thunks in

$maybe ?? $x++ !! $y++

where you don't know which will be incremented until the implementation
of ??!! decides to run one thunk or the other.

It's also a strange way to name a monadic sort of relationship:

my $capture := \($x++);
$x = 0;
|$capture xx *  # 0,1,2,3,4

Lately I've been thinking of lazy lists as Perl 6's cheap knockoff
of the idea of monads, modulo the appropriate amount of handwaving
(not to mention handwringing) over side effects.  Naming a lazy list
basically gives a name to the relationship between the consecutive
elements (where in the case of infix:... the new elements are
specifically defined in terms of the prior ones).  Yes, I'm ignoring
a bunch of cool type theory when I say that.  I'm hoping this will
make Perl 6 usable by non-geniuses without getting them into trouble
too terribly often.  :)

But certainly a lot of the get-into-trouble examples involve $x++,
so we'll need to be careful with that particular monad^Wside effect.

Larry

Re: r27635 - docs/Perl6/Spec

[Larry Wall]

On Mon, Jul 20, 2009 at 07:33:23PM -0700, Jon Lang wrote:
: A stronger argument against it would be to find comparison operators
: that exist at other precedence levels.  I don't think that there are
: any.  (Well, besides =, leg, and cmp.)

I think people would find it quite odd if an operator named cmp can't
be considered a comparison operator.

: Indeed, I'll be surprised if there are any other precedence levels
: that are chaining - which is another key point: what kind of operator
: would be chaining, but _not_ some sort of comparison?

Congratulations, with that argument you've completely persuaded me that
Chaining is the most precise description of that precedence level,
and we should leave it just the way it is now.

The reason I renamed Nonchaining is not that I dislike the concept
of chaining, but that all the *other* non-chaining precedence levels
are also, er, non-chaining. :)

Though the proximate cause was that it made for a stupid error message,
which indicated that the old name wasn't sufficiently accurate:

  Can't reduce a nonchaining operator because it's diffy and not chaining

It now reads:

  Can't reduce cmp because structural infix operators are diffy and not chaining

In short, chaining is a good concept, but non-chaining is bad
(and doubly bad when it means two different things).

Larry

Re: YAPC::EU and Perl 6 Roles

[Larry Wall]

On Wed, Jul 08, 2009 at 01:59:53PM -0700, Dave Whipp wrote:
 Ovid wrote:

 I'd like to see something like this (or whatever the equivalent Perl 6 
 syntax would be):

   class PracticalJoke does Bomb does SomeThingElse {
 method fuse() but overrides { ... }
   }

 The overrides tells Perl 6 that we're overriding the fuse() method
  from either Bomb or SomeThingElse (or both).  Otherwise, a warning
  or exception would be useful to prevent me from accidentally overriding
  needed behavior.

 This would also be useful to catch the case where you mistype the  
 override method, and so have to go debug why you're still using the
 base-class (or role) version of the method.

Note we already have syntax that can be applied here:

supersede method fuse {...}
augment method fuse {...}

It only remains to spec what those mean... :)

Larry

Re: XOR does not work that way.

[Larry Wall]

On Fri, Jul 03, 2009 at 09:40:12AM +0200, TSa wrote:
 I see. But I wouldn't make that an exception but ^^ returns a tristate
 value instead of boolean. The third state besides True and False is
 TooMany that evaluates to False in boolean context. But ^^ can react
 to it as you describe. That solves the associativity problem, indeed.
 Hmm, perhaps a TooFew value is nice as well. Then one can 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 we write that into the spec?

I suspect that boolean operators should stay boolean operators,
and counting should usually be done with normal integers.  In
other words, this is too much mechanism for too little payback.

Larry

Re: r27312 - docs/Perl6/Spec

[Larry Wall]

On Mon, Jun 29, 2009 at 09:14:10PM -0700, Darren Duncan wrote:
 pugs-comm...@feather.perl6.nl wrote:
 +When it happens that the same module is available from more than one
 +authority, and the desired authority is not specified by the Cuse,
 +the version lineage that was created first wins, unless overridden by
 +local policy or by official abandonment by the original authority (as
 +determined either by the author or by community consensus in case the
 +author is no longer available or widely regarded as uncooperative).
 +An officially abandoned lineage will be selected only if it is the
 +only available lineage of locally installed modules.
 +
 +Once the authority is selected, then and only then is any version
 +selection done; the version specification is ignored until the
 +authority is selected.  This implies that all official modules record
 +permanently when they were first installed in the official library,
 +and this creation date is considered immutable.
 +
  For wildcards any valid smartmatch selector works:
   use Dog:ver(v1.2.1 | v1.3.4):auth(/:i jrandom/);

 So now you've explicitly stated what I implicitly (or maybe explicitly) 
 thought before, in that version numbers are always subordinate to 
 authorities, and only make sense in the context of an authority, though 
 an explicit authority doesn't have to be declared in user code.

 I propose that the canonical order of entity long names be altered so 
 that the :auth always comes first, and :ver second, when both are used.

 For example:

 use Dog:auth(/:i jrandom/):ver(v1.2.1 | v1.3.4);

 The documentation should be in that order, not the other order.  Then I 
 think the syntax better corresponds to the actual interpretation, 
 conceptually where each new trait (or trait-looking thing) is interpreted 
 in the context of those before it.  And I don't just mean example code, 
 but explanation order too.

I agree, and since you've got a pugs commit bit, feel free to fix it if
I don't get to it.  I've got about three other fundamental design issues
distracting me at the moment, alas...

Larry

Re: Multi-d array transforms (was Re: Array rotate)

[Larry Wall]

On Sat, Jun 13, 2009 at 02:49:10PM -0500, John M. Dlugosz wrote:
 Wow.  The overarching logic for list assignment would have to compare  
 the containers and the arguments in the capture before doing the list  
 assignment to each container, in order to avoid cloning all the  
 containers on the right first in the general case.  It can't just copy  
 values out because they may contain iterators or be lazy or be infinite.

Well, that's not really a problem, as long as the same semantics
are preserved.  All you need to do is cut loose the contents of the
container completely to the mercy of GC, build a new one with the
appropriate structure, then copy values in from the assignment's RHS.
The only reason Perl 5 couldn't do it this way is that the idiot who
wrote it prematurely optimized values on the stack so that they didn't
need to be reference counted. :)

Larry

Re: Multi-d array transforms (was Re: Array rotate)

[Larry Wall]

We also need to consider the dimension of referentiality.  I can see
three levels here.  Given

@a.mung

the .mung could return

A) a modified @a (treat @a as mutable)
B) a new array (treat @a as immutable)
C) a remapped array whose elements refer back to @a's elements

Currently .rotate is defined as A, but I could easily switch it to B,
so you'd have to write

@a.=rotate;

to rotate in place.  If we did that, then we could conceivably set
things up with more PDLish C semantics so that

@a .= mung  # A semantics
@b  = @a.mung   # B semantics
@b := @a.mung   # C semantics

This implies, however, that the copy semantics of = are sufficiently
clever to snapshot all the referenced values of @a before clobbering
@a in the case of either:

@a .= mung
@a = @a.mung

But list assignment really ought to be doing that in any case.

Maybe .push is really sugar for .=append, and unshift is really sugar
for .=prepend.

Larry

Re: Array Dimensionality (Was: Re: Multi-d array transforms (was Re: Array rotate))

[Larry Wall]

On Fri, Jun 12, 2009 at 04:00:10PM -0300, Daniel Ruoso wrote:
: Em Sex, 2009-06-12 às 11:52 -0700, Jon Lang escreveu:
:  On Fri, Jun 12, 2009 at 11:51 AM, Daniel Ruosodan...@ruoso.com wrote:
:   Ok, There's one thing that is not clear in the thread, which is when an
:   array is multidimensional or not...
:   For instance:
:@a = (1, 2, 3; 4, 5, 6; 7, 8, 9);
:   Will produce a flatten array, because list assignment causes flattening,
:   so the dimensionality was lost.
:  Right.  I should have said:
:  @@a = (1, 2, 3; 4, 5, 6; 7, 8, 9);
: 
: The important point here is that it means we're dealing with a different
: type, so it can actually behave differently, so @@a.rotate would
: rotate the first dimension only..
: 
: maybe @@a.rotate(1;1) would mean to rotate by 1 in the first dimension
: and by 1 in the second, producing
: 
:  (5, 6, 4; 8, 9, 7; 2, 3, 1)

I think captures are a bit of a red herring here.  Arrays can be shaped
without the @@ sigil, and that is part of its type, so assignment to
@a and @.rotate can also do the right thing.

The @@ context was originally just a way of declaring a context that turns
nested captures into a multidimensional array at binding or
coercion time.  So

@a := @@(1,2,3; 4,5,6; 7,8,9);

used to be defined as the same as

@a := [[1,2,3], [4,5,6], [7,8,9]];

Treating @@ as a capture sigil would make @@ coercion a no-op.
So perhaps @@ isn't the Texas form of a capture sigil after all.

Alternately, we leave @@ (or @%) meaning ¢ and instead let some
other syntax take over the pay attention to the capture's structure
semantics from @@.  Maybe it's another use for the zen slice:

@a   = (1,2,3; 4,5,6; 7,8,9); # 1..9
@a[] = (1,2,3; 4,5,6; 7,8,9); # [1,2,3], [4,5,6], [7,8,9]

Interestingly, that would mean that

@a   = 1,2,3;   # 1,2,3 3 elems
@a[] = 1,2,3;   # [1,2,3]   1 elem!

much like subscripts assume .[1,2,3] is a 1-dim slice of three
elements, not a 3-dim vector pointing to a single element.

There's something slightly pleasing about the equivalence

@a = [1,2,3];
@a[] = 1,2,3;

Larry

Re: Multi-d array transforms (was Re: Array rotate)

[Larry Wall]

On Sat, Jun 13, 2009 at 01:25:23AM +0200, Daniel Carrera wrote:
 Damian Conway wrote:
 In fact, I would even be happy with requiring @a.=push and @a.=shift, if
 it meant that there were *no* special cases. One extra character is a
 small price to pay for perfect SWIM (and not just Say What I Mean,
 the real benefit is the other SWIM: See What I Meant).

 I don't like @a.=shift. It looks like @a = @a.shift, which is of course  
 not what you mean.

He meant unshift, I suspect.

Nevertheless, for any major methods borrowed from Perl 6, I'm not
inclined to change them that drastically.  Much more likely to
define them as sugar for the more general list operators:

.push   means   .=append
.unshiftmeans   .=prepend
.splice means   .=impend:-)

or some such.

Larry

Re: Assigning duplicate values to several hash keys using junctions?

[Larry Wall]

On Mon, Jun 08, 2009 at 12:02:43PM +0100, Ville Koskinen wrote:
: An alternative is always
: 
: @hash{qw(foo bar)} = ('some value') x 2;
: 
: which is probably
: 
: %hashfoo bar = ('some value') x 2;
: 
: in Perl 6, but you always need to take care to write the correct integer
: in the list replication.

Two problems.  First, list replicaiton is xx rather than x, and second,
you *don't* have to write the integer, because you can use the
Whatever star:

%hashfoo bar = 'some value' xx *;

That makes an arbitrarily long list of strings.

: The best way is, of course, (in Perl 5)
: 
: {
:my @keys = qw(foo bar);
:@ha...@keys} = ('some value') x @keys;
: }
: 
: but then you need the @keys array, which needs to be defined if you are
: dealing with literal values.

Perl 6's new * term is useful in many such places where you just want
to say, I dunno, you figure it out.

: Reading the synopses, one possibility seems to be 
: 
: %hashfoo bar = 'some value';
: 
: using hyper operators, but is that really the best way?

If you'll define best way, I'll tell you if it is.  :)

The relative efficiency is going to be difficult to predict because
any of these could be poorly implemented and do too much busywork.
Apart from that, it's gonna come down primarily to what you think
is readable.

By the way, infix hypers want to go on both sides, like this:

%hashfoo bar »=» 'some value';

Larry

Re: say followed by lines - inconsistencies

[Larry Wall]

On Tue, Jun 09, 2009 at 12:37:10AM +0400, Richard Hainsworth wrote:
 I write a hash to a file delimited by tabs, eg

 my $fn=open('data.csv',:w);
 my %x=one two three four Z 1,2,2.1,3;
 $fn.say('record-name'~map(\t$^a\t$^b),%x);
 $fn.close;

 The output sometimes contains either the keys or the values padded with  
 single spaces on either side (I cannot find a pattern for the spaces). I  
 am not sure whether this a bug of say (or $fn.say() ).

Well, regardless of whether there are extra spaces, please note that
the default stringifications are not intended as a serialization
format.  They are intended only to provide a bit of human readability
for the common case of small, spaceless items such as numbers and
words; they make no guarantee about the sanity of the delimiters.

 So now I want to read in the data again. (The problem arises because  
 perl6 has a memory leak and my program segfaults after five loops, so I  
 need to store the intermediate data; this is a serialisation problem,  
 but I dont need to go to the extreme of yaml for it).

Hmm, if you think yaml is extreme, yowie, the world is a harsh place...

I guess I can only suggest that you use .perl instead, for a minimal
serialization format.  Or write your own explicit formatting and
serialization using .fmt calls.

Larry

Re: Anonymous multidimensional array

[Larry Wall]

On Tue, Jun 02, 2009 at 08:21:29AM -0700, yary wrote:
: I do see a problem if there's more than one unspecified dimension.
: Though I suppose an array of shape(*;*) as an lvalue might be a
: constraint allowing assignment only of another 2D array?

I don't see why we shouldn't use the capture shape of the value
by default all the time, and do linear reshaping only if the value
comes in as a flat list.  We've gone to some pains to allow ephemeral
shaping of values through captures, and it seems like it's good error
checking to check the shape of the value against the shape of the
container unless explicitly defeated.

That is to say, if you erase the capture shape by putting the value
into list context, it linearizes it, and then the container knows
to reshape.  Otherwise the container attempts to use the value slicily.

Larry

Re: Amazing Perl 6

[Larry Wall]

On Sun, May 31, 2009 at 04:45:12PM -0400, Brandon S. Allbery KF8NH wrote:
 On May 29, 2009, at 15:43 , John M. Dlugosz wrote:
 Care to try ☃ ?  That's alt-meta-hyper-doublebucky-cokebottle.


 *puzzled as to why OSX Character Map thinks that's related to 雪*

Maybe they can't tell the diffence between snowman and snow?
(By the way, if you know any 日本人 named Yuki, they probably
write their name with 雪.  Which is a really cool (no pun intended)
character--if you look at the two radicals, it basically means
precipitation you can grasp.  :)

Larry

Re: Anonymous multidimensional array

[Larry Wall]

On Mon, Jun 01, 2009 at 08:23:41PM -0700, yary wrote:
: How does one create an anonymous multidimensional array in p6? Not an
: array of arrays or a capture of captures...

But I would expect a shaped array to be able to coerce either of
those into its internal format.  And coercing captures into
structure is basically what @@/slice context is for.

Larry

Re: renaming or adding some operators

[Larry Wall]

On Fri, May 29, 2009 at 11:06:46PM -0700, Darren Duncan wrote:
 Larry, did you choose = for assignment and == etc for comparison because 
 you thought that looked prettier, or because that was the C/etc 
 convention that you decided to copy?

Neither beauty nor convention, really.  I chose it for the same reason
that C chose it: Assignment is much more common than testing equality,
so this is pure Huffman.  This was specifically mentioned in the
original rationale for the design of C, because by percentage there
were more mathematicians in programming then than there are today.
So there was certainly some pressure to use = for equality back in the
day, and I give KR credit for helping establish the Huffman principle.

Certainly the Huffman principle was largely ignored by the designers
of COBOL.  The first time I saw that you call a subroutine with
perform, I said to myself, Something's desperately wrong here.
Why didn't they just use 'do'?  Which you'll notice is how Perl 1
called subs.  Of course, eventually I figured out that two characters
is still too long for that, so I changed it to 1 character, , a
little slow to realize that the correct answer was 0 characters...  :)

These days I try to be stupid about other things instead.

Larry

Re: renaming or adding some operators

[Larry Wall]

On Fri, May 29, 2009 at 08:45:06PM -0700, Darren Duncan wrote:
 So does anyone else have thoughts on that?

Actually, I think ~x is kinda ugly.  And I like the mnemonic value of
x returning one thing and xx returning multiple things.  And in the
bitwise ops ~ doesn't indicate postprocessing.  And given that we've
only used a ~ modifier in bitops, people would look at ~x and try to
figure out what kind of bitop it was meant to indicate.  And in any
case, it would be silly to actually implement string replication in
terms of list replication.

So by all means feel free to speculate on what a mathematical syntax
module might tweak, but there are lots of obvious and not-so-obvious
reasons to keep the standard operators pretty much the way they
already are.  Most of the current-day tweaks are driven by semantic
simplifications, not the desire to refactor S03 yet again in pursuit
of some kind of completist agenda, which you know can never entirely
satisfy the mathematicians.  :)

Larry

Re: renaming or adding some operators

[Larry Wall]

It occurs to me that, while I don't want to pull in all the
possible Unicode operators by default, we should make it easy
to do so.  Perhaps something like

use *;

should pull in all the Unicode operators.  Which if course means that
any golfing would start with

*;

to pull in all the possible operators in non-strict mode, and turn
on the mode where methods can be specified by the first few unique
characters, and maybe turn off mandatory whitespace in a few spots. :)

Larry

Re: renaming or adding some operators

[Larry Wall]

On Sat, May 30, 2009 at 01:09:01PM -0600, David Green wrote:
 I think that one's ambiguous as to whether $bar exists as a key or a  
 value.

 $bar ∈ @foo; $bar ∈ %foo.keys; $bar ∈ %foo.values;  ∃ %foo{bar}

Generally when hashes have been used as sets we've taken the keys
to be the set, not the values, since the keys guarantee uniqueness.

However, even defining it that way, a hash should really be considered
a set *container* rather than a set, since sets are immutable, and
hashes aren't.  This is why we distinguish the Set type from the
KeySet type.

But tagmemically speaking, it's perfectly fine to *use* a hash
as if it were a set.

Larry

Re: CPAN -- moving forward

[Larry Wall]

On Sun, May 31, 2009 at 12:22:31AM +0200, Daniel Carrera wrote:
 Mark Overmeer wrote:
 A pity you didn't want to read the paper.

 I have better things to do with my life than read your 30-page paper.  
 I'd rather participate in a consensus process where I feel I can make a  
 difference.

What is this, a contest to see who can be snippier?

 Please clarify ... how would you specify that?   And how
 would you denote ranges of conflicting packages?  Well, maybe start
 with putting that in your wishlist.

 And conflicting/dependencies in licenses?
 How would you resolve dependency conflicts? Design human intervention
 in this process of dependency processing.
 [big snip]

 My wiki page was purposely only an initial step. I don't believe in  
 working in isolation for days or weeks and then handing down a massive  
 ready-made solution to the masses. I offer a small, incremental step on  
 top of Synopsis 22 and hope that it is useful.

People have different work styles.  Part of consensus building is
not expecting everyone to think the same way you do.  We try to put
both the tortoises and hares to work here, but each has to work at
their own pace, and some temporal displacement necessarily results.

A healthy community can put up with a certain amount of tension
and compression.  It's called tensegrity when it helps hold us
all together.  It's probably called something else when it drives
us apart.  Please aim for the tensegrity, because I don't want to
figure out what to call the other.

Larry

Re: renaming or adding some operators

[Larry Wall]

On Sat, May 30, 2009 at 04:50:02PM -0500, John M. Dlugosz wrote:
 Note that ≥ and ≤ are bidi mirroring characters in the Unicode  
 Properties.  So if someone were crazy enough to use them as brackets,  
 then the digraph equivalent should work as well, right?

No, they'd only function as digraphs in the infix syntactic category.
Bracketing chars are outside of any such category.  Perl 6 is very
careful to recognize macro-like things only where they would make
sense for their particular category.  That's part of the magic of
STD, that it generates different lexers at each choice point in
the grammar, and does so just-in-time, based on the current language
definition.

Now, within a particular syntactic category you can have conflicts,
and with other categories that are ORed in to it; for example,
prefixes share LTM space with terms and circumfixes, for instance.
So we do have to be a little careful about defining other termish
things that start '' though, since '«'can introduce a term.
That's one of the reasons heredocs don't use that notation any more.
But that only interferes with spots where a term is expected.

There is a corresponding conflict at postfix position, but the two are
causally unrelated.  I hesitate to call them digraphs even, since to
me that kinda implies they're translated without regard to context,
as by a preprocessor, and they're not.

 I'm more interested in making sure that someone _can_ easily define ℝ as  
 a type name than in providing that by default.

Indeed, getting close enough is one of the underlying design themes
of Perl 6.  As to whether we're close to do the operator aliasing in
a mostly digraphic fashion, I'm not sure.  Currently a macro for an
infix would be given the AST of the left argument to play with, and
the opportunity to influence the parse of its right argument.  This is
overkill for a mere alias.  We may need to distingish single-token
substitution macros from macros that govern the ASTs around them in
order to make such operator canonicalization painless, I think.

Larry

Re: Amazing Perl 6

[Larry Wall]

On Fri, May 29, 2009 at 10:47:44AM -0400, Buddha Buck wrote:
: The questions which remain (for me, at least) is if (a) the symbols
: survive in email, and (b) if they really are the proper marks for
: Perl6.

Yes, and yes.

Me, I just defined a compose key, and compose  does the right thing.
(though I often use ^K in vim).

Larry

Re: New CPAN

[Larry Wall]

On Fri, May 29, 2009 at 05:32:16PM +0200, Mark Overmeer wrote:
:  Perl6 and Perl5 have some things in common, just like PHP and Perl5.
: 
:  Perl 6 is the next version of Perl 5 and Perl 6 comes with a Perl 5  
:  compatibility mode and Perl 6 is intended to be able to use Perl 5  
:  modules. That makes Perl 5 different from PHP.
: 
: The parrot-based PHP implementation will be able to link Perl6 and
: PHP code, if I understand correctly.  And the same for Python.  And
: Lua. and so on.  I don't know.  I am less convinced about a strong
: bond than you.

And indeed, Perl 6 considers all other languages to be dialects of
itself.  Even if you say Perl only, any Perl 6 program can say:

use Befunge;

and then continue in the Befunge dialect of Perl 6, assuming the
Befunge Perl 6 module is available.  :)

I realize this is not the current attitude of (much of) the Perl 5
community, but originally Perl succeeded because it *connected* with
everything else it could, not because it was trying to be an island
to itself.  Perl was never supposed to be about drawing boundaries.

Larry

Re: New CPAN

[Larry Wall]

On Fri, May 29, 2009 at 04:32:00PM +0200, Mark Overmeer wrote:
: * Daniel Carrera (daniel.carr...@theingots.org) [090529 14:24]:
:  I think that it would be a good idea to put Perl 5 and Perl 6 modules in  
:  the same CPAN.
: 
: I have a very cowardous reply on this.  My CPAN6 design supports both
: sub-setting and super-setting archives.  So, it can produce three
: access-points: pure-perl6, pure-perl5 and combined.  If they physically
: share a disk store, you even do not even need copies of the releases.
: 
: And... I do not really care what kind of information people keep inside
: the archive.  That is for the founding board of the archive to decide.
: As long as it has meta-data, it is ok to my scope.

I think this is an important point, philosophically.  The internet,
and later the web, both succeeded primarily because they unified
identity *without* resorting to centralization (except to bootstrap
the top-level nameservers, of course).  But identity must not be
confused with location.  It's perfectly fine for various repos to
store only a subset of an archive, just as it's perfectly fine for
a node on the internet to only handle a portion of the traffic.
But they get away with this only because of uniform addressing.

So think of this as more a problem of identity.  The data can flow
wherever it likes, as in a p2p network; as long as you can actually
*name* what you want to acquire, the network can figure out how to give
it to you eventually.  This is why S11 specs that module versions are
immutable once made official, and names include versions and naming
authorities (and presumably some checksumming), so that it doesn't
matter where you get the module from, it will always be the same thing.

Nothing else is likely to scale.  Let's all remember the old joke:

Biologist: What could possibly be worse than a velociraptor?
Physicist: Obviously, an acceloraptor.

Long term, acceloraptors tend to beat out velociraptors.  Perl 6 is
all about being an acceloraptor.  :)

Larry

Re: Amazing Perl 6

[Larry Wall]

On Fri, May 29, 2009 at 09:50:36AM -0700, yary wrote:
: Back to the question of cool things about perl6- after showing some
: of the extended syntax and its expressiveness, put up a slide saying
: it's still Perl.
: 
: Show that much of the basics still work:
:  my @x=('a' .. 'z'); @x[3,4]=qw(DeeDee Ramone);
:   say @x.splice(2,4).join(',')
: c,DeeDee,Ramone,f

That qw is not a good example of what still works, since it is supposed
to be interpreted as a qw subroutine (rakudo bug).  I recommend square
brackets instead.

Larry

Re: Feature request: Grammar debugging support

[Larry Wall]

Can't help you with PGE, but STD supports a trace facility by
setting the STD5DEBUG environent variable to -1, or a set of bits
defined in src/perl6/Cursor.pmc in the pugs repo.

Note the log uses ANSI color, so you might want to use less -R
or some such.

Larry

Re: Amazing Perl 6

[Larry Wall]

On Fri, May 29, 2009 at 05:50:57PM -0500, John M. Dlugosz wrote:
 Copy and paste it from the message into a word processor or other  
 program that lets you choose a font where it is not missing and make it  
 very large so you can see the details.

 Or see http://www.marco.org/83873337 for a large graphic in several fonts.

Or feed it as an argument to this program, whereupon it will tell you
directly which character it is.

Larry

#!/usr/bin/perl -C

binmode STDOUT, :utf8;
$pat = @ARGV;
if (ord $pat  256) {
$pat = sprintf(%04x, ord $pat);
print That's $pat...\n;
$pat = '\b' . $pat . '\b';
}
elsif (ord $pat  128) {# arg in sneaky UTF-8
$pat = sprintf(%04x, unpack(U0U,$pat));
print That's $pat...\n;
$pat = '\b' . $pat . '\b';
}

@names = split /^/, do 'unicore/Name.pl';
for my $line (@names) {
$hex = hex($line);
$_ = chr($hex).\t.$line;
if (/$pat/io) {
print ' ' if /COMBINING/;
print;
}
}

Re: Amazing Perl 6

[Larry Wall]

On Thu, May 28, 2009 at 10:51:33AM -0400, John Macdonald wrote:
: Yes.  The full expression in raw APL for n! is:
: 
: */in
: 
: (where i is the Greek letter iota - iotan is Perl's 1..$n).

Only if the origin is 1.  This breaks under )ORIGIN 0.  cough $[ /cough

By the way, the assumption here is that everyone can process Unicode,
so it's fine to write */⍳n.  :)

Note that that's the APL iota U+2373, not any of the other 30 or so
iotas in Unicode.  :/  Well, okay, half of those have precomposed
accents, but still...

Larry

Re: Amazing Perl 6

[Larry Wall]

On Thu, May 28, 2009 at 09:43:58AM -0400, Mark J. Reed wrote:
: So that much makes sense.  But I still think the two different
: meanings of square brackets in operators are going to confuse people.

You're welcome to introduce more bracketing characters into ASCII.  :P

But seriously, this is one of those tagmemics things, where an A can
be *used* as a B without actually being one.  (For example, a noun
can be used as a verb.)  I think of [op] is the unambiguous name of
an infix operator (bare op is of course useful when unambiguous), and
[op] can be *used* as a prefix operator, or as the short name of the
function when prefixed by the noun marker .  Note that when you say

func()

you are, in fact, using the noun func as a verb.

Anyway, I suspect people are generally pretty good at differentiating
such things from the visual context.

Larry

Re: Amazing Perl 6

[Larry Wall]

On Thu, May 28, 2009 at 02:55:10PM -0400, Mark J. Reed wrote:
: Since when are we limited to ASCII again? :)

Well, we used some of Latin-1's bracket offerings, and people already
carp about that.  :)

: If this is just a question of prefix vs infix telling you what [+] is
: shorthand for, OK. But it seems there's still scope for conflict
: between the two meanings of the square brackets.  I mean, prefix ops
: can be used in reduce, too, right?

I will let you ponder the meaning of reduce a bit more, and the
relationship of that to the respective arity of infixes vs prefixes.
We already have hyper prefixes, if that's what you're thinking...

: Tagentially related: why doesn't simple + or + work for what we're
: currently spelling [+] (and which is more specifically spelled
: infix:+)?

Because it would conflict with twigils and such, not to mention
alphabetic infixes.  What would xx mean?

Larry

Re: Amazing Perl 6

[Larry Wall]

On Thu, May 28, 2009 at 02:55:10PM -0400, Mark J. Reed wrote:
: Tagentially related: why doesn't simple + or + work for what we're
: currently spelling [+] (and which is more specifically spelled
: infix:+)?

Oh, and why not +?  Mainly because we have lots of infix operators
containing  and , but none containing [ and ], so we use [...]
to disambiguate infixes already in things like [X]=.  So reusing
square brackets for [+] and [+] is deemed to be a good thing.

But also because foo would mean ($/foo).  [op] is a special
form, so it can get away with parsing it's innards specially,
whereas infix:op is not a special form, insofar as all adverbials
are parsed similarly, and infix:['op'] therefore requires quotes,
which is going the wrong direction when you're looking for a
shortcut.  People will get used to seeing [+] and thinking infix,
whereas + would always be causing double-takes by its similarity
to = and such.

Larry

Re: Amazing Perl 6

[Larry Wall]

On Thu, May 28, 2009 at 03:33:34PM -0400, Mark J. Reed wrote:
: On Thu, May 28, 2009 at 3:13 PM, Larry Wall la...@wall.org wrote:
:  :  I mean, prefix ops can be used in reduce, too, right?
: 
:  I will let you ponder the meaning of reduce a bit more, and the
:  relationship of that to the respective arity of infixes vs prefixes.
: 
: Well, infixes are necessarily binary, but while prefixes tend to be
: slurpy, I was thinking one could also declare a prefix op with a
: finite arity.

Well, sure, but we de-emphasize that arity when parsing anyway for
consistency.  All listop-y operators parse infinite args, even if
none of the candidates can handle them.

And if the prefix is declared slurpy, you'd just call it directly
on the arg list, I'd think, since it already has its own idea
of reduction built in.

: And does [...] only reduce if what's inside is an
: operator?

Yes, only operator, but including user-defined operators (unlike APL).

: How do you do a reduce using a plain old binary subroutine?

For the general form,

[+] @x

is equivalent to

reduce [+], @x

(Which is another good reason to keep the [+] form.)  Note that the
first arg to reduce is simply a noun, so forgetting the  as in:

reduce foo, @x

would be an error.  Unless foo returns something Callable, of course.
But the user probably meant:

reduce foo, @x.

So just as  turns the foo verb into a noun, it turns the [+] verb
into a noun.

Larry

Re: [RFC] CPAN6 requirements analysis

[Larry Wall]

On Fri, May 29, 2009 at 01:04:28AM +0200, Daniel Carrera wrote:
 Hi Alex,

 I hve comments.

 Alex Elsayed wrote:
 While lurking in IRC, I've seen several discussions of what CPAN 6 
 should look like. Honestly, wayland76++'s idea for packaging seems the 
 best to me. Most of the suggestions so far, especially those based on 
 alien, apt, yum, or other existing package managers have a few major 
 problems:

 * Alien only converts between a few package formats
 * All of these suggestions are _heavily_ biased towards binary distributions
 * These suggestions make automatic packaging for new distros extremely  
 difficult, because they require major changes to multiple projects

 * We were mainly looking at Alien as a source of Perl code we could borrow.
 * The point of wayland76's proposal was to use the local package  
 manager. Whether the local package manager is geared toward binary  
 distributions is a separate issue.

I support the notion of distributing binaries because nobody's gonna
want to chew up their phone's battery doing unnecessary compiles.  The
ecology of computing devices is different from ten years ago.

 At first I liked wayland76's proposal, but now I have a new concern:  
 Most package managers are not designed to hold multiple versions of the  
 same package. As indicated in S11, it is important that a computer can  
 hold multiple versions of the same package. I fear that using the native  
 package manager will make this difficult.

Most of these package managers have ways of running an installation
script at the end, so we could perhaps think of this as downloading
an installer rather than the actual software, and the new version
of the installer contains or has access to all the versions it knows
should be installed, and interacts with the official Perl library
installer to install them.

 * Separate the metadata from the package
 * If the metadata is in the source distribution, have CPAN 6 
 extract it, and put it in a separate tree of just metadata
 * This enables simple fetching of the entire /metadata/ tree 
 without the entire /source/ tree

 This is something I agree with. It seems smart to be able to download  
 the metadata before downloading the source tree. This allows dependency  
 resolution, searches, etc.

By the same token, it's smart to keep the metadata close to the thing
it's describing, so if it's easy to extract up front reliably, that's
probably sufficient.

Larry

Re: Illustration of stuff we've been discussing

[Larry Wall]

On Thu, May 28, 2009 at 01:06:18PM -0300, Daniel Ruoso wrote:
: Em Qui, 2009-05-28 às 09:27 -0500, John M. Dlugosz escreveu:
:  Daniel Ruoso daniel-at-ruoso.com |Perl 6| wrote:
:   Em Qui, 2009-05-28 às 00:24 -0500, John M. Dlugosz escreveu:
:   Please see http://www.dlugosz.com/Perl6/web/info-model-1.html
:   and talk to me about it.
:   The illustratino is cool, but it doesn't take into account the
:   possibility of:
:@a[0] := $x;
:  Where in the synopses does it say anything like that is possible?  := is 
:  applied to a _name_.
: 
: I don't recall if it is in the synopsis... but it is a general
: expectation, and, I think, this was discussed in IRC for a long time.
: But certainly is a good time to either put on the spec or drop the
: expectation...

It pretty much has to be that way, if we want to represent lexical
pads with built-in data types.  Our symbol tables are simply hashes,
for instance.  (There may be many pads corresponding to a given
lexical symbol table, however, since all clones of a closure share
a single symbol table but each have their own pad of values.)

Basically, (ignoring STD's definition of name) I view @a[0] as a
name, in the sense of identifying a unique object.  It just happens
to contain navigational elements like a URL.

Of course, if @a is declared to hold only a compact array of native
types, binding a pointer into one of the entries isn't going to fly.

But we're defining the differences between the behavior of $a and @a in
terms of how it desugars in context, so there's no need for the actual
binding to distinguish any extra levels of indirection.  All it needs
to know is where to poke the pointer to the object.  And normally @a
contains a list of poke-able pointers, so @a[0] := $x is fair game.

Larry

Re: Amazing Perl 6

[Larry Wall]

On Thu, May 28, 2009 at 08:06:14PM -0500, John M. Dlugosz wrote:
 Mark J. Reed markjreed-at-gmail.com |Perl 6| wrote:

 So that much makes sense.  But I still think the two different
 meanings of square brackets in operators are going to confuse people.


   

 I agree.  The previously quoted passages in the synopses are confusing,  
 too, since it doesn't make the context clear.

 If you find the shorthand too confusing, write it out as infix+  
 instead.  Perl can do solid software engineering as well as one-liners.

Which, of course, is not as solid as you think, since you left out the :
of the adverbial there... :)

So let's not make the mistake of thinking something longer is always
less confusing or more official.

Larry

Re: Amazing Perl 6

[Larry Wall]

On Wed, May 27, 2009 at 07:56:42PM +0200, Daniel Carrera wrote:
 Here is another idea: Is it possible to declare a circumfix function  
 that calculates the magnitude of a vector?

 $magnitude = |@vector|;

 You know how in math, two vertical bars are a standard notation for  
 magnitude. Oh oh oh... is it possible to define a circumfix function for  
 the dot product?  Something like:

 $dot_product = @vector1,@vector2;

 Is that possible? That would be uber-cool.

The problem with that is the presence of an existing prefix:|
operator.  One could fake it with a postfix:| macro that rewrites
the AST produces by the prefix, except no one implements macros yet.
But circumfix openers have to share longest-token space with prefixes.

You could maybe use broken bar instead, circumfix:¦ ¦.

Larry

Re: Amazing Perl 6

[Larry Wall]

Sorry, only answered half of your question.

On Wed, May 27, 2009 at 07:56:42PM +0200, Daniel Carrera wrote:
 Oh oh oh... is it possible to define a circumfix function for  
 the dot product?  Something like:

 $dot_product = @vector1,@vector2;

 Is that possible? That would be uber-cool.

More likely just use

sub infix:· (@a,@b) { ... }
$dot_product = @vector1 · @vector2;

Or some such.

Larry

Re: Meditations on a Loop

[Larry Wall]

On Wed, May 20, 2009 at 07:55:55PM -0500, John M. Dlugosz wrote:
 If you would be so kind, please take a look at  
 http://www.dlugosz.com/Perl6/web/med-loop.html.  I spent a couple days  
 on this, and besides needing it checked for correctness, found a few  
 issues as well as more food for thought.

It's been legal (for more than two years) to nest a condtional inside
a loop modifier without extra parens:

@array = ($_ if .prime for 1..10);

In fact, the first example in S04 Loop statements is:

@evens = ($_ * 2 if .odd for 0..100);

And since the when modifier counts as a conditional, you can rewrite

grep Dog, @mammals

as

$_ when Dog for @mammals;

So perhaps will see a lot of subtypes used this way: 

subset Odd if Int where { $_ % 2 };
@evens = ($_ * 2 when Odd for 0..*);

Well, those examples are pretty silly.  Anyone with better
examples should feel free to edit the specs.

Larry

Re: r26868 - docs/Perl6/Spec

[Larry Wall]

On Mon, May 18, 2009 at 07:01:27AM +0200, pugs-comm...@feather.perl6.nl wrote:
: Author: jdlugosz
: Date: 2009-05-18 07:01:27 +0200 (Mon, 18 May 2009)
: New Revision: 26868
: 
: Modified:
:docs/Perl6/Spec/S03-operators.pod
: Log:
: Fix one typo, s/know/known/.  Really just low-hanging fruit to test my Commit 
access and procedures therein.  I'm assuming that the VERSION block is updated 
manually before checking in, and all versions are numbered sequentially even if 
a typographic change.

It's fine to change the version on a typo, but no big deal if you
forget, and sometimes I forget on purpose if it's right after the
original checkin that introduced the typo, especially if it's my
own typo.  :)

Larry

Re: is value trait

[Larry Wall]

On Sun, May 17, 2009 at 09:35:50PM +0200, Moritz Lenz wrote:
: Hi,
: 
: t/oo/value_types.t mentions the is value trait, which doesn't appear
: in the spec anywhere. According to the discussion in [1] there was
: speculation about 'is cow' and 'is value', but the former didn't seem to
: enter the spec either.
: 
: So what should I do about that test? Simply delete it?

Yes, unless someone can think of a reason not to.

Larry

Re: Unicode in 'NFG' formation ?

[Larry Wall]

On Mon, May 18, 2009 at 12:37:49PM -0400, Brandon S. Allbery KF8NH wrote:
 On May 18, 2009, at 09:21 , Mark J. Reed wrote:
 If you're doing arithmetic with the code points or scalar values of
 characters, then the specific numbers would seem to matter.  I'm


 I would argue that if you are working with a grapheme cluster  
 (grapheme), arithmetic on individual grapheme values is undefined.   
 What is the meaning of ord(\c[LATIN LETTER T WITH DOT ABOVE, COMBINING  
 DOT BELOW]) + 1?  If you say it increments the base character (a  
 reasonable-looking initial stance), what happens if I add an amount  
 which changes the base character to a combining character?  And what  
 happens if the original grapheme doesn't have a base character?

 In short, I think the only remotely sane result of ord() on a grapheme  
 is an opaque value meaningful to chr() but to very little, if anything, 
 else.  If you want to represent it as an integer, fine, but it should be 
 obscured such that math isn't possible on it.  Conversely, if you want 
 ord() values you can manipulate, you must work at the codepoint level.

Sure, but this is a weak argument, since you can already write complete
ord/chr nonsense at the codepoint level (even in ASCII), and all we're
doing here is making graphemes work more like codepoints in terms of
storage and indexing.  If people abuse it, they have only themselves
to blame for relying on what is essentially an implementation detail.
The whole point of ord is to cheat, so if they get caught cheating,
well, they just have to take their lumps.  In the age of Unicode,
ord and chr are pretty much irrelevant to most normal text processing
anyway except for encoders and decoders, so there's not a great deal
of point in labeling the integers as an opaque type, in my opinion.

As an implementation detail however, it's important to note that
the signed/unsigned distinction gives us a great deal of latitude
in how to store a particular sequence of integers.  Latin-1 will (by
definition) fit in a *uint8, while ASCII plus (no more that 128) NFG
negatives will fit into *int8.  Most European languages will fit into
*int16 with up to 32768 synthetic chars.  Most Asian text still fits
into *uint16 as long as they don't synthesize codepoints.  And we can
always resort to *uint32 and *int32 knowing that the Unicode consortium
isn't going to use the top bit any time in the foreseeable future.
(Unless, of course, they endorse something resembling NFG. :)

Note also that uint8 has nothing to do with UTF-8, and uint16 has
nothing to do with UTF-16.  Surrogate pairs are represented by a single
integer in NFG.  That is, NFG is always abstract codepoints of some
sort without regard to the underlying representation.  In that sense
it's not important that synthetic codepoints are negative, of course.

Larry

Re: Unicode in 'NFG' formation ?

[Larry Wall]

On Mon, May 18, 2009 at 11:11:32AM +0200, Helmut Wollmersdorfer wrote:
 [1] Open questions:

 1) Will graphemes have an unique charname?
e.g. GRAPHEME LATIN SMALL LETTER A WITH DOT BELOW AND DOT ABOVE

Yes, presumably that comes with the normalization part of NFG.
We're not aiming for round-tripping of synthetic codepoints, just
as NFC doesn't do round-tripping of sequences that have precomposed
codepoints.  We're really just extending the NFC notion a bit further
to encompass temporary precomposed codepoints.

 2) Can I use Unicode property matching safely with graphemes?
If yes, who or what maintains the necessary tables?

Good question.  My assumption is that adding marks to a character
doesn't change its fundamental nature.  What needs to be provided
other pass-through to the base character's properties?

 3) Details of 'life-time', round-trip.

Which is a very interesting topic, with connections to type theory,
scope/domain management, and security issues (such as the possibility
of a DoS attack on the translation tables).

 4) Should the definition of graphemes conform to Unicode Standard Annex  
 #29 'grapheme clusters'? Wich level - legacy, extended or tailored?

No opinion, other than that we're aiming for the most modern
formulation that doesn't implicitly cede declarational control to
something out of the control of Perl 6 declarations.  (See locales for
an example of something Perl 6 ignores in the absence of an explicit
declaration to pay attention to them.)  So just guessing from the
names without reading the Annex in question, not legacy, but probably
extended, with explicitly tailoring allowed by declaration.  (Unless
extended has some dire performance or policy consequences that would
be contraindicative...)

So as long as we stay inside these fundamental Perl 6 design
principles, feel free to whack on the specs.

Larry

Re: Unicode in 'NFG' formation ?

[Larry Wall]

On Mon, May 18, 2009 at 02:16:17PM -0400, Mark J. Reed wrote:
: Surrogates are just weird, since they have assigned code points even
: though they're purely an encoding mechanism.  As such, they straddle
: the line between abstract characters and an encoding form. I assume
: that if text comes in as UTF-16, the surrogates will disappear as far
: as character-level P6 code is concerned.

I devoutly hope so.  UTF-8 is much cleaner than UTF-16 in this regard.
(And it's why I qualified my code point with abstract earlier, to
mean the UTF-8 interpretion rather than the UTF-16 interpretation.)

: So is there any way for P6
: to manipulate surrogates as characters?  Maybe an adverb or trait?
: Or does one have to descend to the bytewise layer for that?  (As you
: said, that *normally* shouldn't be necessary outside encoding and
: decoding, where you need to do things bytewise anyway; just trying to
: cover all the bases...)

Buf16 should work for raw UTF-16 just fine.  That's one of the main
reasons we have buffers in sizes other than 8, after all.

Larry

Re: each() comprehension

[Larry Wall]

On Sun, May 17, 2009 at 07:41:45PM +0200, Moritz Lenz wrote:
: Hi,
: 
: (sorry for yet another p6l email mentioning junctions; if they annoy you
: just ignore this mail :-)
: 
: while reviewing some tests I found the each() comprehension in S02
: that evaded my attention so far.
: 
: Do we really want to keep such a rather obscure syntactic
: transformation? I find an explicit grep much more readable; if we want
: it to work in a more general case, it might become some kind of junction
: that, on autothreading, keeps a mapping between the original item and
: the new value, and on collapse returns all items for which the new value
: is true. Something along these lines:
: 
:  g(f(each(1..3))9
: becomes
:  g(each(1 = f(1), 2 = f(2), 3 = f(3)))
: becomes
:  each(1 = g(f(1)), 2 = g(f(2)), 3 = (g(f(3)))
: and on collapse returns
:  1..3.grep:{g(f($_))};
: 
: IMHO this would DWIM more in arbitrary code than the special syntactic
: form envisioned

Feel free either to whack it out and/or install each() as a conjectural
mapping junction that may be deferred till post-6.0.0.

: Also this part of S02 is rather obscure, IMHO:
: 
:   In particular,
: 
: @result = each(@x) ~~ {...};
: 
:  is equivalent to
: 
: @result = @x.grep:{...};
: 
: Should it be @result = @x.grep:{ $_ ~~ ... } instead? Otherwise
: 
: 'each(@x) ~~ 1..3' would be transformed into '@x.grep:{1..3}', which
: would return the full list. (Or do adverbial blocks some magic smart
: matching that I'm not aware of?)

The grep itself does the smart matching:

@dogs = grep Dog, @mammals;

Larry

Re: Unicode in 'NFG' formation ?

[Larry Wall]

On Mon, May 18, 2009 at 07:59:31PM -0500, John M. Dlugosz wrote:
 No, a few million code points in the Unicode standard can produce an  
 arbitrary number of unique grapheme clusters, since you can apply as  
 many modifiers as you like to each different base character.  If you  
 allow multiples, the total is unbounded.

 A small program, which ought to go into the test suite g, can generate  
 4G distinct grapheme clusters, one at a time. 

That precise behavior is what I was characterizing as a DoS attack.  :)

So in my head it falls into the Doctor-it-hurts-when-I-do-this category.

Larry

Re: Contextual Variables

[Larry Wall]

On Fri, May 15, 2009 at 08:04:49PM -0500, John M. Dlugosz wrote:
 Larry Wall larry-at-wall.org |Perl 6| wrote:
 On Fri, May 15, 2009 at 07:16:45PM -0500, John M. Dlugosz wrote:
   
 Reading through S02, I see that contextual variables has changed in 
 the  last year.  It appears that contextual and global variables have 
 been  unified.  So, the + twigil is no more?

 I assume the point is that any supposed global can be overridden in 
  dynamic context, rather than having to know which you planned to and 
  which you didn't.  Normal code should use $*x, not $GLOBAL::x or  
 whatever.

 Is that it, or is there more I need to be filled in on?
 

 That's it, you've nailed it in one.  Though perhaps we could mention
 here that part of the motivation is to push context info down the
 dynamic stack to the point where we minimize shared state between
 threads.  And also, knowing whether a particular context var is
 rw or not means we know whether we can just make a copy into our
 current thread with value semantics, or we have to manage a lock
 around the shared container.  Well, that's the hope...

 Larry

   
 Hmm, so being read-only implies it won't change and can be cached  
 locally, as opposed to YOU can't change it along this access path.   
 Don't we have separate readonly and rw variables aliasing the same  
 underlying value now?  I think you're confusing const and volatile.

Oh, undoubtedly... :)

But at least we only have to manage changes from the lexical alias,
and that might be amenable to analysis.  Or maybe we can enhance
the declaration syntax to something approximating single-assignment
semantics, so the lexical alias is also not allowed to modify it.
There are various ways to push it; I consider the current notation
to be an approximation of what we'll end up with.

But regardless of the details, it's still the case that minimizing
the scope of contextuals will *tend* to prevent accidental thread
interaction, and trying to get rid of accidental interactions in the
name of parallelizability is one of the strong reasons for many of
the design decisions in Perl 6.  Even if we've flubbed it in spots. :)

Certainly, we've at least got the design to the point where if
you recontextualize within a thread, you don't have to look outside
the thread for something more global, and that's something...

Larry

Re: Call for review: traits, lift

[Larry Wall]

On Sun, May 03, 2009 at 08:20:17PM +0200, Moritz Lenz wrote:
: If I understood the specs correctly, variables can be lifted, so you can
: write
: 
: sub f() {lift $a + $b};
: {
: my $a is context = 3;
: my $b is context = 4;
: say f();
: }
: 
: Is that correct?

I think so.

: And if yes, do these variables need to be context variables?

Excellent question.  I think the conservative thing to say is yes,
but it's possible that the lift mechanism can't easily distinguish,
unless it happens to use the same lookup that context vars use.
But if we don't require the context declaration, it basically gives
any called routine carte blanche on modifying your variables, which
is probably a bad thing.

So leave it in for now, I guess.

Larry

Re: Interpolation of \c[$charname]?

[Larry Wall]

On Mon, Apr 27, 2009 at 10:44:54AM +0200, Helmut Wollmersdorfer wrote:
 It's not explicitly specified, if a something like

   my $charname = 'SPACE';
   my $string   = \c[$charname];

 should interpolate or not.

 I assume 'not'. Right?

I also assume 'not', unless someone can present a valid use case
for delaying the \c till inside the interpolation.  I don't think
the definition of Unicode changes so rapidly that we need to assume
dynamic definitions for character names.  :)

In any case, one can always interpolate a closure to force late
evaluation of a symbolic representation via any function of one's
choosing.  This doesn't seem like something that will occur
frequently enough to need rehuffmanization.

Larry

Re: .to_charnames() and .from_charnames()

[Larry Wall]

On Mon, Apr 27, 2009 at 12:02:56PM +0200, Helmut Wollmersdorfer wrote:
 [1] It would be possible to compose character names for the life-time of  
 the process, but these names would need to be checked for uniqueness  
 (performance problem).

With our grapheme approach we will certainly compose unique graphemes
to be temporarily representable with single (negative) integers, so the
table of these can easily map the integer to a temporarily composed name.
Going the other direction is just a hash to integer, which should scale
O(1)ishly, albeit with a larger constant.  Currently parrot plans to
implement these tables per-string rather than per-process, but the idea
is the same.

In any event, correctness before optimization applies.  If we can
make graphemes work (more or less) the way users expect rather than
the way computers expect, we will have achieved a strong bit of
disruptive technology, which alone would make Perl 6 a better choice
for text processing than many other current offerings.  And as
Todd Proebsting has pointed out, in order to produce a disruptive
technology, you pretty much have to plan to do something *worse*
rather than better, so I'm not so worried about the performance
at this point.

Larry

Re: Whitespace in \c[...], \x[...], etc.

[Larry Wall]

On Mon, Apr 27, 2009 at 11:04:03AM +0200, Helmut Wollmersdorfer wrote:
 It's not explicitly specified, if insignificant whitespace is allowed in  
 \c[...], \x[...], etc.

 Std.pm allows e.g.

   \x[   41  ,   42  ,  43  ]

 For convenience - especially with long charnames - it should be possible  
 to write

 \c[
 SPACE, # blafasel
 LATIN SMALL LETTER A,  # some comment
 COMBINING DOT BELOW,   # thisandthat
 ]

Does anyone know offhand whether the Unicode Consortium has an explicit
policy against use of punctuation in a charname?  So far they only
seem to use hyphen and parens, but I wonder to what extent we can
depend on that...

In any case, STD doesn't currently try to check the string in \c[...]
for correctness.  It just scans for the closing bracket.  We will
certainly need to refine this, and the suggested approach is certainly
a possible outcome, if we decide it's sufficiently unambiguous.

Larry

Re: S08 Draft questions (Captures and Signatures)

[Larry Wall]

On Tue, Mar 31, 2009 at 10:54:33PM -0700, Jon Lang wrote:
: * Why are pointy blocks forbidden from enclosing their signatures in
: parentheses, or from using the :( ... ) notation?  Is this a
: holdover from the early days, when parentheses denoted a list?  Or is
: there still a good reason not to allow such notation?

Because subsignatures within a signature match a single argument
with that subsignature, on the assumption that the argument is something
resembling a capture.

Larry

Re: simultaneous conditions in junctions

[Larry Wall]

On Wed, Apr 01, 2009 at 08:40:12AM -0700, Dave Whipp wrote:
 That said, the semantics of a chained relop really should work correctly  
 for this. If you only reference a junction once in an expression, then  
 it should behave as such: {abc} !=== {ab  bc}.

Yes, that is the intent.  I consider a chained 1  $x  2 to be a
single function from the standpoint of autothreading, something like

chained(1, infix:«», $x, infix:«», 2);

and the semantics would fall out of that naturally, more or less.

Something similar could also work for the blocks of conditionals
if we were to treat the conditional as a function that autothreads
consistently over both its condition and its blocks; this implies the
junction autothreader must be given enough access to the scope of the
block in question to temporarily override the value of $x within the
block to its autothreaded value somehow.  The tricky bit is that
autothreading is setting up extra scopes around variant captures
without explicit blocks.  That alone is reason enough to keep
the mechanism all internal.

If we do give access to universe of values the junction is interested
in, it should probably just be via a coercion to Set.  There would have
to be some caveats about using that as the universe of values, however,
since none() junctions define a set outside of the eigenstates.
For that reason I'd still prefer people to track their universe of
values outside the junctions rather than rely on junctions for that.

And of course, a Set in list context is its members, so any(%set) isn't
a problem going the other direction.

Larry

Re: Logo considerations - 3 logos needed

[Larry Wall]

On Wed, Mar 25, 2009 at 08:54:34AM -0400, Guy Hulbert wrote:
: On Wed, 2009-25-03 at 22:45 +1100, Timothy S. Nelson wrote:
:  Additionally, while you recommended Camelia for Rakudo, my 
:  understanding was that Larry was recommending it for Perl 6 rather than 
:  Rakudo.

This is correct.  Patrick has the final say on Rakudo's logo.

: I think he was offering it as an example and a suggestion.  The perl6
: community might favor it out of respect for Larry but I think he went
: out of his way to make it clear that it's the kind of thing he would
: like.

Yes, I went out of my way to indicate that my mind was still open
(a little).  However, if you will allow an old geezer to be a wee bit
testy, I would also like to make it clear that I'm a just a little
tired of these rounds; more importantly, that I've been mulling
over this particular issue for many years.  I didn't just come up
with that list of requirements off the cuff.  I'm old enough to have
lots of stuff on my cuff as well.

Also, it's probably mere hubris, but I already consider myself to be a
professional designer.  I know how to take into account the various
factors that a professional designer would take into account when
designing yet another highly original logo that somehow ends up looking
just like every other logo out there.  You'll notice that sterility
is not on my list of requirements.  It was a deliberate omission.

So let me summarize the requirements into a meta-requirement:

The new logo must make Larry at least as happy as Camelia does.

That is the extent to which my mind is still open...  :-)

Larry