Re: Regex interpolation

[mark . a . biggar]

Use <{...}>. as the string returned is reinterpreted as a regex, if it consists 
of the single quoted string then it's a literal, but you must include the 
single quotes in the result returned.  E.g., 
<{ my $x = funct($a, $b, $c); "'$x'";}>

Mark Biggar
--
m...@biggar.org
mark.a.big...@comcast.net
mbig...@paypal.com

- Original Message -
From: Mark J. Reed 
To: perl6-langu...@perl.org
Sent: Mon, 29 Mar 2010 14:27:00 + (UTC)
Subject: Regex interpolation

Is there not a way to run arbitrary code and interpolate the result as
a literal string (instead of a Regex)?

 I assume that {...} is intended to be where you hook in
semantics/actions mid-parse, but it seems a bit counter-intuitive that
the same syntax interpolates in double-quote context but not regexes.

Question Inspired by this Rakudo patch:
On Monday, March 29, 2010, Bruce Keeler  wrote:
> # New Ticket Created by  Bruce Keeler
> # Please include the string:  [perl #73862]
> # in the subject line of all future correspondence about this issue.
> # 
>
>
> The attached patch adds support for variable and block-result
> interpolation into regexes.
>
> It does so by means of a new PAST::Regex node pasttype 'interpolator'.
> The following syntaxes are supported by this patch:
>
> / $var /  -- Interpolates as literal string, unless it's a Regex object
> / @foo / -- Interpolated as ||-style alternations of literal strings
> or Regex objects
> / <$var> / -- compiled into a Regex (unless it's already one), then
> interpolated
> / <@foo> / -- A list of ||-style alternations of things to be
> compiled into Regexes (unless they already are)
> / <{ ... }> / -- Result of capture is interpolated as a Regex,
> compiling if necessary
> / / -- Unchanged
> / { ... } / -- Capture is merely executed, but not interpolated.
> (Unchanged)
>

-- 
Mark J. Reed 

Re: Temporal changes

[mark . a . biggar]

Instant 
Moment 
Point 
PointInTime 
Timestamp 
Event 
Jiffy 
Time 

Mark 
Biggar%0D%0Amark%40biggar.org%0D%0Amark.a.biggar%40comcast.net%0D%0Ambiggar%40paypal.com
 

Re: Temporal revisited

[mark . a . biggar]

- Original Message - 
From: "Dave Rolsky"  
>That will make it clear 
>that there's no way to calculate "one month from today" >using the core API. 

"one month from today" is ill-defined regardless what time system you are 
using. There are dates from which "one month from today" can be reasonably 
argued to be any of 5 different days. This is why bank contracts are always to 
be written to say 30, 60 or 90 days not 1, 2 or 3 months from now. 
-- 
Mark 
Biggar%0D%0Amark%40biggar.org%0D%0Amark.a.biggar%40comcast.net%0D%0Ambiggar%40paypal.com
 

Re: What does a Pair numify to?

[mark . a . biggar]

-- Original message --
From: Larry Wall 
> On Thu, Dec 11, 2008 at 02:24:54PM +0100, TSa wrote:
> > My idea is to let a pair numify to whatever the value numifies to.
> > Same thing with stringification. In general I think that a pair should
> > hide its key as far as possible if used as non-pair.
> 
> This makes sense to me, but I'd like to see any use cases to the
> contrary, if anyone can think of one.

The only use case I can think of is sorting a list of pairs;
 should it default to sort by key or value?

--
Mark Biggar
m...@biggar.org
mark.a.big...@comcast.net
mbig...@paypal.com

Re: Support for ensuring invariants from one loop iteration to the next?

[mark . a . biggar]

oops make that 

last if !someCondition();

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: [EMAIL PROTECTED]
> loop {
> doSomething();
> next if someCondition();
> doSomethingElse();
> }
> 
> --
> Mark Biggar
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> 
>  -- Original message --
> From: "Mark J. Reed" <[EMAIL PROTECTED]>
> > OK, so let's look at the general problem.  The structure is this:
> > 
> > doSomething();
> > while (someCondition())
> > {
> > doSomethingElse();
> > doSomething();
> > }
> > 
> > ...and you want to factor out the doSomething() call so that it only
> > has to be specified once.
> > 
> > Is that correct, Aristotle?
> > 
> > The "gotcha" is that the first doSomething() is unconditional, while
> > the first doSomethingElse() should only happen if the loop condition
> > is met (which means just moving the test to the end of the block
> > doesn't solve the problem).
> > 
> > IFF the doSomething() can be reasonably combined with the conditional
> > test, then Bruce's solution works, but that won't necessarily be the
> > case in general.  Overall, the goal is to ensure that by the end of
> > the loop the program is in the state of having just called
> > doSomething(), whether the loop runs or not - while also ensuring that
> > the program is in that state at the top of each loop iteration.
> > 
> > It does seem like a closure trait sort of thing, but I don't think
> > it's currently provided by the p6 spec.
> 

Re: Support for ensuring invariants from one loop iteration to the next?

[mark . a . biggar]

loop {
doSomething();
next if someCondition();
doSomethingElse();
}

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: "Mark J. Reed" <[EMAIL PROTECTED]>
> OK, so let's look at the general problem.  The structure is this:
> 
> doSomething();
> while (someCondition())
> {
> doSomethingElse();
> doSomething();
> }
> 
> ...and you want to factor out the doSomething() call so that it only
> has to be specified once.
> 
> Is that correct, Aristotle?
> 
> The "gotcha" is that the first doSomething() is unconditional, while
> the first doSomethingElse() should only happen if the loop condition
> is met (which means just moving the test to the end of the block
> doesn't solve the problem).
> 
> IFF the doSomething() can be reasonably combined with the conditional
> test, then Bruce's solution works, but that won't necessarily be the
> case in general.  Overall, the goal is to ensure that by the end of
> the loop the program is in the state of having just called
> doSomething(), whether the loop runs or not - while also ensuring that
> the program is in that state at the top of each loop iteration.
> 
> It does seem like a closure trait sort of thing, but I don't think
> it's currently provided by the p6 spec.

Re: how to write literals of some Perl 6 types?

[mark . a . biggar]

The literals for Bit are just 0 and 1.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: "Carl Mäsak" <[EMAIL PROTECTED]>
> Darren (>):
> >  Bit
> >  Blob
> >  Set
> >  Bag
> >  Mapping
> >
> > How does one write anonymous value literals of those types?  And I mean
> > directly, not by writing a literal of some other type and using a conversion
> > function to derive the above?
> 
> Why is the latter method insufficient for your needs?
> 
> // Carl

Re: new article, "A Romp Through Infinity"

[mark . a . biggar]

Supporting multiple levels of infinities, transfinite numbers or even Surreal 
Numbers should be considered in the same category of features as returning 
multiple answers from complex trig functions.

They're an interesting thing to discuss and experiment with but shouldn't 
distract form getting Perl 6 out the door.  Let's just make sure we're handling 
inf and  -inf right and leave all that other stuff until later.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Complex planes

[mark . a . biggar]

Let's worry about getting principal values, branch cuts and handling signed 
zeros correct before dealing with the interaction of junctions and multi-valued 
complex functions.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Rakudo test miscellanea

[mark . a . biggar]

Most financial institutions don't use float, rational or fixed point, they just 
keep integer pennies.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: Larry Wall <[EMAIL PROTECTED]>

> Would any financial institution care to comment?
> 
> Larry

Re: Where is "Manhattan Dispatch" discussion?

[Mark A. Biggar]

Carl Mäsak wrote:

John (>):

I'm still in the dark... I find an positions for "manhattan distance" but no
definition of what that is.  I did find the alternative pod page earlier.


I don't have a whole answer for you, but a part that may help. What is
generally meant by "Manhattan distance" is so-called L1 distance, i.e.
Pythagoras' distance summation formula but without all the squaring
and surding.

 

I imagine the concept is applied to parameter types in the discussion
in question.


To do multi method dispatch, you want to select the method that best 
matches the parameters in the call. One way to do that is to define a 
measure for distances between types and they use the method that's at 
the minimum distance.  One simple measure is that a type is distance 0 
from itself and distance 1 from it's immediate super-types, distance 2 
from the immediate super-types of it's immediate super-types, etc. When 
dispatching over a single parameter picking the method at the minimum 
distance is the usual most specific type match. But when you want to do 
multi-method dispatch, you need some rule to combine the various 
distances of the individual parameters into a single measure value, then 
pick the method at the minimum distance by that combined measure. 
"Manhattan Distance" or "Taxicab Distance" is the rule that the combined 
distance is just the simple unweighted sum of the individual parameter 
distances. The is named after the fact that a taxi must follow the 
streets and to go 3 block north and 4 blocks west it must travel 7 
blocks not the 5 blocks of the euclidean distance.


BTW, if you want to do euclidean distance comparisons you don't need to 
do any square roots. Square root is monotonic, so order relations 
between the sums of squares values is the the same whether you take 
square roots or not.



--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: First look: Advanced Polymorphism whitepaper

[mark . a . biggar]

 -- Original message --
From: TSa <[EMAIL PROTECTED]>
> HaloO,
> 
> John M. Dlugosz wrote:
> >> Maybe we already have this--see "emulates" in S11.
> > Works for me.
> 
> For me, too. But note that we should keep does the ultimate
> type checker that first checks the declared presence of a role,
> then falls back to a declared class inheritance and then falls
> back to a declared emulation. What else should be in this check
> sequence?

Do we need to consider boxed vs un-boxed,  E.G. Int vs int?

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: First look: Advanced Polymorphism whitepaper

[mark . a . biggar]

 -- Original message --
From: "John M. Dlugosz" <[EMAIL PROTECTED]>
> Jon Lang dataweaver-at-gmail.com |Perl 6| wrote:
> > On Wed, Apr 30, 2008 at 9:58 PM, Brandon S. Allbery KF8NH
> > <[EMAIL PROTECTED]> wrote:
> >   
> >>  On May 1, 2008, at 0:53 , chromatic wrote:
> >>
> >>
> >> 
> >>> correctness sense.  Sadly, both trees and dogs bark.)
> >>>
> >>>   
> >>  Hm, no.  One's a noun, the other's a verb.  Given the linguistic
> >> orientation of Perl6, it seems a bit strange that the syntax for both is 
> >> the
> >> same:  while accessors and mutators are *implemented* as verbs, they should
> >> *look* like nouns.
> >> 
> >
> > In defense of chromatic's point, both people and syrup run.
> >
> >   
> Sometimes you don't even know the correct part of speech without a 
> backtracking parser or infinite lookahead in English.
> 
> "The green can
> 
> (continues...)
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> be watered after it has been cut."

And sometime you can't even do it syntactically:

"Time flies like an arrow."
"Fruit flies like a banana."
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: static types, checking, conversions

[mark . a . biggar]

You should look at Common Lisp.  it's definition of "optional typing" is that 
if you take a correct program and remove all the type declarations, then it 
still works correctly, although it may be significantly less efficient.  Larry 
and i have discussed this and that was his goai in Perl.  Now Perl doesn't 
quite meet that because of inferred method dispatch on .new().  you need to 
change

my Dog $spot = .new();

to

my $Spot = Dog.new();

when you remove the declaration.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: TSa <[EMAIL PROTECTED]>
> HaloO,
> 
> Mark J. Reed wrote:
> > It would behoove @Larry to examine the optional type constraints
> > system proposed for Javascript:TNG (see link from firefox.com
> > developers page).  I therefore assume that they have done so, but
> > others would benefit by doing likewise. :)
> 
> Do I get that right: you imply that I didn't do my homework?
> Note that I don't feel offended by that.
> 
> I found two dissertations and a couple of papers about typing
> JavaScript. The quintessential is that optional typing is
> defined as having *no* impact on the dynamic behavior of the
> program. In that respect type annotations are like comments.
> I doubt that this is the case with Perl 6, or is it?
> 
> 
> Regards, TSa.
> -- 
> 
> The Angel of Geometry and the Devil of Algebra fight for the soul
> of any mathematical being.   -- Attributed to Hermann Weyl

Re: cross operator and empty list

[Mark A. Biggar]

Miller, Hugh wrote:
From: Moritz Lenz [mailto:[EMAIL PROTECTED] 
[EMAIL PROTECTED] wrote:
Technically the Cartesian cross operator doesn't have an 

identity value.
It has.
The set which contains only the emty set, or in perl terms ([]);
Or am I missing something?

Should be a (any) 1 point set for the identity.
How about considering models from category theory, rather than set
theory ? Seems much more fruitful for computer issues than set theory.


No an identity would be a set E such that for any set A: A x E = A, but 
no such set exists.  A singleton set get close, but the result is only 
isomorphic (there is a natural bijection) not equal. Even in category 
theory you only get isomorphism.



--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: cross operator and empty list

[mark . a . biggar]

Technically the Cartesian cross operator doesn't have an identity value.  There 
is no set X such that 
A x X = A.  Now any singleton set gives a result that is naturally isomorphic 
to the original set, I.e, there is a obvious bijection between the two sets, 
but they are not equal sets.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: Darren Duncan <[EMAIL PROTECTED]>
> Adriano, I think perhaps what Tsa is trying to get at is the identity value 
> for the X operator, and I believe I know what it is.
> 
> In the relational model of data, both the version of the model where tuples 
> have unordered named attributes/elements (which I prefer), and the version 
> where tuples have ordered attributes/elements (which Perl 6 seems to be 
> using in its X operator), the relational cross product operator is 
> analogous to numeric multiplication or logical 'and' in its properties 
> (except that the ordered version isn't commutative).
> 
> With respect to relational join being like multiplication, the special 
> values 0 and 1 are represented by the nilary (zero attribute) relation with 
> either 0 or 1 tuples respectively, which in common Perl array-of-hash (or 
> array-of-array) notation for rowsets is
> 
>[]
> 
> and
> 
>[ {} ] or [ [] ]
> 
> respectively; I'll call them R0 and R1 for now.  Joining any relation R 
> with R0 gives R0 (or alternately a relation with the same attributes as R 
> but zero tuples; its zero tuples either way), and joining any relation R 
> with R1 gives R.
> 
> So R1 is the identity value for cross product, meaning the identity value 
> for X, in Perl 6 would be a one-element array|seq whose element is the 
> empty array|seq.  That is,
> 
>[X] ()
> 
> equals this:
> 
>( () )
> 
> Larry et al, on a related note, the list of identity values for reduce in 
> S03 should be updated to account for this; [X] wasn't on the list last I 
> looked.
> 
> -- Darren Duncan

Re: cross operator and empty list

[mark . a . biggar]

Cartesain product with the empty set is empty.  A x B is the set of all pairs 
(a,b) where a is in A and b is in B. If either is empty then there are no such 
pairs and the result is also empty.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: TSa <[EMAIL PROTECTED]>
> HaloO,
> 
> why is (1,2,3) X () defined to be the empty list
> and not (1,2,3) as is the case with the cartesian
> product of sets which X basically is with preserved
> order.
> 
> Regards, TSa.
> -- 
> 
> The Angel of Geometry and the Devil of Algebra fight for the soul
> of any mathematical being.   -- Attributed to Hermann Weyl

Re: Query re: duction and precedence.

[Mark A. Biggar]

Mark J. Reed wrote:

I'm a believer in generalizing where possible, modulo the principles
of KISS and YAGNI. The latter essentially means "at least make it
general enough that you can extend it later without major retooling if
it turns out YNIAA.".  It's pretty surprising what can turn out to be
useful, so I've never been swayed by arguments from "what is it good
for?"...

Something I'm wondering, though, realistically how often would one actually
be reducing on an operator that is not associative?  What practical use is
there for [-] (3,4,5) for example?


The reduce meta-operator over - in APL gives alternating sum, similarly 
alternating quotient for /, which only works if you right associate 
things.


[-] 1,2,3,4,5,6 => 1-2+3-4+5-6 # pseudo-apl

[/] 1,2,3,4,5,6 => (1*3*5)/(2*4*6) #pseudo-apl

note that would break the perl 6 simple rule that [-] 1,2,3 => 1-2-3, 
but gives something much more useful.  There currently is no easy way to 
do alternating sum/quotient in perl6.


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Integerizing a rat involves truncating its tail

[mark . a . biggar]

I think nearest makes more sense.  People will be really surprised when 
/1 turns into 0.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: TSa <[EMAIL PROTECTED]>
> HaloO,
> 
> just re-reading S03 I saw that it defines the Rat to Int
> conversion as truncation. Why not floor semantics like in %?
> Actually I would recommend floor semantics whenever an integer
> is coerced. With the sole exception of Num propably using
> rounding.
> 
> Regards, TSa.
> -- 
> 
> The Angel of Geometry and the Devil of Algebra fight for the soul
> of any mathematical being.   -- Attributed to Hermann Weyl

Re: Floating point comparisons

[mark . a . biggar]

if the values you are storing in floats are known to be integers of a size less 
then the mantissa for he floating type then exact comparisons work just as 
expected.  Storing 10 digit phone numbers as floats is an example of this.  
There must be some way to access exact comparisons in the language.  Least 
surprise would argue that == should be that operator.  if you want to provide a 
fuzzy comparison as a separate operator that fine.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: Doug McNutt <[EMAIL PROTECTED]>
> At 18:32 + 7/31/07, peter baylies wrote:
> >On 7/31/07, Paul Cochrane <[EMAIL PROTECTED]> wrote:
> > > return (fabs(x - y) <= fabs(x + y)*EPSILON) ? 1 : 0;
> >
> >That may not be a bad idea, but I think there's a bug in that code --
> >take, for example, the case where x and y both equal approximately a
> >million (or more).
> >
> >Maybe you wanted this instead:
> >
> > return (fabs(x - y) <= EPSILON) ? 1 : 0;
> 
> This physicist thinks Paul is right here. His formula is equivalent to 
> allowing 
> larger variations when the numbers are large. That's a logarithmic approach 
> that 
> makes sense for very large or very small numbers. Numbers can be considered 
> equal if they vary by less than some small fraction of their sum.
> 
> Actually it's pretty much the same as masking off a few bits at the right end 
> of 
> the mantissa in a pair IEEE floats. That works if the items being are results 
> of 
> calculations that are known to be normalized, and they're not in the 
> super-large 
> range where the mantissa is less than 1/2, and we're not dealing with NAN's. 
> . .
> 
> There are reasons for checking for complete exactness though. Telephone 
> numbers 
> are best treated as strings but a lot of less mathematical IT folks allow a 
> type-less compiler to assign them to 10 digit floats. Nearly correct might 
> not 
> be good enough for that especially if an extension is added after a period. 
> Testing for exactly zero should be possible. And minus zero?  That reminds me 
> too much of ones complement arithmetic on a Control Data 3800.
> -- 
> 
> --> From the U S of A, the only socialist country that refuses to admit it. 
> <--

Re: Generalizing ?? !!

[mark . a . biggar]

Besides ?? !! with out an else part is just &&.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: Damian Conway <[EMAIL PROTECTED]>
> Mark J. Reed concluded:
> 
> > So I prefer keeping a single construct, but perhaps the else-part
> > could be optional?
> 
> I hope not. The mandatory else-part is one of the most valuable features of 
> the ternary operator. It helps ensure that variables initialized with a 
> cascaded ternary actually do get initialized:
> 
>   $action =  $name eq 'Kirk'  ??  'fight'
>   !! $name eq 'Spock' ??  'think'
>   !! $shirt eq 'red'  ??  'die'
>   !!  'stand';
> 
> The required-ness of the else-part makes cascaded ternaries a safer, more 
> robust choice than if-elsif-else chains in many cases.
> 
> Damian

Re: Y not

[Mark A. Biggar]

Thomas Wittek wrote:

Damian Conway schrieb:

If the very much more readable 'zip' and 'minmax' are
to be replaced with 'ZZ' and 'MM', then I think that's a serious step
backwards in usability.


Fully agree here and I think that there are still even more places,
where the usability could be improved:
Say more words/letters, less symbols/special characters.
Especially special characters (shift + num: [EMAIL PROTECTED]&*...) are harder 
to
type (I think I can type a 5-char word a lot faster than shift-5 = % -
additionally the shift-wrench disturbs the typing flow) and above all
harder to read/intuitively understand/learn/remeber than plaintext keywords.

Of course there will always be a trade-off and special characters are
the most usable choice in many cases. But I also think that in many
other cases "words" will be more usable.

As the usability of a tool greatly influences it's acceptance and usage,
this is a point, where we really should think about.


It's madness, MADNESS I tell you!

Beware: this way leads to PERLBOL! :-)

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: named sub-expressions, n-ary functions, things and stuff

[mark . a . biggar]

And you may be forced to deal with NaN and Inf values if you are storing raw 
binary float values as they are built into the bit patterns.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: "Mark J. Reed" <[EMAIL PROTECTED]>
> On 11/13/06, Darren Duncan <[EMAIL PROTECTED]> wrote:
> > - There are no Undef or NaN etc values or variables.
> 
> A RDBMS language with no "null" would seem to be problematic..
> although i guess you could just use 1-tuples where the empty tuple is
> treated as null.
> 
> -- 
> Mark J. Reed <[EMAIL PROTECTED]>

Re: Edge case: incongruent roles

[mark . a . biggar]

 -- Original message --
From: "Jonathan Lang" <[EMAIL PROTECTED]>
> Mark Biggar wrote:
> > Jonathan Lang wrote:
> > > They can be:
> > >
> > >   $A > $B if $A.x > $B.x | $A.y > $B.y;
> > >   $A < $B if $A.x < $B.x | $A.y < $B.y;
> >
> > That dosn't work.
> 
> Agreed.  The above was written in haste, and contained a couple of
> fatal syntax errors that I didn't intend.  Try this:
> 
> multi infix:< <= > (Complex $A, Complex $B) {
> $A.x < $B.x || $A.x == $B.x && $A.y <= $B.y
> }
> 
> or
> 
> multi infix:< <= > (Complex $A, Complex $B) {
> $A == $B || pi()/2 < ($A - $B).a <= 3*pi()/2 # if $.a is
> normalized to 0..2*pi()
> }
> 
> This is transitive, reflexive, and anti-symmetric.  The underlying
> rule for <= in English: anywhere to the west, or due south, or equal.

See the following.

http://www.cut-the-knot.org/do_you_know/complex_compare.shtml




--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Edge case: incongruent roles

[mark . a . biggar]

 -- Original message --
From: "Jonathan Lang" <[EMAIL PROTECTED]>
> TSa wrote:
> > Jonathan Lang wrote:
> > > If at all possible, I would expect Complex to compose Num, thus
> > > letting a Complex be used anywhere that a Num is requested.
> >
> > This will not work. The Num type is ordered the Complex type isn't.
> > The operators <, <=, > and >= are not available in Complex.
> 
> They can be:
> 
>   $A > $B if $A.x > $B.x | $A.y > $B.y;
>   $A < $B if $A.x < $B.x | $A.y < $B.y;
> 
> This also allows you to unambiguously order any arbitrary set of
> complex numbers.
> 
> Pipe dream: it would be nice if something similar to the above
> (faulty) code counted as valid Perl 6 logic programming.

That dosn't work.  1+2i < 2+1i then evaluates to (true | false) which is 
ambigious and can't be use to sort.  Num."<=" as usually defined has certain 
properties: it's transitive: a<= && b<=c --> a <= c, it's reflexive: a<=a, it's 
anti-symetric: a<=b && b<=a --> a==b and it's total: one of a<=b or b<=a must 
hold.  a

Re: signature subtyping and role merging

[mark . a . biggar]

This is the "dog does bark" vs "tree does bark" problem.  You can assume that 
the two methods "blahh" have naything semantically to do with each other at 
all.  Unless ther is a specif annotation from the programmer creating the Role 
union that they are the same you must assume that they are different.  
Therefore your proposed signiture merge is nonsense in the general case.  Even 
if the signature are the same the only case where you are justified in assuming 
that are the "same" method is if both composed Roles inherited the method from 
a common ancestor and even then you must solve the diamond inheritence problem.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: TSa <[EMAIL PROTECTED]>
> HaloO,
> 
> with my idea of deriving a type lattice from all role definitions
> the problem of subtyping signatures arises. Please help me to think
> this through. Consider
> 
> role Foo
> {
> sub blahh(Int, Int) {...}
> }
> role Bar
> {
> sub blahh(Str) {...}
> }
> role Baz does Foo does Bar # Foo|Bar lub
> {
># sub blahh(Int&Str,Int?) {...}
> }
> 
> The role Baz has to be the lub (least upper bound) of Foo and Bar.
> That is the join of two nodes in the lattice. This means first of
> all the sub blahh has to be present. And its signature has to be
> in a subtype relation <: to :(Int,Int) and :(Str). Note that
> Int <: Int&Str and Int|Str <: Int. The normal contravariant subtyping
> rules for functions gives
> 
>  +- :> ---+
>  ||
> :(Int&Str,Int?) <: :(Int,Int)
>|  |
>+--- :> ---+
> and
> 
>  +- :> ---+
>  ||
> :(Int&Str,Int?) <: :(Str)
> 
> I hope you see the contravariance :)
> 
> The question mark shall indicate an optional parameter that
> allows the subtype to be applicable in both call sites that
> have one or two arguments.
> 
> The choice of glb for the first parameter makes the sub in Baz
> require the implementor to use the  supertype of Int and Str
> which in turn allows the substitution of Int and Str arguments
> which are subtypes---that is types with a larger interface.
> 
> Going the other way in the type lattice the meet Foo&Bar of the
> two roles Foo and Bar is needed. But here the trick with the
> optional parameter doesn't work and it is impossible to reconcile
> the two signatures. This could simply mean to drop sub blahh from
> the interface. But is there a better way? Perhaps introducing a
> multi?
> 
> Apart from the arity problem the lub Int|Str works for the first
> parameter:
> 
>  +- <: ---+
>  ||
> :(Int|Str,Int)  :> :(Int,Int)
>|  |
>+--- <: ---+
> 
>  + <: ---+
>  |   |
> :(Int|Str) :> :(Str)
> 
> 
> Regards, TSa.
> -- 

Re: special named assertions

[mark . a . biggar]

The documentation should distinguish between those that are just pre-defined 
characters classes (E.G.,  and ) and those that are special 
builtins (E.G.,  and .  The former are things that you 
should be freely allowed to redefine in a derived grammar, while the other 
second type may want to be treated as reserved, or at least mention that 
redefining them may break things in surprising ways.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
> On Wed, Sep 27, 2006 at 11:59:32AM -0700, David Brunton wrote:
> > A quick scan of S05 reveals definitions for these seven special named 
> assertions:
> >   [...]
> 
> I don't think that <'...'> or <"..."> are really "named assertions".
> 
> I think that  (as well as <+xyz> and <-xyz>) are simply special forms
> of the named assertion .
> 
> I should probably compare your list to what PGE has implemented and see if
> there are any differences -- will do that later tonight.
> 
> Pm
> 

Re: Implicit current-index variable, scoped inside for-loops

[Mark A. Biggar]

Carl Mäsak wrote:

 Hey do you know what would be cool in perl 6
 A special variable for when you do a for (@array) style loop
 it would always have the index of the array

Discussed on #perl6: it's already quite easy in Perl 6 to loop with an
explicit index:

my @array = ;
for @array.kv -> $i, $val {
 say "$i\t$val";
}

But maybe a variable that implicitly carries along the loop index
would be even snazzier?



Whatever is done should also work for grep and map.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Numerification of Order:: constants

[mark . a . biggar]

 -- Original message --
From: "Reed, Mark (TBS)" <[EMAIL PROTECTED]>
> S03, lines 418-420:  "[cmp] always returns C,
> C, or C (which numerify to -1, 0, or +1)."
>  
> Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1?  In
> which case it would be clearer to put them in respective order above...
> 


"$a cmp $b" has always been define as sign($a - $b), so the above 
numerification are correct.  Thnk of them as describing the sequence ($a, $b). 
if the sequence is increasing then "$a, cmp $b" returns Order::Increase or -1.

Mark Biggar



--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained

[Mark A. Biggar]

Darren Duncan wrote:
Now, I didn't see them yet anywhere in Synopsis 3, but I strongly 
recommend having negated versions of all these various types of equality 
tests.  Eg, !== for ===, nev for eqv, etc.  They would be used very 
frequently, I believe (and I have even tried to do so), and of course we 
get the nice parity.


Yes and they should be strictly implicitly defined in term of the 
positive versions in such a way that you can't explicitly redefine them 
separately.  I.e., $x !== $y should always mean exactly the same thing 
as !($x === $y).  Maybe by a macro definition. To do otherwise would be 
very confusing as it would make such simple program transformations as:


say "foo" if $x !== $y;

into

say "foo" unless $x === $y;

very unreliable.

Actually a similar argument could be made about '<' vs '>', '>=' and 
'<=' in other words just redefining '==' & '<' should automatically get 
you '!=', '<=', '>=' and '>'.


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Scans

[Mark A. Biggar]

Austin Hastings wrote:

Gaal Yahas wrote:

On Mon, May 08, 2006 at 04:02:35PM -0700, Larry Wall wrote:
 
: I'm probably not thinking hard enough, so if anyone can come up 
with an

: implementation please give it :)  Otherwise, how about we add this to
: the language?

Maybe that's just what reduce operators do in list context.



I love this idea and have implemented it in r10246. One question though,
what should a scan for chained ops do?

  list [==] 0, 0, 1, 2, 2;
  # bool::false?
  # (bool::true, bool::true, bool::false, bool::false, bool::false) 
Keeping in mind that the scan will contain the boolean results of the 
comparisons, you'd be comparing 2 with "true" in the later stages of the 
scan. Is that what you intended, or would ~~ be more appropriate?


(And I'm with Smylers on this one: show me a useful example, please.)


Well the above example does tell you where the leading prefix of equal
values stops, assuming the second answer.

Combined with reduce it gives some interesting results:

[+] list [?&] @bits  ==> index of first zero in bit vector

There are other APLish operators that could be very useful in
combination with reduce and scan:

the bit vector form of grep (maybe called filter);
filter (1 0 0 1 0 1 1) (1 2 3 4 5 6 7 8) ==> (1 4 6 7)
This is really useful if your selecting out of multiple parallel arrays.
Use hyper compare ops to select what you want followed by using filter
to prune out the unwanted.

filter gives you with scan:

filter (list [<] @array) @array ==>
first monotonically increasing run in @array

filter (list [<=] @array) @array ==>
first monotonically non-decreasing run in @array

That was 5 minutes of thinking.

Mark Biggar


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Scans

[Mark A. Biggar]

Markus Laire wrote:


ps. Should first element of scan be 0-argument or 1-argument case.
i.e. should list([+] 1) return (0, 1) or (1)



APL defines it as the later (1).


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Scans

[Mark A. Biggar]

Austin Hastings wrote:

Gaal Yahas wrote:

On Mon, May 08, 2006 at 04:02:35PM -0700, Larry Wall wrote:
 
: I'm probably not thinking hard enough, so if anyone can come up 
with an

: implementation please give it :)  Otherwise, how about we add this to
: the language?

Maybe that's just what reduce operators do in list context.



I love this idea and have implemented it in r10246. One question though,
what should a scan for chained ops do?

  list [==] 0, 0, 1, 2, 2;
  # bool::false?
  # (bool::true, bool::true, bool::false, bool::false, bool::false) 
Keeping in mind that the scan will contain the boolean results of the 
comparisons, you'd be comparing 2 with "true" in the later stages of the 
scan. Is that what you intended, or would ~~ be more appropriate?


(And I'm with Smylers on this one: show me a useful example, please.)


Well the above example does tell you where the leading prefix of equal 
values stops, assuming the second answer.


Combined with reduce it gives some interesting results:

[+] list [?&] @bits  ==> index of first zero in bit vector

There are other APLish operators that could be very useful in 
combination with reduce and scan:


the bit vector form of grep (maybe called filter);
filter (1 0 0 1 0 1 1) (1 2 3 4 5 6 7 8) ==> (1 4 6 7)
This is really useful if your selecting out of multiple parallel arrays.
Use hyper compare ops to select what you want followed by using filter 
to prune out the unwanted.


filter gives you with scan:

filter (list [<] @array) @array ==>
first monotonically increasing run in @array

filter (list [<=] @array) @array ==>
first monotonically non-decreasing run in @array

That was 5 minutes of thinking.

Mark Biggar


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Perl 6 built-in types

[Mark A. Biggar]

> How about Bag, a set container?  Alternately what we really want is
> just a Hash where the type of the value is defined as 1, so it need
> not be stored at all.  Then most of the syntax for it just falls out
> of Hash syntax, unless you like writing $x ∈ $bag instead of $bag{$x}.
> Presumably we could make both work.

Please don't use bag as that is usually mathematically defined to be a
multi-set that can contain multiple copies of any given element.  In
perl that would be a hash of Ints.

I'm not sure that immutable make any sense as a concept separate from
constant. A truly immutable object can't even be initialized, it has to
be born ex-nilo already with a value.

I think that only values (like 1, "ABC" and a set constant like
(1|2|5|9)) are immutable. So, we should just stick with variable and
constant (assigned once doesn't change afterwards) containers and not
use the term immutable at all.


-- 
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: comment scope

[mark . a . biggar]

Isn't this what POD is for?


--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

 -- Original message --
From: "Ruud H.G. van Tol" <[EMAIL PROTECTED]>
> Perl6 could introduce (lexical, nestable) comment scope. 
> 
> Has that been discussed before?
> 
> 
> Maybe like: 
> 
>   #<<#EOC
>   # a comment line
>   # another comment line
> 
>   
> 
>   #EOC
> 
> 
> Or like: 
> 
>   #{#
> # first comment line
> # next comment line
> 
> 
> 
> # last comment line
>   #}#
> 
> 
> Or POD-ish.
> 
> -- 
> Groet, Ruud

Re: s29 and Complex numbers

[Mark A. Biggar]

David Green wrote:

 On 2/23/06, Jonathan Lang wrote:

  (Another possibility would be to return a list of every possible
result when in list context, with the result that you'd get in scalar
context being element zero of the list.  This even has its uses wrt
sqrt(Num), providing a two-element list of the positive and negative
roots, in that order.  This option would apply to sqrt, exp, log, and
the trig functions.)


I was thinking functions like sqrt would return a disjunction... I 
suppose it's probably still most useful to return a single scalar by 
default, so there would be some pragma via which you could choose to get 
lists or to get junctions when there's more than one possible result.


(Perhaps if you , the default might be to return junctions 
or lists on the grounds that you're trying to be more mathematical?)


For the complex trig functions the result set is infinite with no 
obvious order to return the list in even lazily that provides anything 
useful.  The results are all of the form A + (B + 2*pi*N)i where N can 
be any integer.  It is worth much more effort to just return a 
consistent principle value and getting the branch cuts and the handling 
of signed zero correct then to worry about trying to return multiple 
values in these cases.  For a through discussion see either the Ada or 
Common Lisp reference manuals.


Mark Biggar


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Smart match table

[mark . a . biggar]

 -- Original message --
From: Luke Palmer <[EMAIL PROTECTED]>
> On 2/7/06, Robin Houston <[EMAIL PROTECTED]> wrote:
> > Any undef undefinedmatch if !defined $a
> > Any Regex pattern matchmatch if $a =~ /$b/
> > Code()  Code()results are equalmatch if $a->() eq $b->()
> > Any Code()simple closure truth match if $b->() (ignoring $a)
> > Num numish[!] numeric equality match if $a == $b
> > Any Str   string equality  match if $a eq $b
> > Any Num   numeric equality match if $a == $b
> >
> > which retains commutativity in all cases. Of course it's
> > different in Perl 6, because the "dotted entries" like
> > .[number] and .method need to behave non-commutatively.
> > But is it really necessary for coderefs?
> 
> My interpretation (which may be totally off, as I don't have any
> confirmation that anybody else is thinking the same way I am) is that
> the synopsis is wrong, and commutivity of ~~ is a happy coincidence
> wherever it exists.  The way I've been thinking about ~~ is just as
> the following object-oriented sugar:
> 
> role Pattern {
> method match(Any $x) {...}
> }
> sub infix:<~~> (Any $x, Pattern $y) {
> $y.match($x);
> }
> 
> And then the interpretation of ~~ is determined by its right-hand side.
> 
> Luke

Also ermemebr that a very common user of ~~ is the implisit use in a when 
conditional inside a given block, which is an inheirently assymeterical (thus 
non-communitive) situation.


--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: type sigils redux, and new unary ^ operator

[Mark A. Biggar]

Juerd wrote:

Rob Kinyon skribis 2005-11-23 11:58 (-0500):

I don't use 0..$n-1 very often. I use 0..$#arr most often. 



Good point. Doesn't ^5 encourage [EMAIL PROTECTED] too much? After all, we 
should
write what we mean, instead of something that happens to evaluate to the
same list. We mean to use indexes, but [EMAIL PROTECTED] doesn't return an index. 


Actually I like that and think that ^$x should be 0..($x-1) and that 
[EMAIL PROTECTED] should be define to return the array's index set (usually 
0..$#foo) but maybe something else for a non-zero based array.



--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Copyrights in file headers

[Mark A. Biggar]

Has any FOSS developer ever been found liable (or even sued)?

Not that I have any objections to this plan but it might be worth
considering that it's much easier to sue a single entity then it is to
file a tort against a few tens or hundreds of contributors.


Yes, the guy who wrote an open source DVD player for Linux was sued by 
the consortium of companies that own the IP for DVD's.  I don't remember 
the result, but the EFF archives should have something on it.



--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: multiline comments

[Mark A. Biggar]

Alfie John wrote:

Hi (),

This is probably a stupid question, but I can't find anything from  google:

Does Perl6 support multiline comments?


Briefly, No and kind of.

Standard Perl 6 comments are just like those in Perl 5.  A '#' starts a 
comment that is terminated by the end of line. But, both Perl 5 and 6 
are intended to support the POD system of embedded documentation (for 
the 'kind of'.)  Of course the grammar is planed to be dynamically 
modifiable so a Perl module could theoriticaly declare it own special 
multi-line comment system.


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Look-ahead arguments in for loops

[Mark A. Biggar]

Mark A. Biggar wrote:

Damian Conway wrote:


Rather than addition Yet Another Feature, what's wrong with just using:

for @list ¥ @list[1...] -> $curr, $next {
...
}

???

Damian



Shouldn't that be:

for [EMAIL PROTECTED], undef] ¥ @list[1...] -> $curr, $next {
...
}

As I remember it zip hrows away extras, not fills in with undef.



Drat I did that backwaeds didn't I.

try:

for @list ¥ [EMAIL PROTECTED], undef] -> $curr. $next {

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Look-ahead arguments in for loops

[Mark A. Biggar]

Damian Conway wrote:

Rather than addition Yet Another Feature, what's wrong with just using:

for @list ¥ @list[1...] -> $curr, $next {
...
}

???

Damian



Shouldn't that be:

for [EMAIL PROTECTED], undef] ¥ @list[1...] -> $curr, $next {
...
}

As I remember it zip hrows away extras, not fills in with undef.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Stringification, numification, and booleanification of pairs

[Mark A. Biggar]

In a private conversation with Larry this afternoon, he said that by 
default "$foo" and ~$foo and $foo.as(Str) all give the same result 
(assuming scalar context, etc.).  And that "@foo[]" and [EMAIL PROTECTED] and 
@foo.as(Str) are the same as join(' ', @foo) where join is effectively:


sub join(Str $x is rw, @A) {
my Str $y = '';
for $z -> (@A) {
$y ~= ~$z;
} continue {
$y ~= $x:
}
return $y;
}

Also that a pair ($x => $y) stringifies to "$x\t$y" and that [EMAIL PROTECTED] for an 
array of pairs is the same as join("\n", @A);


It is also intended that .as(Str, ...) takes extra named args (names 
TDB) for things like separators and sprintf like format strings so you 
can customize it, including ways to change the defaults for a class 
(like the separator for arrays of pairs being "\n" instead of ' ').


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: [perl #17490] Magic is useless unless verifiable.

[Mark A. Biggar]

Joshua Hoblitt wrote:


a) live with it
b) change the magic number to be two identical bytes so the byte
   ordering doesn't matter
c) shrink the magic number to be a single byte


d) use a magic number that can also be used as the byte order indicator.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Stringification, numification, and booleanification of pairs

[Mark A. Biggar]

Eric wrote:

Hey,

Since you wouldn't expect an object to stringify or numify why expect pairs
to? I'm not sure i see any value in thatm, $pair.perl.say would be the best
way to output one anyway.

my $pair1 = (a => 2);
my $pari2 = (b => 3);
say $pair1 + $par2; # Error: illegal stringification of pair.?

I know nothing, but couldn't users create there own pair class that does
what they want? Or extend the builting one to override operators they way
they want?


Actually I do except some object to stringify or numify.  For example en 
object of type date should stringify to something like "January 1, 2000" 
and also to numify to the Julian day number.


Now for a related question:  is it intended that ~$x and +$n be the same 
as $x.as(Str) and $x.as(Num)?  How locked in stone would this be,  I.e.,

~ and + are macros that give the .as() form?

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: conditional wrapper blocks

[mark . a . biggar]

Some other possible problems:

1: if $condition is an expression with side-effects then your new construct has 
a different meaning then the original code.

2: if the middle part does something that changes the value of  the expression 
$condition then the new construct again has a different meaning.


besides if you really want it just define a macro.


--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


> Today on #perl6 I complained about the fact that this is always
> inelegant:
> 
>   if ($condition) { pre }
> 
>   unconditional midsection;
> 
>   if ($condition) { post }
> 
> Either you put the condition in a boolean var and check it twice, or
> you use a higher order function and give it three blocks, and the
> conditional. But no matter how much we try, it always feels too
> "manual".
> 
> I asked for some ideas and together with Aankhen we converged on the
> following syntax:
> 
>   if ($condition) {
>   pre;
>   } uncond {
>   middle;
>   } cond {
>   post;
>   }
> 
> s/uncond/<>.pick/e;
> s/cond/<>.pick/e;
> 
> Some restrictions:
> 
> The block structure must always be ternary - for other cases we
> already have enough control flow.
> 
> The if is not the same if that can cuddle with else - it's either
> or.
> 
> Does anybody have any comments, or synonyms for the control
> structure naming?
> 
> BTW, I expect readability to be optimal with 1-2 lines of pre/post,
> and 1-5 lines of middle. Any observations?
> 
> -- 
>  ()  Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418  perl hacker &
>  /\  kung foo master: /me groks YAML like the grasshopper: neeyah!!
> 
> 

--- Begin Message ---


pgpQKcWBJSvqV.pgp
Description: PGP signature
--- End Message ---

Re: @array = $scalar

[mark . a . biggar]

I think this deserves at least a compile time warning and also a strict pragma 
to make it an error as it is most likely not what the programmer wanted.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


> Ingo Blechschmidt skribis 2005-08-31 13:22 (+):
> > @array = $arrayref;  # really means 
> > @array = ($arrayref,);   # same as 
> > @array = (); @array[0] = $arrayref;  # thus 
> > say [EMAIL PROTECTED]; # always 1 
> > # Correct? 
> 
> Yes, although at some point there was this weird notion of scalars
> automatically dereferencing in list context, in this respect Perl 6
> currently is sane.
> 
> 
> Juerd
> -- 
> http://convolution.nl/maak_juerd_blij.html
> http://convolution.nl/make_juerd_happy.html 
> http://convolution.nl/gajigu_juerd_n.html

Re: my $pi is constant = 3;

[mark . a . biggar]

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]> On Wed, Aug 17, 2005 at 08:47:18AM -0700, Larry Wall wrote:
> > : >That could be made to work by defining constant to mean you can assign
> > : >to it if it's undefined.  But then it gets a little harder to reason
> > : >about it if $pi can later become undefined.  I suppose we could
> > : >disallow undefine($pi) though.
> 
> If you can assign it when it contains an undefined value, bad
> things happen:
> 
> sub f ($x is readonly) { $x = 10 }
> my $a; f($a);
> 
> Compare this with:
> 
> my $x is readonly;
> $x = 10;
> 
> If it is defined as "bound to a immutable value cell", both cases
> above would fail, which is imho the easiest to explain.


Not only that, but what if what I want is a named constnat undef value?


> On Wed, Aug 17, 2005 at 08:47:18AM -0700, Larry Wall wrote:
> > : >That could be made to work by defining constant to mean you can assign
> > : >to it if it's undefined.  But then it gets a little harder to reason
> > : >about it if $pi can later become undefined.  I suppose we could
> > : >disallow undefine($pi) though.
> 
> If you can assign it when it contains an undefined value, bad
> things happen:
> 
> sub f ($x is readonly) { $x = 10 }
> my $a; f($a);
> 
> Compare this with:
> 
> my $x is readonly;
> $x = 10;
> 
> If it is defined as "bound to a immutable value cell", both cases
> above would fail, which is imho the easiest to explain.
> 
> > You could still reason about it if you can determine what the initial
> > value is going to be.  But certainly that's not a guarantee, which
> > is one of the reasons we're now calling this write/bind-once behavior
> > "readonly" and moving true constants to a separate declarator:
> > 
> > my $pi is readonly;
> > $pi = 3;
> 
> The question remains, whether you can bind the readonliness away:
> 
> my $pi is readonly; # undef at this point
> my $e is rw = 2.7;
> $pi := $e;
> $pi = 9;
> 
> I can argue both sides -- rebindable is easier to implement, but
> non-rebindable is perhaps more intuitive.
> 
> Thanks,
> /Autrijus/
> 

Re: Time::Local

[Mark A. Biggar]

Nicholas Clark wrote:

On Tue, Jul 05, 2005 at 06:47:41PM -0600, zowie wrote:


There is also a certain joy that comes from noticing that a tool was  
designed by pedants:
it's great that cal(1) handles the Gregorian reformation correctly  
(or at least, in one
of several arguably correct ways) even though most of us don't deal  
with dates in 1752.



I disagree:


$ LC_ALL=es_ES cal 9 1752
 septiembre de 1752
do lu ma mi ju vi sá
   1  2 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30


Spain adopted the Gregorian Calendar in 1582. Surely setting my locale to
Spain should make the Julian/Gregorian jump show up in 1582, not 1752?


I think that this demonstrates how tricky all this mess is.

Nicholas Clark



The actual situation is even worse.  You can even use Gregorian dates
for all of 20th history as Russia didn't convert from Julian until 1920.

There is not much you can do to simply store historical dates on a computer:

1) keap all dates Gregoian even those before 1582 when the Gregorian
calendar was first used by Catholic Europe.  This was right in the
middle of King Henry VIII's disagreement with the Catholic church so
England didn't convert until 1752 (the cal refernce above).  Given that
Englands colonies converted at the same time this explains the confusion
over the Washington's birthday holiday where some states used Feb 11
(Julian Calendar) and some used Feb 22 (Gregorian calendar), as Feb 12
is Lincon's Birthday, for the national version of the holiday it was
decided to just call some Monday in Feb President's Day and do it all
the same day.  Also, do you use a year 0 or not, which is an interesting
problem?

2) keep all dates as the people at that place and time in history would
have recorded them, but that is hard as you loose comparability and lots
of recorded historic date are Reign dated or things like N years sence
the founding of Rome, etc.

3) use Astronomical Dates which are kept as the number of days sense
noon Jan-1-4713 BC.

4) keep soe dates Julian Calandar and some Gregorian, but which switch
over do you use.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]

[Mark A. Biggar]

Mark A. Biggar wrote:

Luke Palmer wrote:


On 8/10/05, Dave Rolsky <[EMAIL PROTECTED]> wrote:


[changing the subject line for the benefit of the summarizer ...]

On Wed, 10 Aug 2005, Larry Wall wrote:



And now some people will begin to wonder how ugly set values will look.
We should also tell them that lists (and possibly any-junctions)
promote to sets in set context, so that the usual way to write a set
of numbers and strings can simply be

  <1 dog 42 cat 666.5>



Groovy, but what about this?

 <1 dog 42 cat 42>

Maybe a warning with an optional fatality under "use strict 'sets'"?




I doubt that should be any kind of warning or error.  It's just that
your set will end up having four elements instead of five.  But you
really don't want to warn in this case:

@myset (+) <1>;

By using the (+) operator (instead of the list concatenation, er,
operator?), the user is implying that he wants duplicates in @myset
thrown away.



Small issue, what comparison operator do you use to determine 
duplicates?  For example (possibly pathological case):


(undef but true) (+) (undef but false)


Actually, I'm going to make a stab at answering this myself.  The 
obvious answer is that you use the magic operator ~~ by default just 
like for a case statement.  But there does need to be some way to change 
that when necessary.



--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]

[Mark A. Biggar]

Luke Palmer wrote:

On 8/10/05, Dave Rolsky <[EMAIL PROTECTED]> wrote:


[changing the subject line for the benefit of the summarizer ...]

On Wed, 10 Aug 2005, Larry Wall wrote:



And now some people will begin to wonder how ugly set values will look.
We should also tell them that lists (and possibly any-junctions)
promote to sets in set context, so that the usual way to write a set
of numbers and strings can simply be

  <1 dog 42 cat 666.5>


Groovy, but what about this?

 <1 dog 42 cat 42>

Maybe a warning with an optional fatality under "use strict 'sets'"?



I doubt that should be any kind of warning or error.  It's just that
your set will end up having four elements instead of five.  But you
really don't want to warn in this case:

@myset (+) <1>;

By using the (+) operator (instead of the list concatenation, er,
operator?), the user is implying that he wants duplicates in @myset
thrown away.


Small issue, what comparison operator do you use to determine 
duplicates?  For example (possibly pathological case):


(undef but true) (+) (undef but false)


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Elimination of Item|Pair and Any|Junction

[Mark A. Biggar]

Larry Wall wrote:

On Wed, Jul 27, 2005 at 06:28:22PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Since we are in type hierachies these days, here's my from ::Any
: towards ::All version.

That's pretty, but if you don't move Junction upward, you haven't
really addressed the question Autrijus is asking.  We're looking
for a simple type name that means none(Junction) for use as the
default type of the $x parameter to -> $x {...}.  Whatever we call
it, this type/class/role/subtype has to admit Item and Pair objects
but not Junctions.  (And if that's the wrong way to think about it,
please tell us why.)


Suggestions:

Definite
Singelton (but that may mean no pairs, oops)
Solid
Settled
NonJunctive (yuck)
Terminal
NonThreaded (yuck)
Simple (but that could exclude arrays and hashs)]
Basic

Interesting question: are junctions infectious, are class object that 
include a member with ajunction type also junctions?



--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: %hash1 >>...<< %hash2

[Mark A. Biggar]

Luke Palmer wrote:

On 14 Jun 2005 06:07:10 -, David Formosa (aka ? the Platypus)
<[EMAIL PROTECTED]> wrote:


multi sub infix_circumfix_meta_operator:{'>>','<<'} (Hash %a,Hash %b,Code $op) {
   my Hash %return;
   for intersection(keys %a,keys %b) -> $key {
 %return{$key} = $op($a{$key},$b{$key});
   }
   return %return;
}

   Would this be sensible, usefull behavour?



I think so.

In fact, I've implemented "hash vector" and "hash matrix" classes
which are useful for doing various linearesque things, when you don't
know how many elements your vectors will have.  The difference between
the hyper hash ops and vector-vector ops in my class is the fact that
you did intersection instead of union (I assumed unset elements were
0).  Unfortunately, such an assumption doesn't make sense on a general
scale, so I wonder whether I would end up using the hash hyper ops or
whether I'd just go and implement them again.

So, I'd really like to see a couple examples where this behavior could
be useful.  I don't doubt that it can, but I can't think of anything
at the moment.


This is effectively the Database inner vs outer join issue.  There are 
times you need one and times you need the other.  Example for the outer 
join case: combining two invoices where you want to add together the 
subtotals for each type of item and missing items on either invoice 
should be assumed to be 0 quantity at 0 dollars.  Note that just like in 
the reduce op you need to know the identity value associated with the 
op.  come to think of it just like in the DB world you really need 4 
different versions: inner join (intersection of keys), full outer join 
(union of keys) and the left and right outer joins where you on consider 
the missing keys on the left or right sides. This means that the current 
hyper-op should be define to be one of inner or full and we need some 
syntax to specify the other three op types.  >>-:left<< Ugh!


As a sidenote this would make writing a simple in Perl 6 DB module trivial.


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: comprehensive list of perl6 rule tokens

[mark . a . biggar]

I'm having a hard time coming up eith examples where I need anything otehr than 
union and difference for character classes.  Most of the predefined character 
classes are disjoint, so intersection is almost useless.  So for now let's just 
stick with + and - and simple sets with not parens, unless we can come up with 
cases that really need anything more complicated.

--
Mark Biggar 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED]

-- Original message -- 

> On Sat, May 28, 2005 at 12:58:01AM -0400, Jeff 'japhy' Pinyan wrote: 
> >[ set notation for character classes ] 
> > 
> > What say you? 
> 
> Off the top of my head I think using & and | within character classes 
> will cause confusion. 
> 
> / (<~(X & Y) | Z> | ) & / 
> 
> So much for the "visual pill" of 
> 
> Also, character classes don't currently utilize parentheses for 
> anything. This is a good thing as you don't have to distinguish between 
> which parens are within assertions and which are without. Or do you 
> proposed that even the parens within assertions should capture to $0 
> and friends? 
> 
> -Scott 
> -- 
> Jonathan Scott Duff 
> [EMAIL PROTECTED] 

Re: comprehensive list of perl6 rule tokens

[Mark A. Biggar]

Jeff 'japhy' Pinyan wrote:

On May 25, Mark A. Biggar said:


Jonathan Scott Duff wrote:


On Tue, May 24, 2005 at 11:24:50PM -0400, Jeff 'japhy' Pinyan wrote:

I wish  was allowed.  I don't see why  has to be 
confined to zero-width assertions.



I don't either actually. One thing that occurred to me while responding
to your original email was that  might have slightly wrong
huffmanization.  Is zero-width the common case?  If not, we could use
character doubling for emphasis:   consumes, while  is
zero-width. 



Now  is a character class just like <+digit> and so
under the new character class syntax, would probably be written
<+prop X> or if the white space is a problem, then maybe <+prop:X>
(or <+prop(X)> as Larry gets the colon :-), but that is a pretty
adverbial case so ':' maybe okay) with the complemented case being
<-prop:X>.  Actually the 'prop' may be unnecessary at all, as we know
we're in the character class sub-language because we saw the '<+', '<-'
or '<[', so we could just define the various Unicode character property
codes (I.e., Lu, Ll, Zs, etc) as pre-defined character class names just
like 'digit' or 'letter'.



Yeah, that was going to be my next step, except that the unknowing 
person might make a sub-rule of their own called, say, "Zs", and then 
which would take precedence?  Perhaps  is a good way of writing it.


Well we have the same problem with someone redefining 'digit'.  But 
character classes are their own sub-language and we may need to
distinguish between Rule::digit and CharClass::digit in the syntax.  Of 
course we could hack it and say that a rule that consists of nothing but 
a single character class item is usable in other character classes by
its name, but that could lead to subtle bugs where someone modifies that 
special rule to add stuff to it and breaks all usage of it as a 
character class everywhere else.  Now a grammar is just a special kind 
of class that contains special kinds of methods called rules, maybe we 
need another special kind of method in a grammar that just define a 
named character class for later use?  In any case as usual with methods 
a user define character class should override a predefined one of the 
same name.


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: comprehensive list of perl6 rule tokens

[Mark A. Biggar]

Jonathan Scott Duff wrote:

On Tue, May 24, 2005 at 11:24:50PM -0400, Jeff 'japhy' Pinyan wrote:

I wish  was allowed.  I don't see why  has to be confined 
to zero-width assertions.



I don't either actually. One thing that occurred to me while responding
to your original email was that  might have slightly wrong
huffmanization.  Is zero-width the common case?  If not, we could use
character doubling for emphasis:   consumes, while  is
zero-width.  


But that's just a random rambling on my part. I trust @Larry has put
wee more thought into it than I.  :-)


But what would a consuming  mean?  As it can have no internal
backtracking points (it only has them if it fails), it would match (and
consume) the whole rest of the string, then if there were any more to
the pattern, would immediately backtrack back out left of itself.  Thus
it would be semantically identical to the zero-width version.  So 
zero-width is really the only possibility for .


Now  is a character class just like <+digit> and so
under the new character class syntax, would probably be written
<+prop X> or if the white space is a problem, then maybe <+prop:X>
(or <+prop(X)> as Larry gets the colon :-), but that is a pretty
adverbial case so ':' maybe okay) with the complemented case being
<-prop:X>.  Actually the 'prop' may be unnecessary at all, as we know
we're in the character class sub-language because we saw the '<+', '<-'
or '<[', so we could just define the various Unicode character property
codes (I.e., Lu, Ll, Zs, etc) as pre-defined character class names just
like 'digit' or 'letter'.

BTW, as a matter of terminology, <-digit> should probably be called the
complement of <+digit> instead of the negation so as not to confuse it 
with the  negative zero-width assertion case.


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Perl development server

[Mark A. Biggar]

wolverian wrote:

On Tue, May 24, 2005 at 03:44:43PM +0200, Juerd wrote:


But I like the newly suggested "feather" better, as it can relate to
pugs AND parrot.



Feather is best one thus far, I think. I like carrot too; it's more
playful. I equate Pugs with fun a lot.



How about "budgie". a small Australian parakeet usually light green with 
black and yellow markings in the wild but bred in many colors, syn: 
budgerigar.


--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: reduce metaoperator on an empty list

[mark . a . biggar]

There are actuall two usefull definition for %.  The first which Ada calls 
'mod' always returns a value 0<=X HaloO Mark,
> 
> please don't regard the following as obtrusive.
> 
> you wrote:
> > If as usual the definition of a right identity value e is that a op e = a 
> > for 
> all a,
> > then only +inf works.  Besdies you example should have been;
> 
> Or actually $n % any( abs($n)+1 .. Inf ) to really exclude 0
> from the junction.
> 
> > $n % any (($n+1)..Inf),  $n % $n = 0. 
> 
> That depends on the definition of % and the sign of $n.
> With the euclidean definition 0 <= ($n % $N == $n % -$N) < abs($N)
> and for $n < 0 there's no identity at all. The identity element
> has to be an element of the set, which +Inf isn't. It's a type.
> 
> BTW, is % defined as truncation in Perl6?
> That would be a bit unfortunate. Simple but not well thought out.
> -- 
> TSa (Thomas Sandlaß)
> 

Re: reduce metaoperator on an empty list

[mark . a . biggar]

> Mark A. Biggar wrote:
> > Well the identity of % is +inf (also right side only).
> 
> I read $n % any( $n..Inf ) == $n. The point is there's no
> unique right identity and thus (Num,%) disqualifies for a
> Monoid. BTW, the above is a nice example where a junction
> needn't be preserved :)

If as usual the definition of a right identity value e is that a op e = a for 
all a,
then only +inf works.  Besdies you example should have been;
$n % any (($n+1)..Inf),  $n % $n = 0. 

> > E.g. if X 
> Sorry, is it the case that $x = $y < $z might put something else
> but 0 or 1 into $x depending on the order relation between $y and $z?

Which is one reason why I siad that it might not make sense to define the 
chaining ops in terms of the associtivity of the binary ops,  But as we are 
interested in what [<] over the empty list shoud return , the identity (left or 
right) of '<' is unimportant as I think that should return false as there is 
nothing to be less then anything else.  Note that defaulting to undef therefore 
works in that case.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: reduce metaoperator on an empty list

[Mark A. Biggar]

John Macdonald wrote:
Is there a built-in operator that doesn't have a meaningful
identity value?  I first thought of exponentiation, but it has
an identity value of 1 - you just have to realize that since
it is a right associative operator, the identity has to be
applied from the right.
Well the identity of % is +inf (also right side only).  The identities 
for ~| and ~^ are infinitely long bitstrings of 0's, while that for ~& 
is a similarly long bitstring of 1's.  The chained comparison ops are 
weird as depending of which why you define the associativity (and thus 
which side's value you return when true) you get either a left side only 
or right side only Identity.  E.g. if X

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: reduce metaoperator on an empty list

[Mark A. Biggar]

Stuart Cook wrote:
To summarise what I think everyone is saying, []-reducing an empty
list yields either:
1) undef (which may or may not contain an exception), or
2) some unit/identity value that is a trait of the operator,
depending on whether or not people think (2) is actually a good idea.
The usual none(@Larry) disclaimer applies, of course...
Well the only case where it probably really matters is [+] where you 
really want the result to be 0.  Of course +undef == 0, so maybe 
returning undef might be okay.  I'm thinking about the case:

[+] grep &some_condition, @a
where you really want the total to be 0, even if the result of the grep 
is empty.

A case can also be made for (assuming @a = ();) that
[EMAIL PROTECTED] == 1
[EMAIL PROTECTED] eq '' (also covered by ~undef)
[?&[EMAIL PROTECTED] ~~ true
[?|[EMAIL PROTECTED] ~~ false (also covered by ?undef)
[EMAIL PROTECTED] ~~ false (also covered by ?undef)
[+&[EMAIL PROTECTED] == MAXINT (whatever that is)
[+|[EMAIL PROTECTED] == 0 (also covered by +undef)
[EMAIL PROTECTED] == 0 (also covered by +undef)
chained ops are wierd
[<[EMAIL PROTECTED] ~~ false
[>[EMAIL PROTECTED] ~~ false
[<[EMAIL PROTECTED] ~~ true
[>[EMAIL PROTECTED] ~~ true
Other ops have theoritical values that I don't know if we can handle:
[~&[EMAIL PROTECTED] should be an infinitely long bitstring of 1's
[~|[EMAIL PROTECTED] should be an infinitely long bitstring of 0's
Again, given that that the really important case [+] is covered by 
+undef == 0, maybe just always returning undef is good enough.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: reduce metaoperator on an empty list

[Mark A. Biggar]

Matt Fowles wrote:
All~
What does the reduce metaoperator do with an empty list?
my @a;
[+] @a; # 0? exception?
[*] @a; # 1? exception?
[<] @a; # false?
[||] @a; # false?
[&&] @a; # true?
Also if it magically supplies some correct like the above, how does it
know what that value is?
The usual definition of reduce in most languages that support it, is 
that reduce over the empty list produces the Identity value for the 
operation.  So for the above ops the answers are: 0, 1, depends, false, 
true.  For chained ops like '<' it depends on whether x

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: trait and properties thru getter/setters

[mark . a . biggar]

I don't understand why you think you need the eval here?

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


> There is syntax to define trait and properties
> but is there an API?
> 
>   my $b = eval '$a but true'; # setting a true property
>   # API to do it without an eval?
> 
> A trait setter probably does not make sense but for the
> implementer because it should not be set at run time.
> 
> Incidentally, in a interactive environment it would be cool
> to access the documentation of variables and functions using
> properties. Say "doc" and "udoc" respectively for the full and
> one line version.
> 
> 
> -- 
>   cognominal stef

Re: split /(..)*/, 1234567890

[mark . a . biggar]

No, it's not inconsistant.  Think about the simpler case split /a/,'a' 
which return a list of empty strings.  Now ask to keep the separators
split /(a), 'a' which will return ('', 'a', '', 'a', '', 'a', '', 'a, '', 
'a').  Now look at 
split /(a)/, 'aaab' which returns ('', 'a', '', 'a', '', 'a', 'b'). not no 
empty string ebfore the 'b'.

In the case of split /(..)/, "12345678" all those pairs of digits are all 
spearators so again you get  empty strings aternating with digit pairs.  If the 
number of digits is odd the lat on isn't  a separator so it takes the place of 
the final empty string and there won;t be a empty string in the list before it, 
I.e,
split /(..)/, 12345 returns (''. '12', '', '34', '5');

This is another of those cases where the computer did exactly what you ask it 
to.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


> Autrijus Tang wrote:
> > I don't know, I didn't invent that! :-)
> > 
> > $ perl -le 'print join ",", split /(..)/, 123'
> > ,12,3
> 
> Hmm,
> 
> perl -le 'print join ",", split /(..)/, 112233445566'
> ,11,,22,,33,,44,,55,,66
> 
> For longer strings it makes every other match an empt string.
> With the "Positions between chars" interpretation the above
> string is with '.' indication position:
> 
> .1.1.2.2.3.3.4.4.5.5.6.6.
> 0 1 2 3 4 5 6 7 8 9 1 1 1
>  0 1 2
> 
> There are two matches each at 0, 2, 4, 6, 8 and 10.
> The empty match at the end seams to be skipped because
> position 12 is after the string? And for odd numbers of
> chars the before last position doesn't produce an empty
> match:
> perl -le 'print join ",", split /(..)/, 11223'
> ,11,,22,3
> 
> Am I the only one who finds that inconsistent?
> -- 
> TSa (Thomas Sandlaß)
> 

Re: rules trouble

[Mark A. Biggar]

Dino Morelli wrote:
I'm working on more p6rules unit tests.
Having some trouble. First, understanding when :w means \s* and when it
means \s+
Also, these tests are failing when I use :: to separate the modifier
from the pattern. But they work when I do ':w blah' (separate with a
space). I'm not sure which ways are "right".
The actual failing tests:
my $targ = qq{ foobar
baz  quux
zot\tfum};
p6rule_is  ($targ, ':w::baz quux',  'baz\s+quux or baz\s*quux matches');
p6rule_is  ($targ, ':w::zot fum',   'zot\s+fum or zot\s*fum matches');
If I remember right Larry's intent was that it depends on word 
boundaries.  Thus the thing to look at is to put "\b" there instead of 
the "\s+" or "\s*" and see if the match will still work.  I.e., if "\b" 
would succeed then use "\s*" and if "\b" would fail the use "\s+".  Thus 
both of your examples above should use "\s+" because you want to 
preserve the separation between the words.  So, if the rule was
':w::baz ###', then you'd what to use "\s*" as the white space is not 
needed to keep them separate.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Nested captures

[mark . a . biggar]

> On Wed, May 11, 2005 at 05:48:59PM +1000, Damian Conway wrote:
> : But that's only the opinion of one(@Larry), not of $Larry.
> 
> Let's go 0-based and make $0 =:= $/[0] so that $/[] is all the parens.
> Our old $0 (P5's $&) could be $<> instead, short for $ or some
> such.

Why can't bare $/ just striingify to the whole match?
 
> It's already the case that p5-to-p6 is going to have a *wonderful*
> time translating $7 to $1[2][0]...

Not a real problem.  Patrick has already said that his plan is that :p5 REs 
will return a match object with an already flattened match list using perl5 
left peren counting semantics.

> I wonder how much call there will be for a rule option that uses P6
> syntax but P5 paren binding with "push" semantics.

Just add a :flat 

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Nested captures

[mark . a . biggar]

Can I say $*1, $*2, etc, to get perl5 flattened peren counting captures?  We 
need something like that to make perl5->perl6 translation easier; otherwise 
we'd have to parse perl5 RE instead of just slapping on a ":p5".   Unless ":p5" 
also means that you get a single already fattened match objct.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


> On Mon, May 09, 2005 at 02:08:31PM -0500, Patrick R. Michaud wrote:
> : Hmmm, then would $x.$j.2 then be equivalent to $x[$j-1][1] ?  
> 
> Ouch.
> 
> Larry

Re: available operator characters

[Mark A. Biggar]

Juerd wrote:
Juerd skribis 2005-05-06 18:24 (+0200):
   |AVAILABLE any()

We can use this for labels:
|foo| for ... {
while ... {
...;
next foo if ...;
}
}
It'll confuse the heck out of Ruby coders, but I do like this syntax. It
makes labels stand out, as was one of the requirements, and it puts a
little less strain on the colon.
(Now, if we really want to bug Rubyfolk, we could make labels per block
instead of per statement, and put them inside the curlies:
for ... { |foo|
while ... {
...;
next foo if ...;
}
}
*evil grin*)
Actually if we define |...| at all, I'd prefer it mean abs(), its usual 
mathmatical meaning.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Pugs 6.2.0 released.

[mark . a . biggar]

Well, consider expressions with xor that only contain values 1 and 0.
What should "1 xor 1 xor 1" return?  Least surprise would suggest 
that it should be 1 not 0.  I was ignoring the fact that non-zero values perk 
through (which is not very useful in the "xor" case, unlike that for "or" or 
"and") and only was considering the eventual boolean meaning of the result.

Yes, we are discussing the definition of the language and of course there isn't
any such function as xor(p1,p2,p3...) yet.  We are attempting to determine just 
what that should mean it it were to be added.  All we really have to go
on right now is the carry over of the meaning from perl5 of "p1 xor p2 xor p3" 
which happens to be the same as  "p1 xor (p2 xor p3))", I.e., built from a 
binary right-associative "xor" op.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


> 
> --- "Mark A. Biggar" <[EMAIL PROTECTED]> wrote:
> > [EMAIL PROTECTED] wrote:
> > 
> > > I see here another case of a common erroneous approach to
> > > problem-solving.   People are trying to enumerate definitions to
> > impose
> > > on something, rather than starting with the thing at hand and
> > > exhausting any clues it may provide before moving on.  This can
> > lead to
> > > serious and, in hindsight, embarrassing mistakes.
> > > 
> > > In this case, we are dealing with '^^', a meaningless
> > unpronounceable
> > > symbol.  Oh, but wait ... we also spell it 'xor', which I suppose
> > is
> > > often pronounced "ex or", which might be the source of the
> > difficulty.
> > > Because 'xor' stands for ... ... 'exclusive or'.  Exclusive? 
> > It's not
> > > hard to figure out what that means.  Here are some of the
> > relevant
> > > dictionary definitions:
> > > 
> > > Not allowing something else; incompatible: mutually exclusive
> > > conditions
> > > Not accompanied by others; single or sole
> > > 
> > > So what does that say about proposing that xor(p1,p2,...) is true
> > if an
> > > odd number of p[i] are true?  Other than that people should
> > pronounce
> > > these operators out loud more often?
> > > 
> > > Clearly, xor is true iff *exactly* one of its arguments is true,
> > and of
> > > course it should return that argument (or bool::false if no
> > argument is
> > > true).
> > > 
> > > That should now be so blatantly obvious that everyone should be
> > > embarrassed for not having seen it immediately.  But don't run
> > from
> > > embarrassment (or become defensive and attack the messenger) --
> > it's a
> > > powerful tool (which is why we evolved to have it).  It should
> > cause
> > > one to question one's thought processes and consider how to
> > improve
> > > upon them, which is all to the good, isn't it?
> > 
> > Except that xor or ^^ is only a binary operation, there is no
> > "xor(p1,p2,...)", only "p1 xor p2 xor ..." which can really only be
> > 
> > understood if you add () to disambiguate the order that the binary
> > ops 
> > are performed.  Fortunately, xor is associative so it doesn't
> > matter how 
> > you add the (), you get the same answer.  Try it out, you will
> > discover
> > that "p1 xor p2 xor ..." is true iff an odd number of the p's are
> > true. 
> >   As long as you build "p1 xor p2 xor ..." out of binary xor ops
> > that is 
> > the result you get.  Computing parity is much more common that your
> > 
> > multi-arg operation.  Besides, all the literature about logic and 
> > circuit design define "p1 xor p2 xor ..." in terms of binary xor,
> > so 
> > your trying to buck hundreds of years of consensus.
> 
> Sorry, but you're quite wrong here, because that literature applies
> to an associative operator, which Perl's xor is not.  ((1 xor 2) xor
> 3) == 3, while (1 xor (2 xor 3)) == 1.  I again ask that you pay more
> attention to the thing you're dicussing, rather than to simply
> generate stuff out of your own head, so as to avoid trivial
> embarrassing error.  You wrote q(Try it out, you will discover that
> "p1 xor p2 xor ..." is true iff an odd number of the p's are true) --
> this fails on two counts; 1) it begs the question, which was how "p1
> xor p2 xor p3" should be evaluated -- it can only be "tried ou

Re: Pugs 6.2.0 released.

[Mark A. Biggar]

[EMAIL PROTECTED] wrote:
I see here another case of a common erroneous approach to
problem-solving.   People are trying to enumerate definitions to impose
on something, rather than starting with the thing at hand and
exhausting any clues it may provide before moving on.  This can lead to
serious and, in hindsight, embarrassing mistakes.
In this case, we are dealing with '^^', a meaningless unpronounceable
symbol.  Oh, but wait ... we also spell it 'xor', which I suppose is
often pronounced "ex or", which might be the source of the difficulty.
Because 'xor' stands for ... ... 'exclusive or'.  Exclusive?  It's not
hard to figure out what that means.  Here are some of the relevant
dictionary definitions:
Not allowing something else; incompatible: mutually exclusive
conditions
Not accompanied by others; single or sole
So what does that say about proposing that xor(p1,p2,...) is true if an
odd number of p[i] are true?  Other than that people should pronounce
these operators out loud more often?
Clearly, xor is true iff *exactly* one of its arguments is true, and of
course it should return that argument (or bool::false if no argument is
true).
That should now be so blatantly obvious that everyone should be
embarrassed for not having seen it immediately.  But don't run from
embarrassment (or become defensive and attack the messenger) -- it's a
powerful tool (which is why we evolved to have it).  It should cause
one to question one's thought processes and consider how to improve
upon them, which is all to the good, isn't it?
Except that xor or ^^ is only a binary operation, there is no
"xor(p1,p2,...)", only "p1 xor p2 xor ..." which can really only be 
understood if you add () to disambiguate the order that the binary ops 
are performed.  Fortunately, xor is associative so it doesn't matter how 
you add the (), you get the same answer.  Try it out, you will discover
that "p1 xor p2 xor ..." is true iff an odd number of the p's are true. 
 As long as you build "p1 xor p2 xor ..." out of binary xor ops that is 
the result you get.  Computing parity is much more common that your 
multi-arg operation.  Besides, all the literature about logic and 
circuit design define "p1 xor p2 xor ..." in terms of binary xor, so 
your trying to buck hundreds of years of consensus.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: -X's auto-(un)quoting?

[Mark A. Biggar]

Matt wrote:
On Sat, 23 Apr 2005 07:25:10 -0400, Juerd <[EMAIL PROTECTED]> wrote:
Matt skribis 2005-04-22 21:55 (-0400):
What about . for each level up you want to go?
instead of 1.say, 2.say, 3.say
you use .say, ..say, ...say
(Ok, I'm just kidding.. really!)

I read your message after I suggested the same thing (I'm too impatient
to read all new messages before sending replies).
Why were you just kidding? I think it's a great idea.

Well I like it too.  I just didn't think anyone would actually go for 
it.   I guess I underestimated how crazy you guys are ;)
After some further thought (and a phone talk with Larry), I now think
that all of these counted-level solutions (even my proposal of _2.foo(),
etc.) are a bad idea. They have a similar problems to constructs like
"next 5;" meaning jump to the next iteration of the loop 5 level out.
Any time you refactor you code and change levels, they break in a
subtle and very hard to debug way, causing mysterious errors.  Just like
the current Perl construct of "labeled loops" so that you can talk about
the target loop explicitly, the proper solution for up-level access to
$OUTER::OUTER::...::OUTER::_ is to create a named binding like
"$uplevel_topic := $_;" at that upper level and then use that to refer 
to it at lower levels.  Beside is "...foo();" seven of eight levels
up?  Any other way than explicit naming is madness; leading to
unreadable and unmaintainable code.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: -X's auto-(un)quoting?

[Mark A. Biggar]

Larry Wall wrote:
I should point out that we're still contemplating breaking .foo() so it
no longer means $_.foo().  I wish there were more keys on my keyboard...
I know it's a bit counter-cultural, but at the moment I'm wondering
if we can make this work instead:
given open 'mailto:[EMAIL PROTECTED]' {
_say(...);
_close or fail;
}
We do, after all, have better ways of declaring private methods and
functions now. so maybe we don't need to reserve _ for that anymore.
And it would save two characters over $_.foo().  But recovering C
I kind of like that, but see below.
programmers will scream, and probably prefer _.foo(), even if it only
saves one character.  Maybe it's time to raid Latin-1 for the next
closest thing to a dot, "middle dot":
given open 'mailto:[EMAIL PROTECTED]' {
·say(...);
·close or fail;
}
But I'm sure some will argue that's too subtle.  (Hi, @Larry.)
I agree, too subtle.
Well, hey, as long as we're looking at Latin-1, we could use superscripts
to indicate nested topic defaults.
given open 'mailto:[EMAIL PROTECTED]' {
say¹(...);
close¹ or fail;
}
Then foo² would be $OUTER::_.foo(), foo³ would be $OUTER::OUTER::_.foo().
Or we go back to .foo always meaning $_.foo and use ¹.foo to call the
first invocant, ².foo to call the second, ³.foo to call the third.
Interestingly, 1.foo, 2.foo, 3.foo etc. would work as ASCII workarounds
if we didn't autobox literal numbers.  
Given I like _.foo(), we can get around the autobox problem by using 
_2.foo(), _3.foo, etc.  Even though those are legal(?) variable names 
I've never seen them used in code anywhere.

But I rather like ` for user-defined literals.  I suppose bare ^
is also available:
given open 'mailto:[EMAIL PROTECTED]' {
^say(...);
^close or fail;
}
This kind of works also.  And it would allow ^2.foo(), ^3.foo(), etc. or 
even ^^.foo(), ^^^.foo(), etc (nah!).

That almost makes sense, given that $^a is like $_.  It also points vaguely
upward toward some antecedent.  I could maybe get used to that, if I
tried real hard for a long time.  Almost makes we wish we could rename
$_ to $^ though.  Hmm...
Too late, maybe.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: CGI.pm url_encoding problem

[Mark A. Biggar]

BÁRTHÁZI András wrote:
Randal,
BÁRTHÁZI> use CGI;
BÁRTHÁZI> set_url_encoding('utf-8');
BÁRTHÁZI> The problem is that "use CGI" automagically initializes the 
parameters
BÁRTHÁZI> *before* I set the encoding of them, so set_url_encoding 
will run too
BÁRTHÁZI> late.

Did I miss the memo where anything outside the list of valid
URI characters needed to be hexified, hence there's no need
for such a URL encoding scheme?  Where is this memo?

Can you write it again with other words? Both Stevan and me are not 
understand.
I believe that the standard for URL's calls for always encoding in utf-8 
but that all non-ascii bytes (bytes with the high bit set) are to be 
further encoded using %xx hex notation.  So the URL is always 
transmitted as an ascii string, but is easily converted into a utf-8 
string simply by converting the %xx codes back into binary bytes.  Thus 
firewalls and proxies need only deal with ascii.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: [pugs] regexp "bug"?

[mark . a . biggar]

Isn't that what the difference between byte-level and codepoint-level access to 
strings is all about.  If you want to work with values that are illegal 
codepoints then you should be working at the byte-level not the 
codepoint-level, at least by default.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


> On Fri, Apr 15, 2005 at 12:56:14AM -0700, Mark A. Biggar wrote:
> : Yes, the value 0x can be stored as either 3 byte UTF-8 string or a 2 
> : byte UCS-2 value, but the Unicode standard specifically says that the 
> : values 0x, 0xFFFE and 0xFEFF are NOT valid codepoints and should 
> : never appear in a Unicode string.  0x is reserved for out-of-band 
> : signaling (such the -1 returnd by getc()) and 0xFFFE and 0xFEFF are 
> : specificaly reserved for out-of-band marking a UCS-2 file as being 
> : either bigendian or littlendian, but are specifically not considered 
> : part of the data.  chr() is currently defined to mean convert an int 
> : value to a Unicode codepoint. That's why I said that chr(65535) should 
> : return an exception, it's an argument error similar to sqrt(-1).
> 
> It has to at least be possible to Think Bad Thoughts in Perl.
> It doesn't have to be the default, though.  But there has to be
> some way of allowing illegal characters to be talked about, or
> you can't write programs that talk about them.  It's like saying
> it's okay to be an executioner as long as you don't kill anyone...
> 
> Larry

Re: [pugs] regexp "bug"?

[Mark A. Biggar]

BÁRTHÁZI András wrote:
Hi,
 >> This code:
 >>
 >> my $a='A';
 >> $a ~~ s:perl5:g/A/{chr(65535)}/;
 >> say $a.bytes;
 >>
 >> Outputs "0". Why?
 >
 >
 > \u is not a legal unicode codepoint.  chr(65535) should raise an 
exception of some type.  So the above code does seem show a possible 
bug. But as that chr(65535) is an undefined char, who knows what the 
code is acually doing.

In my opinion (that can be wrong), \u can be stored as an UTF-8 
character, it should be 0xEF~0xBF~0xBF. If I do it outside the regexp (I 
mean "say chr(65535).bytes", it works well.

Another "bug", I've found, it's not related to the regexps, but still 
unicode character one:

  say chr(0x10).bytes;
The answer:
  pugs: encodeUTF8: ord returned a value above 0x10
And if I start to increment $b, I will get:
  pugs: Prelude.chr: bad argument
I don't understand it, as I thougth that unicode characters in the range 
of 0x-0x7FFF. Is Haskell not supporting the whole set?

There is a Unicode version, called UCS-2, that is just between 
0x-0x, but it still not answer the question.

[...]
Meanwhile, I've found this:
http://std.dkuug.dk/jtc1/sc2/wg2/docs/n2175.htm
It can be the answer to my question.
Yes, the value 0x can be stored as either 3 byte UTF-8 string or a 2 
byte UCS-2 value, but the Unicode standard specifically says that the 
values 0x, 0xFFFE and 0xFEFF are NOT valid codepoints and should 
never appear in a Unicode string.  0x is reserved for out-of-band 
signaling (such the -1 returnd by getc()) and 0xFFFE and 0xFEFF are 
specificaly reserved for out-of-band marking a UCS-2 file as being 
either bigendian or littlendian, but are specifically not considered 
part of the data.  chr() is currently defined to mean convert an int 
value to a Unicode codepoint. That's why I said that chr(65535) should 
return an exception, it's an argument error similar to sqrt(-1).

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: [pugs] regexp "bug"?

[Mark A. Biggar]

BÁRTHÁZI András wrote:
Hi,
This code:
my $a='A';
$a ~~ s:perl5:g/A/{chr(65535)}/;
say $a.bytes;
Outputs "0". Why?
Bye,
  Andras
\u is not a legal unicode codepoint.  chr(65535) should raise an 
exception of some type.  So the above code does seem show a possible 
bug. But as that chr(65535) is an undefined char, who knows what the 
code is acually doing.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: pugs CGI.pm

[mark . a . biggar]

No the bug is using chr() to convert the byte as it appears to be defined as 
taking a Unicode codepoint and returning a UTF-8 character (which will be 
multibyte if the arg is >127), not as taking an int and return an 8 bit char 
with the same value.  If this were perl 5, I'd say you really wanted to use 
pack instead.  We really need both conversion functions and chr() can't be both.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


> Hi,
> 
> BÁRTHÁZI András wrote:
> > It's interesting, and it can be the problem, but I think, the CGI.pm
> > way is not the good solution to decode the URL encoded string: if you
> > say chr(0xE2)~chr(0x82)~chr(0xA2), then they are 3 characters, and
> 
> s:g/A2/AC/?
> 
> I think we've discovered a bug in Pugs, but as I don't know that much
> about UTF-8, I'd like to see the following confirmed first :).
>   # This is what *should* happen:
>   my $x = chr(0xE2)~chr(0x82)~chr(0xAC);
>   say $x.bytes;  # 3
>   say $x.chars;  # 1
> 
>   # This is what currently happens:
>   my $x = chr(0xE2)~chr(0x82)~chr(0xAC);
>   say $x.bytes;  # 6
>   say $x.chars;  # 3
> 
> Comparision with perl5:
>   $ perl -MEncode -we '
> my $x = decode "utf-8", chr(0xE2).chr(0x82).chr(0xAC);
> print length $x;
>   '
>   1 # (chars)
> 
>   $ perl -we '
> my $x = chr(0xE2).chr(0x82).chr(0xAC);
> print length $x;
>   '
>   3 # (bytes)
> 
> 
> --Ingo
> 
> -- 
> Linux, the choice of a GNU | The computer revolution is over. The
> generation on a dual AMD   | computers won. -- Eduard Bloch <[EMAIL 
> PROTECTED]>
> Athlon!| 
> 

Re: pugs CGI.pm

[mark . a . biggar]

The standard for URLs uses a double encoding: A URL is coded in UTF-8 and then 
all bytes with high bits set are written in the %xx format.  Therefore, if you 
just convert each %xx to the proper byte, the result is a valid UTF-8 string. 
You don't need to worry about multi-byte codes, if UTF-8 is the result you want.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]


> Hi!
> 
> > the "XXX -- correct" refers to the :16 (IIRC, Larry said on p6l that he
> > liked that, but I wasn't able to find it in the Synopses).
> > 
> > BTW, Pugs' chr does understand input > 255 correctly:
> >   pugs> ord "€"
> >   8364
> >   pugs> chr 8364
> >   '€'
> Yes, I know it.
> 
> > $decoded does contain valid UTF-8, the problem is Pugs' print/say
> > builtin -- compare:
> It's interesting, and it can be the problem, but I think, the CGI.pm way 
> is not the good solution to decode the URL encoded string: if you say 
> chr(0xE2)~chr(0x82)~chr(0xA2), then they are 3 characters, and chr(0xE2) 
> is a 2 byte coded character in UTF-8 (on a iso-8859-1 terminal, the 
> output can be good, but the internal storage and handling isn't). I mean 
>   if you would like to handle the string in memory, and you query the 
> length of it, the in this way you get 3, but the right is 1.
> 
> So, if there isn't a trick there (for example a function called "byte" 
> that is usable as "chr"), then CGI.pm have to recognize %E2%82%AC as one 
> character and have to decode it with evaluating chr(8364).
> 
> Additionally, detecting character boundings is not so easy, because a 
> character can 2-4 bytes long, and two or more characters can be next to 
> each other.
> 
> Bye,
>Andras

Re: The S29 Functions Project

[Mark A. Biggar]

Rod Adams wrote:
Ashley Winters wrote:
For documentary purposes, can we make that $radians?
multi sub cos (Num +$degrees) returns Num {
   return cos :radians($degrees * PI  / 180);
}
my Num $x = cos :degrees(270);
I have changed the trig functions it to have an optional "base" 
argument. (I'm option to new names for this term.)

The problem I see with your proposal is that both versions have the same 
MMD long name, which only looks at required parameters. We'd have to 
have something like:

   multi sub cos (Num ?$radians = $CALLER:_, Num +$degrees, Num 
+$gradians) returns Num

And then internally dispatch on what is defined and undefined.
Personally I like
   multi sub cos (Num ?$x = $CALLER::_, Num|Str +$base) returns Num
better. You can do:
   our &cos<> := &cos<>.assuming:base('degrees');
to make cosine "degrees only" for your current package.
The Ada language uses a numeric parameter for Base with a default of 
2*pi.  So Base => 360.0 gives degrees, Base => 400.0 gives grads, Base 
=> 1.0 gives bams, etc.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: pull & put (Was: Angle quotes and pointy brackets)

[mark . a . biggar]

stuff & grab :-)

--
Mark Biggar 
[EMAIL PROTECTED] 
[EMAIL PROTECTED] 
[EMAIL PROTECTED]

-- Original message -- 

> On Mon, Dec 06, 2004 at 10:45:22AM -0500, Austin Hastings wrote: 
> : But I'd be willing to rename them to get/put. 
> 
> If I went with "get", the opposite would be "unget" for both historical 
> and huffmaniacal reasons. 
> 
> Larry 

Re: Ordinals, Hashes, and Arrays, oh my

[Mark A. Biggar]

Jonadab the Unsightly One wrote:
Jonathan Lang <[EMAIL PROTECTED]> writes:

ISAM?

From the RDBMS world, a kind of index I think, or something along
those lines.  MySQL for example has a type of table called MyISAM.
Index Sequential Access Method
Invented by IBM in the '60s, provides fast random access to single 
records and then allows for sequential access to the following records 
in sorted order.  It is very similar to the perl 5 sorted hashs.

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Namespaces

[Mark A. Biggar]

Luke Palmer wrote:
Jeff Clites writes:
On Sep 7, 2004, at 6:26 AM, Dan Sugalski wrote:

*) Namespaces are hierarchical
So we can have ["foo"; "bar"; "baz"] for a namespace. Woo hoo and all 
that. It'd map to the equivalent perl namespace of foo::bar::baz.
How does this hierarchical nature manifest? I ask because I don't know 
of any languages which actually have nested namespaces,

Other than, um, well, Perl.

And Ada.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Compile op with return values

[Mark A. Biggar]

Dan Sugalski wrote:
At 11:03 PM -0700 8/21/04, Steve Fink wrote:
I am experimenting with registering my own compiler for the "regex"
language, but the usage is confusing. It seems that the intention is
that compilers will return a code object that gets invoked, at which
time it runs until it hits an C opcode. But what if I want to
return some values from the compiled code?

Here's what's supposed to happen.
The compile op only compiles the code passed in, it doesn't execute it. 
The returned sub object represents the entire code chunk that was 
compiled, and likely ought to be immediately executed itself.

As a perl example, the eval function should give code like:
compiler = compreg "Perl5"
eval_pmc = compile compiler, my_source
eval_pmc()
though the eval_pmc() call ought to check and see if it got anything in 
return.

This does mean that if you skip the invocation of the returned PMC that 
things may not happen. This is fine. And for many languages the returned 
PMC won't actually do anything at all when invoked.

It's important to note that the returned PMC does *not* represent any 
particular sub in the source -- rather it represents the entire source 
module. So if the language was C, for example, the returned PMC wouldn't 
do anything since C doesn't allow you to have code outside functions.
Could not variable initializers require code outside of subs to be
executed even in C?  The issue of elaboration (to borrow a word from
the Ada world) always needs to be considered in cross language
programming.  Only one language can own "main" and some provision always
needs to be made to invoke the outside-of-subs set-up code the other
langauges need.  This issues applies not only to "eval" but to things
like loading dynamic libraries.  The problems that leo and Stephane are
having with gtk are related to this as well, i.e., it looks like parriot 
and Gtk are fighting over who is "main".

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Progressively Overhauling Documentation

[mark . a . biggar]

>OK, there's one non-incremental idea: documentation that you can write 
>in one place and display in some completely different order.  (Shades of 
>literate programming!)  And although there are good reasons for keeping 
>the docs in the same file as the code, there are equal but opposite 
>reasons to keep it separate (if it's all piled up at the end of the file 
>anyway).  What gets presented to the user as "one page" could be bits 
>and pieces from all over the place.
Literate Programming handles reordering by allowing you to specify a 
hirearchical number as part of each doc piece.  This could be easily a
dded to POD.  Something like:
=(1.2.1) begin ...
just default any unspecified values to incrementing the last one.
A simple POD processor could just ignore them and a fancy one could 
use them to reorder the section accordingly.
--
Mark Biggar 
[EMAIL PROTECTED]

Re: undo()?

[mark . a . biggar]

Sorry I did mean temp.


--
Mark Biggar 
[EMAIL PROTECTED]


-- Original message -- 

> Mark A. Biggar skribis 2004-06-29 9:07 (-0700): 
> > Besides we already have MTOWTDI with local() and hypotheticals. 
> 
> I thought temp replaced local. If not, how do they differ? (is temp for 
> lexicals, local for globals (and why would that make sense?)) 
> 
> 
> Juerd 

Re: undo()?

[Mark A. Biggar]

Rafael Garcia-Suarez wrote:
Michele Dondi wrote:
I must say I've still not read all apocalypses, and OTOH I suspect that
this could be done more or less easily with a custom function (provided
that variables will have a method to keep track of their history, or, more
reasonably, will be *allowed* to have it), but I wonder if Perl6 may
include a builtin undo() function to recover values prior, say, to the
last assignement (or push() or, etc. etc.[*]) 

Difficulties: define "history" of a function w.r.t. threads; closures;
and system side-effects (writing to files, locking them etc.)
In other words, if you want a transaction/rollback mechanism, use a
suitable transaction library that fits your needs, not a half-baked
kludge built into the base language.
Besides we already have MTOWTDI with local() and hypotheticals.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Strings internals

[mark . a . biggar]

Yeah, but I believe that at least Unicode has one of the four that they suggest
be used for non-locale specific comparisons (canonical decomposition form).  
So pick that one for the core and provide the others (if necessary) as library 
functions.

--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]


> At 4:30 PM + 6/16/04, [EMAIL PROTECTED] wrote:
> >Do we want a Normalization function here as well.  If you have that 
> >you can use a binary compare (at least for eq/ne).
> 
> Yeah, we probably do. The question is always "Which normalization" 
> since there are at least four for Unicode and two for ISO-2022. (Or 
> something like that--I don't think I remembered the ISO number right)
> 
> >
> >>  The charset vtable needs to handle get/set grapheme, get/set
> >>  substring, up/down/titlecase, and (possibly) comparison. Charsets
> >>  also have a separate grapheme classification requirement (for
> >>  regexes) but we'll put that off for now.
> 
> 
> -- 
>   Dan
> 
> --it's like this---
> Dan Sugalski  even samurai
> [EMAIL PROTECTED] have teddy bears and even
>teddy bears get drunk

Re: Strings internals

[mark . a . biggar]

Do we want a Normalization function here as well.  If you have that you can use a 
binary compare (at least for eq/ne).

--
Mark Biggar
[EMAIL PROTECTED]



> The charset vtable needs to handle get/set grapheme, get/set 
> substring, up/down/titlecase, and (possibly) comparison. Charsets 
> also have a separate grapheme classification requirement (for 
> regexes) but we'll put that off for now.

Re: Yadda yadda yadda some more

[mark . a . biggar]

> Austin Hastings wrote:

> >my int $i = ...; # Fails at compile time -- no good conversion.
> > 
> >my Int $i = ...; # Warns at compile time, fails at runtime.
> 
> I don't get the reasoning here. If Yada Yada Yada is to indicate code 
> that you haven't written yet, it should never fail at compile time 
> unless it's impossible to compile the program without knowing what that 
> code is, so
> 
> my int $i = ...;
> 
> should compile. The problem would arise when you actually tried to run 
> that particular bit of code, which may well look to Parrot like 'die 
> horribly'.

Or. not so horribly.  If I'm in the perl debugger, I'd want that to be a breakpoint
and give me the option to type in a evaluable string to replace it.  So it should 
throw a properly marked exception that an outer context can do something
with.

--
Mark Biggar
[EMAIL PROTECTED]

Re: Event design sketch

[mark . a . biggar]

You wrote:
>i don't think there is a need for all those variants. why would alarm
>need any special opcode when it is just a timer with a delay of abs_time
>- NOW? let the coder handle that and lose the extra op codes.

No, you don't want to do it that way.  Becasue you want to make the latency
between getting the abs_time, doing the substract and actually setting up
the time as small, as possible you almost have to do this operation as
a builtin op.  In fact you can argue that you want to lock out async events
while doing it as well.

--
Mark Biggar
[EMAIL PROTECTED]

Re: A12: default accessors and encapsulation

[mark . a . biggar]

> On 4/19/04 3:58 PM, Austin Hastings wrote:
 
> One work-around might be an alternate kind of default accessor that doesn't
> allow assignment:
> 
> $dog.name # get
> $dog.name('foo')  # set
> $dog.name = 'foo' # compile-time error

I think we already have this.  Just define a non-rw attribute and then
add your own writer as a multi-method.

  has Str $.name;
  multi method name(Str $n) {$.name = $n;}

--
Mark Biggar
[EMAIL PROTECTED]

Re: Apocalypse 12

[Mark A. Biggar]

Brent 'Dax' Royal-Gordon wrote:

chromatic wrote:

Perl.com has just made A12 available:


I started reading it last night, and ended up going to bed before I was 
finished.  But I just wanted to say that this:

With this dispatcher you can continue by saying "next METHOD".

is the sort of genius that makes me glad Larry's designing this 
language.  Well done!

Yeah, remmeber from A4 that flow control stuff like "next", "leave",
"return" are semantically a form of exception throw and so are actaully
dymanically (not lexically) scoped (although the compiler is free to
optimize if the target is in the lexical scope of the construct or
vice versa).
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Apocalypse 12

[Mark A. Biggar]

Brent 'Dax' Royal-Gordon wrote:

chromatic wrote:

Perl.com has just made A12 available:


I started reading it last night, and ended up going to bed before I was 
finished.  But I just wanted to say that this:

With this dispatcher you can continue by saying "next METHOD".

is the sort of genius that makes me glad Larry's designing this 
language.  Well done!

Yeah, remmeber from A4 that flow control stuff like "next", "leave",
"return" are semantically a form of exception throw and so are actaully 
dymanically (not lexically) scoped (although the compiler is free to
optimize if the target is in the lexical scope of the construct or
vice versa).

--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Load paths

[mark . a . biggar]

Dan wrote:
> At the moment I'm thinking of the load path as an array of subs that 
> get passed in the file being looked for and return... something. I'm 
> not sure what, though.

Don't reinvent the wheel here.  Obviously what should be return is an URI.
If we start off only supporting "file://..." okay, but eventually we
should support full over-the-net URI's (http:, https:, ftp:, etc.).


--
Mark Biggar
[EMAIL PROTECTED]

Re: [perl #27690] Numeric comparison bug

[mark . a . biggar]

The real problem is that you always want to use exactly the same code for
ALL cases of string-to-float conversion.  The first public example of this
problem was the FORTRAN II compiler from IBM in the 60's.  The compiler and
the IO library was written by two different people and so constants in
program code didn't match those read in from IO, OOPS!  you'd think
people would remember and learn from the past.  By exactly the same,
I mean exactly the same machine code (hardware floating point status and rounding mode 
bits included) not just the same HL source code.  I.e., You
need exactly one routine, compiled only once and used EVERYWHERE.  It also pays
to have a single routine for the other direction that has the property:
S = ftos(atof(S)) and F = atof(ftoa(F)).  Otherwise you get obscure
very hard to find bugs.

--
Mark Biggar
[EMAIL PROTECTED]
> Its the old problem of rounding errors in floating point arithmetic.
> 
> In string_to_num() in src/string.c,
> f = f * sign * pow(10.0, exponent); /* ugly, oh yeah */
> 
> Which in this case translates to 12.0*-1*0.1 which is -1.2000...2 != -1.2.
> 
> I replaced this bit of code from a block I found in mysql. I only tested 
> this
> on linux, but it seems to do the trick. See attached.
> 
> Leopold Toetsch wrote:
> 
> >Simon Glover <[EMAIL PROTECTED]> wrote:
> >
> >  
> >
> >> This code:
> >>
> >>
> >
> >  
> >
> >>new P0, .PerlNum
> >>set P0, -1.2
> >>new P1, .PerlString
> >>set P1, "-1.2"
> >>eq_num P0, P1, OK
> >>print "not "
> >>OK: print "ok\n"
> >>end
> >>
> >>
> >
> >  
> >
> >> [And yes, I'm well aware of the problems inherent in doing floating point
> >>  comparisons.
> >>
> >>
> >
> >Breakpoint 1, Parrot_PerlNum_cmp_num (interpreter=0x82654f0, pmc=0x40305850,
> >value=0x40305838) at perlnum.c:301

> >301 diff = PMC_num_val(pmc) - VTABLE_get_number(interpreter, value);
> >(gdb) n
> >302 return diff > 0 ? 1 : diff < 0 ? -1 : 0;
> >(gdb) p diff
> >$1 = 2.2204460492503131e-16
> >(gdb)
> >
> >  
> >
> >> Simon
> >>
> >>
> >
> >leo
> >  
> >
> 

> *** tmp/parrot/src/string.c   Sat Mar  6 03:00:06 2004
> --- parrot/src/string.c   Wed Mar 17 12:24:02 2004
> ***
> *** 1836,1844 
>   int exp_sign = 0;
>   INTVAL in_exp = 0;
>   INTVAL in_number = 0;
> ! FLOATVAL exponent = 0;
>   INTVAL fake_exponent = 0;
>   INTVAL digit_family = 0;
>   
>   while (start < end) {
>   UINTVAL c = s->encoding->decode(start);
> --- 1836,1845 
>   int exp_sign = 0;
>   INTVAL in_exp = 0;
>   INTVAL in_number = 0;
> ! INTVAL exponent = 0;
>   INTVAL fake_exponent = 0;
>   INTVAL digit_family = 0;
> + FLOATVAL exp_log=10.0, exp_val=1.0;
>   
>   while (start < end) {
>   UINTVAL c = s->encoding->decode(start);
> ***
> *** 1849,1855 
>   
>   if (df && df == digit_family) {
>   if (in_exp) {
> ! exponent = exponent * 10 + s->type->get_digit(s->type,c);

>   if (!exp_sign) {
>   exp_sign = 1;
>   }
> --- 1850,1856 
>   
>   if (df && df == digit_family) {
>   if (in_exp) {
> ! exponent = exponent + s->type->get_digit(s->type,c);
>   if (!exp_sign) {
>   exp_sign = 1;
>   }
> ***
> *** 1906,1912 
>   
>   exponent = fake_exponent + exponent * exp_sign;
>   
> ! f = f * sign * pow(10.0, exponent); /* ugly, oh yeah */
>   }
>   
>   return f;
> --- 1907,1936 
>   
>   exponent = fake_exponent + exponent * exp_sign;
>   
> ! if(exponent < 0) {
> ! exponent = -exponent; 
> ! exp_sign=-1;
> ! }
> ! 
> ! for (;;) {
> ! if (exponent & 1) {
> ! exp_val *= exp_log;
> ! exponent--;
> ! }
> ! if (!exponent)
> ! break;

> ! exp_log *= exp_log;
> ! exponent >>= 1;
> ! }
> ! 
> ! if(exp_sign < 0)
> ! f /= exp_val;
> ! else
> ! f *= exp_val;
> ! 
> ! 
> ! if(sign < 0)
> ! f = -f;
>   }
>   
>   return f;

Re: Method caches

[mark . a . biggar]

Don't forget about cache invalidation on dynamic method redefinition.

--
Mark Biggar
[EMAIL PROTECTED]
> Okay, so it's method cache time.
> 
> First important note: I've never done this before (I think my 
> antipathy towards objects might've given everyone just the tiniest 
> clue :) so pointers to good docs and papers on this would be much 
> appreciated.
> 
> My current thinking, based entirely on the "Hmmm, if I had no clue 
> there was any history here, what would I do?" school of design, is to 
> do this:
> 
> Method cache is an array of arrays of cache entries.
 
> This seems... too simple, so I'm sure I'm missing something besides 
> the potential massive memory usage. So, by all means, have at it.
teddy bears get drunk

Re: Latin-1-characters

[mark . a . biggar]

Another possibility is to use a UTF-8 extended system where you use values over 
0x10 to encode temporary code block swaps in the encoding.  I.e.,
some magic value means the one byte UTF-8 codes now mean the Greek block
instead of the ASCII block.   But you would need broad agreement for that to
work.  As Dan said this really need a separation between encoding and character set.

--
Mark Biggar
[EMAIL PROTECTED]
> At 12:28 AM +0100 3/16/04, Karl Brodowsky wrote:
> >Anyway, it will be necessary to specify the encoding of unicode in
> >some way, which could possibly allow even to specify even some 
> >non-unicode-charsets.
> 
> While I'll skip diving deeper into the swamp that is character sets 
> and encoding (I'm already up to my neck in it, thanks, and I don't 
> have any long straws handy :) I'll point out that the above statement 
> is meaningless--there *are* no Unicode non-unicode charsets.
> 
> It is possible to use the UTF encodings on non-unicode charsets--you 
> could reasonably use UTF-8 to encode, say, Shift-JIS characters. 
> (where Shift-JIS is both an encoding and a character set, and it can 
> be separated into pieces)
> 
> It's not unwise (and, in practice, at least in implementation quite 
> sensible) to separate the encoding from the character set, but you 
> need to be careful to keep the separation clear, though many of the 
> sets and encodings don't go out of their way to help with that.
> -- 
>  Dan
> 
> --"it's like this"---
> Dan Sugalski  even samurai
> [EMAIL PROTECTED] have teddy bears and even
>teddy bears get drunk

Re: Dates and Times

[mark . a . biggar]

> What I'm thinking we may want to do is provide a minimal 
> interface--turn the time integer into a string rep or split out into 
> an array, something like:
> 
>  localtime Sx, Iy
>  gmtime Sx, Iy
> 

You almost have to provide at least these, as you have to deal with
how various OS's handle the hardware clock.  Windows insists that the
hardware clock be set to localtime, Solaris and most U*x's insist that
it be set to GMT, while Linus supports setting it to either.  This also
means that the simple second-sense-epoc time() may not be so simple
after all.

--
Mark Biggar
[EMAIL PROTECTED]

Re: Exegesis 7: Overflow Fields

[Mark A. Biggar]

Damian Conway wrote:

But that means I have to pre-process data lists that just happen to
contain empty strings so that they won't disappear on me.


Huh? An empty string already *has* disappeared on you. ;-)

 > This seems to violate least surprise.

I'd be much more surprised if an empty string *didn't* disappear.
After all, you wouldn't expect:
$str1 = "nothing" . "to" . "see";

to be different from:

$str1 = "nothing" . "" . "to" . "" . "see";
I also don't expect

$x = '';
$y = " $x ";
to assign '' to $y either, but that's the equlvalent of what you say
form() will do.
I was more worried about arrays of items some of which are empty strings
and having items disappear out my repost because form() throws them
away.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: Exegesis 7: Overflow Fields

[Mark A. Biggar]

Damian Conway wrote:

Mark A. Biggar wrote:

What if I want to interpolate an empty string and let the fill 
characters work?


Then you interpolate a single fill character instead of the empty string.
But that means I have to pre-process data lists that just happen to
contain empty strings so that they won't disappear on me.  This seems to
violate least suprise.
This message brought to you by SFTPODAES
"Society For The Prevention of Descrimination Against Empty Strings".
Motto: Empty Strings Are Valid Data Too.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]