Re: type sigils redux, and new unary ^ operator
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: Smart match table
-- 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: s29 and Complex numbers
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: comment scope
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: Perl 6 built-in types
> 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: Scans
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
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
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: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
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: Numerification of Order:: constants
-- 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: Implicit current-index variable, scoped inside for-loops
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: special named assertions
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: signature subtyping and role merging
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: Edge case: incongruent roles
-- 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: Edge case: incongruent roles
-- 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: named sub-expressions, n-ary functions, things and stuff
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: Y not
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: Nested captures
> 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: rules trouble
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: split /(..)*/, 1234567890
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: trait and properties thru getter/setters
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: reduce metaoperator on an empty list
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: reduce metaoperator on an empty list
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
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 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
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: Perl development server
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: comprehensive list of perl6 rule tokens
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: comprehensive list of perl6 rule tokens
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
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: %hash1 >>...<< %hash2
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: Elimination of Item|Pair and Any|Junction
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: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]
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: Set operators in Perl 6 [was Re: $object.meta.isa(?) redux]
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: Time::Local
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: my $pi is constant = 3;
--
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: @array = $scalar
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: conditional wrapper blocks
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: Stringification, numification, and booleanification of pairs
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: [perl #17490] Magic is useless unless verifiable.
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
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: Look-ahead arguments in for loops
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: Look-ahead arguments in for loops
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: multiline comments
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: Copyrights in file headers
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: This week's summary
On Mon, Jun 09, 2003 at 01:26:22PM +0100, Piers Cawley wrote:
Multimethod dispatch?
Assuming I'm not misunderstanding what Adam is after, this has come up
before (I think I asked about value based dispatch a few months back)
and I can't remember if the decision was that MMD didn't extend to
dispatching based on value, or if that decision hasn't been taken yet.
If it's not been taken, I still want to be able to do
multi factorial (0) { 1 }
multi factorial ($n) { $n * factorial($n - 1) }
That's a bad example, as it's really not MMD. It's a partially
pre-memoized function instead.
Which brings up a issue. Is it really MMD if you're only dispatching on
a single invocant? Most of the examples I've seen for MMD so far use
only a single invocant and are really either regular dispatch or simple
overloading instead. MMD only becomes really interesting if you
have multiple invocants possibly with best-match signature matching
involved.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Class instantiation and creation
Dan Sugalski wrote: Well, we can make objects and we can call methods on objects (at least the interface is specified, if not actually implemented) but actually building classes to make objects out of is still unspecified. So, time to remedy that, after which I hope we can build at least a simple "ParrotObject" class. The issue is metadata. How do you declare a class' inheritance hierarchy, its interfaces, its attributes, and its type? (At the very least, there's probably more) I can see the following . 1) A class subclasses a single parent. 2) A class subclasses a single parent and adds attributes 3) A class subclasses multiple parents 4) A class subclasses multiple parents with extra attributes 5) A class adds attributes at runtime 6) A class adds parents at runtime Why not just have 1, 2 and 3 be degenerate cases 4? We're going to need to be able to do all these at runtime as well as load time, the question is how. It's possible to just go ahead and do it *all* at runtime, and have no compile time component at all--just a series of "newclass, addparent, addattribute" ops, assuming those are the op names we go with. Classes just get created at code initialization time or something. Would "adparent" replacate the metadata of the parent into the metadata of the child or will we need to walk the inheritence tree to get the metadata about inherited attributes? Part of me wants to go all-metadata for cases 2, 3, and 4, since I'm wary of the issues of doing what should be an atomic action in multiple ops. There's a loss of atomicity at the program level there, and if the classes override some of the actions (if we even allow that--does anyone allow overloading the subclassing operation?) it could get messy. #5 really has to be metadata based, as it'll be expensive as it is. Refiguring the attribute array is a constant-time operation, more or less, so doing it 6 times to add in 6 attributes seems... suboptimal. If we don't do it with metadata we'll need ops that allow adding in multiple elements in one go. Another possibility is to have an "addslots N" op to pre-extend the class and only dynamically extend if necessary. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: pull & put (Was: Angle quotes and pointy brackets)
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: The S29 Functions Project
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: pugs CGI.pm
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: pugs CGI.pm
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] regexp "bug"?
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] regexp "bug"?
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"?
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: CGI.pm url_encoding problem
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: -X's auto-(un)quoting?
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?
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: Pugs 6.2.0 released.
[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: Pugs 6.2.0 released.
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: available operator characters
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: Nested captures
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: Apocalypse 12
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
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: A12: default accessors and encapsulation
> 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: Yadda yadda yadda some more
> 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
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: Strings internals
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: Strings internals
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: undo()?
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: undo()?
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: Progressively Overhauling Documentation
>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: Compile op with return values
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: Namespaces
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: Ordinals, Hashes, and Arrays, oh my
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: Macro arguments themselves
Alex Burr wrote:
[EMAIL PROTECTED] (Luke Palmer) writes:
I would hope the former. However, what about this compile-time
integral power macro[1]?
macro power ($x, $p) {
if $p > 0 {
{ $x * power($x, $p-1) }
}
else {
{ 1 }
}
}
That would hopefully turn:
my $var = 10;
print power $var, 4;
Into
print($var * $var * $var * $var * 1);
The complete answer to this would be partial evaluation. Partial
evaluators exist for langauges such as lisp, ML, and even C. See
http://www.dina.dk/~sestoft/pebook/pebook.html
A partial evaluator simplifies a function with respect to some of its
inputs, if possible. This can be quite powerful: If P is a partial
evaluator, I an interpreter, and C some code, the P(I,C) compiles C
(in a rudimentary sort of way) and P(P,I) produces a compiler. But
code has to be written with an eye to making it possible to simplify it,
otherwise you just get the original code back.
In theory you could write one as a perl6 macro, although it would be
more convenient if there was someway of obtaining the syntax tree of a
previously defined function other than quoting it (unless I've missed
that?).
But I confidently predict that no-one with write a useful partial
evaluator for perl6. The language is simply too big.
As it is currently defined the default "is parsed" trait includes
evaluating the arguments before the marco is called, so the above
macro doesn't do what you want with out adding some magic.
One way to do what you want is to use a string returning macro with
an "is parsed" trait that return the unevaluated args as strings and
then concat up the string for the expression you want.
Another possibility is a built-in trait orthoginal to "is parsed"
that turns off argument evaluation and allow the args to be passed
in as syntax trees, allowing the macro to built the syntax tree
to be returned.
I imagine that by the time all is done there will be a whole set
if trait definitions to make various types of macros easy to do.
Which brings us back to the need for a way to bundle up a set of
traits and give it a name.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Event handling (was Re: [CVS ci] exceptions-6: signals, catch a SIGFPE (generic platform)
Nicholas Clark wrote: On Thu, Jul 17, 2003 at 08:40:44PM -0400, Benjamin Goldberg wrote: Actually, I'm thinking of something like the following... suppose the original code is like: label_foo: loop body branch_address: branch label_foo Add in the following: e_handler_foo: .local PerlHash handlers_with_events .local int i_have_an_event handlers_with_events = i_have_an_event = handlers_with_events[cur_thread] unless i_have_an_event, label_foo bsr dequeue_events_and_handle_them_all branch label_foo And then, when an event occurs, replace "branch label_foo" with "branch e_handler_foo". When there are no events queued, for any thread, then we change "branch e_handler_foo" back into "branch label_foo", for speed. Do we need to do this last bit explicitly? Or can we do it lazily - each time we get called to e_handler when there are no longer events, we change back that instruction. Or is this already done this way? Some issues related to this scheme: 1) In a highly secure mode, you don't want self modifing code. we need a way to lock down code into RO memory when security is important. A similar problem exists with modifing vtables on the fly. 2) Making that exception safe may be a problem. 3) Is parriot byte code suppose to be position independent? Having all code be PIC makes dynamic loading simpler. 4) As parriot ops are rather CISC anyway, maybe a special op that checks for events and takes one of two branches could be used here. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Multimethod dispatch function installation issues
Dan Sugalski wrote: Okay, here's an issue for everyone. I'm writing the MMD subsystem, at least the parts needed for operator overloading, and I'm coming across the need to defer adding functions. For example, the Float class has functions for the Integer class, and vice versa, and we can't guarantee that both classes are loaded in when the functions are going to be installed. I don't want to discard the functions, though, since they should be in force when both classes are available. So, I've two options: 1) When one or both of the classes a MMD function is installed for don't exist, we give them both class numbers (but don't load them) so when the classes *are* later loaded they already have numbers 2) We put the functions in a 'pending' list and install them when (if) the missing classes are later loaded I can see it going either way, and I'm not sure which would be better. (It's important to note that this is strictly an internal issue, since bytecode'll never know one way or the other) Opinions? Isn't there also the option to force load the missing class(es) recursively? -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: The Block Returns
Jonathan Scott Duff wrote:
On Thu, Oct 02, 2003 at 11:39:20AM +0100, Dave Mitchell wrote:
On Thu, Oct 02, 2003 at 04:15:06AM -0600, Luke Palmer wrote:
So the question is: What happens when indexof isn't on the call chain,
but that inner closure is?
But how can the inner closure be called if not via indexof?
I believe that's exactly what Luke's original example was
illustrating.
On Thu, Oct 02, 2003 at 01:59:26AM -0600, Luke Palmer wrote:
So, I must ask, what does this do:
sub foo() {
return my $self = {
print "Block";
return $self;
}
}
foo() returns a closure that contains code that returns from the foo()
subroutine (the line that says "return $self") When that closure is
then called ...
my $block = foo;
print "Main";
$block();
... foo() is no longer executing.
That is, the block returns from a function that's not currently
executing.
Will the output be: a)
Can't 'return' from closure Block
b)
Main
Block
Can't 'return' from closure Block
(just like (a) but runtime)
c)
Main
Block
(the block's return returns from the main program, or whatever function
is currently executing)
d)
Main
Block
Main
Block
Main
Block
...
(the block closes over the function's return continuation)
I would expect (a) to happen, but (d) has some interesting
possibilities. And wouldn't (d) be:
Main
Block
Block
Block
...
?
Actually, if your last parenthetical were true, it would be
Main
Block
End
because though foo()'s return continuation is closed over, it only
gets executed once and then returned. I.e., to get "Block" again,
you'd need to execute the return value of $block.
my $block = foo;
print "Main";
$b2 = $block();
$b3 = $b2();
$b4 = $b3();# etc.
print "End";
or for the infinite version:
my $block = foo;
print "Main";
$block = $block() while 1;
print "End"; # we never get here
Or am I missing something?
Possibly, I brought a similar example to Larry a while ago and he said
that creating a closuer and assigning to a variable (or even returning
it), may need to be an exception to the "sub" required for "return"
rule, exactly because of this dangling context problem. So in the above
example, the return is from the local closure not the from foo().
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: The Block Returns
Austin Hastings wrote:
-Original Message-
From: Luke Palmer [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 10:23 PM
To: Jeff Clites
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: The Block Returns
Jeff Clites writes:
Speaking to the practical side, I have written code that has to
disentangle
itself from the failure of a complex startup sequence. I'd love to be
able
to build a dynamic exit sequence. (In fact, being able to do &block
.=
{ more_stuff(); }; is way up on my list...)
I've wanted to do that sort of thing before, but it seems simpler
(conceptually and practically) to build up an array of cleanup
subs/blocks to execute in sequence, rather than to have a .= for
blocks. (Another reason it's handy to keep them separate is in cases in
which each needs to return some information--maybe a status which
determines whether to proceed, etc.)
But this is already supported, in its most powerful form:
wrap &block: { call; other_stuff() }
Hmm, no.
That does a call, which presumes a return, which burns up who-knows-how-many mips. Given that the compiler is being forced to remember the code in case someone overloads the semicolon operator, or whatever, I don't think it's unreasonable to catenate the .source values of various blocks, and that seems a reasonable behavior for infix:.=(Block, Block) {...}.
Especially since the other way turns into:
macro atexit(Block $b) {
get_the_current_sub().eval("my &block = {};")
unless defined █
wrap &block: { call; $b(); };
}
Which makes two calls per additional whosit.
Frankly, I think I'd rather see:
macro atexit($code) is parsed(/{ * }/) {
get_the_current_sub().eval("my $block;")
unless defined $block;
$block .= $code;
}
macro return($retval) {
eval($block) if defined $block;
leave Routine, $retval;
}
But that imposes eval() pretty frequently. Better to provide some lower-level hackish way to agglutinate Blocks.
Isn't this one of the prime examples of why CPS is being use, it allows
for Tail Recursion Optimization. With TRO all your worries about
overhead do to the wrap go away.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: [CVS ci] hash compare
Nicholas Clark wrote: On Wed, Nov 12, 2003 at 01:57:14PM -0500, Dan Sugalski wrote: You're going to run into problems no matter what you do, and as transcoding could happen with each comparison arguably you need to make a local copy of the string for each comparison, as otherwise you run the risk of significant data loss as a string gets transcoded back and forth across a lossy boundary. I think that this rules out what I was going to ask/suggested, having read Leo's patch. I was wondering why there wasn't a straight memcmp of the two strings whenever their encoding were the same. I presume that there are some encodings where two different binary representations are considered "equal", hence we can't blindly assume that a byte compare is sufficient. It's even worse then that. Unicode has characters that have several different code-point values, even ignoring the encoding issue. See the Unicode standard for a discussion of normalization and string comparisons. Unicode has what are called compatibility characters, where when they added a character set to Unicode as a lump then left in characters that were duplicated elsewhere so that the included set could still be a contiguous code-point range. And there are pre-composed versions of characters that are also buildable from a base character plus one or more combining characters, E.g., the first 256 code-points of Unicode are the same as ASCII Latin-1, so code-point 0x00E4 is the character lower-a-umlaut, but that can also be represented by the pair of code-points 0x0061 & 0x0308 which is lower-a followed by umlaut-combining. This is why Unicode defines Normalization rules for preprocessing a string before comparison. And even when the sequence of Unicode code-points is the same, some encodings have multiple byte sequences for the same code-point. For example, UTF-8 has two ways to encode a code-point that is larger the 0x (Unicode as code-points up to 0x10FFF), as either two 16 bit surrogate code points encoded as two 3 byte UTF-8 code sequences or as a single value encoded as a single 4 or 5 byte UTF-8 code sequence. Not to mention malformed UTF-8 codes where a short value is encoded using a longer encoding by not stripping off leading zero bits. In general to compare Unicode you have to normalize both string first. As Dan said in his blog, Unicode support is a big pain. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [CVS ci] hash compare
Mark A. Biggar wrote: 0x (Unicode as code-points up to 0x10FFF), as either two 16 bit Oops that should be 0x10^^^ -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Control flow variables
Luke Palmer wrote:
I was reading the most recent article on perl.com, and a code segment
reminded me of something I see rather often in code that I don't like.
Here's the code, Perl6ized:
... ;
my $is_ok = 1;
for 0..6 -> $t {
if abs(@new[$t] - @new[$t+1]) > 3 {
$is_ok = 0;
last;
}
}
if $is_ok {
push @moves: [$i, $j];
}
...
What's wrong with:
for 0..6 -> $t {
if abs(@new[$t] - @new[$t+1]) > 3 {
push @moves: [$i, $j];
last;
}
}
I see this idiom a lot in code. You loop through some values on a
condition, and do something only if the condition was never true.
$is_ok is a control flow variable, something I like to minimize. Now,
there are other ways to do this:
if (0..6 ==> grep -> $t { abs(@new[$t] - @new[$t+1]) })
{ ... }
But one would say that's not the cleanest thing in the world.
and very unreadable, (even if that's heresy :-) )
Python pulled this idiom out in to the syntax (yay them), with C
on loops. The else block on a python loop executes only if you never
broke out of the loop. That's a great idea.
So, in Perl's postmodern tradition, I think we should steal that idea.
I'm a little uneasy about calling it C, though. Maybe C
would do, making the example:
for 0..6 -> $t {
if abs(@new[$t] - @new[$t+1]) > 3 {
last;
}
FINISH {
push @moves: [$i, $j];
}
}
Violates least surprise, if the 'if' is true for '$t == 6' due
to the ambiguity between 'last' on '$t==6' and falling out the bottom
of the loop. Maybe you want FINISH_EARLY instead?
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Control flow variables
OOPS, totally miss-read your code, ignore my first part of my last message. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [perl #24769] [PATCH] mem_sys_allocate_executable - initial draft
Leopold Toetsch wrote: Jonathan Worthington <[EMAIL PROTECTED]> wrote: The other question is does Parrot care about the memory being zero'd out? Isn't necessary. Executable mem is filled with ops anyway. Currently it is zeroed to aid debugging a bit. It should be filled up with trap operations of some kind finally I think. Wouldn't that suggest that zero ought to be a trap code? -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Exegesis 7: Overflow Fields
Larry Wall wrote: On Sat, Feb 28, 2004 at 11:59:15AM -0800, Gregor N. Purdy wrote: : Smylers -- : : So, what I'm looking for is more explicit phrasing around "immediately : above". In the example, the column range for the overflow field is : exactly the same as that of the $method field in the prior "picture". : But, what does it do if it doesn't match *exactly*? Is it an error, : does it have some heuristics to guess? What are the edge cases? Well, obviously this is one of those places where the implementation is the spec. :-) Arn't there cases where the overflow field want to be bigger then the first field? Something the ends up looking like: LABEL: texttexttextexttexttext texttextexttextetexttexttextte xttexttexttexttexttexttextttex where LABEL is in one field and text... is in an oveflow block? -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Exegesis 7: Overflow Fields
Luke Palmer wrote:
Mark A. Biggar writes:
Larry Wall wrote:
On Sat, Feb 28, 2004 at 11:59:15AM -0800, Gregor N. Purdy wrote:
: Smylers --
:
: So, what I'm looking for is more explicit phrasing around "immediately
: above". In the example, the column range for the overflow field is
: exactly the same as that of the $method field in the prior "picture".
: But, what does it do if it doesn't match *exactly*? Is it an error,
: does it have some heuristics to guess? What are the edge cases?
Well, obviously this is one of those places where the implementation
is the spec. :-)
Arn't there cases where the overflow field want to be bigger then the
first field? Something the ends up looking like:
LABEL: texttexttextexttexttext
texttextexttextetexttexttextte
xttexttexttexttexttexttextttex
where LABEL is in one field and text... is in an oveflow block?
Yeah. I'd do that this way:
form '{<<<}: {<<<<<<<<<<<<â}',
$label, $text,
'{â<<<<<<<<<<<<<<<<<<â}',
$text,
'{}';
I think that works... I only read E7 through once and quickly, so I'll
have to double check that against Perl6::Form;
Expect wouldn't that produce a extra blank line if $text is short? Or
do follow on blocks automatically do the perl 5 '~' thing? Overflow
blocks as well? Do we need a :option to control that. What if I
want a follow-on or overflow block to not suppress extra blank lines?
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Exegesis 7: Overflow Fields
Damian Conway wrote: Mark A. Biggar wrote: Expect wouldn't that produce a extra blank line if $text is short? Nope. Formats only generate text lines if at least one of their fields interpolates at least one character. Damian What if I want to interpolate an empty string and let the fill characters work? If the above is the default I still need someway to turn it off. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Exegesis 7: Overflow Fields
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]
Re: Exegesis 7: Overflow Fields
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: Dates and Times
> 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: Latin-1-characters
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: Method caches
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: [perl #27690] Numeric comparison bug
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: Load paths
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: RFC 180 (v1) Object Class hooks into C
Hildo Biersma wrote: > > > =head1 ABSTRACT > > > > There needs to be a way for an object class to define C format > > specifiers for use in formatting objects into strings with C and > > C. > > I find myself agreeing with your sentiment, but the approach in this RFC > is not sufficiently general. Why only provide hooks for printf, not for > formats and output disciplines? > > I think a better approach would be that the to-string operator for > objects should get an optional 'width' parameter. In normal cases > (stringification, interpolation), that argument would not be set. In > printf and formats, but maybe also by specific file disciplines (e.g. > the 72-character-wide output file), the width parameter would be set and > indicate how wide the object may print its data. Thanks you, I had forgot about formats. Note that more then just width information is needed in the general case (and I should add more examples to the RFC to show this). Take the set of printf specifiers that would be needed for the Math::BigFloat package. You would want to define %f, %e and %g at least with all the decimal point placement, padding and sign stuff. Even formats allow for 'basic print using' picture like fields (which I believe get turned into printf specifiers internally) that have more information then just width. In addition I intended that arbitrary object classes could define unique to the class printf specifiers that contain anything the writer wants to define between the % and the final letter. I will write a second version of the RFC over the weekend to address these issues. -- Mark Biggar [EMAIL PROTECTED]
Re: Generalizing ?? !!
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: Floating point comparisons
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: new article, "A Romp Through Infinity"
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: how to write literals of some Perl 6 types?
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: Support for ensuring invariants from one loop iteration to the next?
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.
