Re: Regex interpolation
Use {...}. as the string returned is reinterpreted as a regex, if it consists
of the single quoted string then it's a literal, but you must include the
single quotes in the result returned. E.g.,
{ my $x = funct($a, $b, $c); '$x';}
Mark Biggar
--
m...@biggar.org
mark.a.big...@comcast.net
mbig...@paypal.com
- Original Message -
From: Mark J. Reed
To: perl6-language@perl.org
Sent: Mon, 29 Mar 2010 14:27:00 + (UTC)
Subject: Regex interpolation
Is there not a way to run arbitrary code and interpolate the result as
a literal string (instead of a Regex)?
I assume that {...} is intended to be where you hook in
semantics/actions mid-parse, but it seems a bit counter-intuitive that
the same syntax interpolates in double-quote context but not regexes.
Question Inspired by this Rakudo patch:
On Monday, March 29, 2010, Bruce Keeler wrote:
# New Ticket Created by Bruce Keeler
# Please include the string: [perl #73862]
# in the subject line of all future correspondence about this issue.
#
The attached patch adds support for variable and block-result
interpolation into regexes.
It does so by means of a new PAST::Regex node pasttype 'interpolator'.
The following syntaxes are supported by this patch:
/ $var / -- Interpolates as literal string, unless it's a Regex object
/ @foo / -- Interpolated as ||-style alternations of literal strings
or Regex objects
/ $var / -- compiled into a Regex (unless it's already one), then
interpolated
/ @foo / -- A list of ||-style alternations of things to be
compiled into Regexes (unless they already are)
/ { ... } / -- Result of capture is interpolated as a Regex,
compiling if necessary
/ / -- Unchanged
/ { ... } / -- Capture is merely executed, but not interpolated.
(Unchanged)
--
Mark J. Reed
Re: Temporal revisited
- Original Message - From: Dave Rolsky auta...@urth.org That will make it clear that there's no way to calculate one month from today using the core API. one month from today is ill-defined regardless what time system you are using. There are dates from which one month from today can be reasonably argued to be any of 5 different days. This is why bank contracts are always to be written to say 30, 60 or 90 days not 1, 2 or 3 months from now. -- Mark Biggar%0D%0Amark%40biggar.org%0D%0Amark.a.biggar%40comcast.net%0D%0Ambiggar%40paypal.com
Re: What does a Pair numify to?
-- Original message -- From: Larry Wall la...@wall.org On Thu, Dec 11, 2008 at 02:24:54PM +0100, TSa wrote: My idea is to let a pair numify to whatever the value numifies to. Same thing with stringification. In general I think that a pair should hide its key as far as possible if used as non-pair. This makes sense to me, but I'd like to see any use cases to the contrary, if anyone can think of one. The only use case I can think of is sorting a list of pairs; should it default to sort by key or value? -- Mark Biggar m...@biggar.org mark.a.big...@comcast.net mbig...@paypal.com
Re: Support for ensuring invariants from one loop iteration to the next?
oops make that
last if !someCondition();
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-- Original message --
From: [EMAIL PROTECTED]
loop {
doSomething();
next if someCondition();
doSomethingElse();
}
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-- Original message --
From: Mark J. Reed [EMAIL PROTECTED]
OK, so let's look at the general problem. The structure is this:
doSomething();
while (someCondition())
{
doSomethingElse();
doSomething();
}
...and you want to factor out the doSomething() call so that it only
has to be specified once.
Is that correct, Aristotle?
The gotcha is that the first doSomething() is unconditional, while
the first doSomethingElse() should only happen if the loop condition
is met (which means just moving the test to the end of the block
doesn't solve the problem).
IFF the doSomething() can be reasonably combined with the conditional
test, then Bruce's solution works, but that won't necessarily be the
case in general. Overall, the goal is to ensure that by the end of
the loop the program is in the state of having just called
doSomething(), whether the loop runs or not - while also ensuring that
the program is in that state at the top of each loop iteration.
It does seem like a closure trait sort of thing, but I don't think
it's currently provided by the p6 spec.
Re: 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: 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: Complex planes
Let's worry about getting principal values, branch cuts and handling signed zeros correct before dealing with the interaction of junctions and multi-valued complex functions. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Rakudo test miscellanea
Most financial institutions don't use float, rational or fixed point, they just keep integer pennies. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: Larry Wall [EMAIL PROTECTED] Would any financial institution care to comment? Larry
Re: Where is Manhattan Dispatch discussion?
Carl Mäsak wrote: John (): I'm still in the dark... I find an positions for manhattan distance but no definition of what that is. I did find the alternative pod page earlier. I don't have a whole answer for you, but a part that may help. What is generally meant by Manhattan distance is so-called L1 distance, i.e. Pythagoras' distance summation formula but without all the squaring and surding. http://en.wikipedia.org/wiki/Taxicab_geometry I imagine the concept is applied to parameter types in the discussion in question. To do multi method dispatch, you want to select the method that best matches the parameters in the call. One way to do that is to define a measure for distances between types and they use the method that's at the minimum distance. One simple measure is that a type is distance 0 from itself and distance 1 from it's immediate super-types, distance 2 from the immediate super-types of it's immediate super-types, etc. When dispatching over a single parameter picking the method at the minimum distance is the usual most specific type match. But when you want to do multi-method dispatch, you need some rule to combine the various distances of the individual parameters into a single measure value, then pick the method at the minimum distance by that combined measure. Manhattan Distance or Taxicab Distance is the rule that the combined distance is just the simple unweighted sum of the individual parameter distances. The is named after the fact that a taxi must follow the streets and to go 3 block north and 4 blocks west it must travel 7 blocks not the 5 blocks of the euclidean distance. BTW, if you want to do euclidean distance comparisons you don't need to do any square roots. Square root is monotonic, so order relations between the sums of squares values is the the same whether you take square roots or not. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: First look: Advanced Polymorphism whitepaper
-- Original message -- From: TSa [EMAIL PROTECTED] HaloO, John M. Dlugosz wrote: Maybe we already have this--see emulates in S11. Works for me. For me, too. But note that we should keep does the ultimate type checker that first checks the declared presence of a role, then falls back to a declared class inheritance and then falls back to a declared emulation. What else should be in this check sequence? Do we need to consider boxed vs un-boxed, E.G. Int vs int? -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: First look: Advanced Polymorphism whitepaper
-- Original message -- From: John M. Dlugosz [EMAIL PROTECTED] Jon Lang dataweaver-at-gmail.com |Perl 6| wrote: On Wed, Apr 30, 2008 at 9:58 PM, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On May 1, 2008, at 0:53 , chromatic wrote: correctness sense. Sadly, both trees and dogs bark.) Hm, no. One's a noun, the other's a verb. Given the linguistic orientation of Perl6, it seems a bit strange that the syntax for both is the same: while accessors and mutators are *implemented* as verbs, they should *look* like nouns. In defense of chromatic's point, both people and syrup run. Sometimes you don't even know the correct part of speech without a backtracking parser or infinite lookahead in English. The green can (continues...) be watered after it has been cut. And sometime you can't even do it syntactically: Time flies like an arrow. Fruit flies like a banana. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: static types, checking, conversions
You should look at Common Lisp. it's definition of optional typing is that if you take a correct program and remove all the type declarations, then it still works correctly, although it may be significantly less efficient. Larry and i have discussed this and that was his goai in Perl. Now Perl doesn't quite meet that because of inferred method dispatch on .new(). you need to change my Dog $spot = .new(); to my $Spot = Dog.new(); when you remove the declaration. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: TSa [EMAIL PROTECTED] HaloO, Mark J. Reed wrote: It would behoove @Larry to examine the optional type constraints system proposed for Javascript:TNG (see link from firefox.com developers page). I therefore assume that they have done so, but others would benefit by doing likewise. :) Do I get that right: you imply that I didn't do my homework? Note that I don't feel offended by that. I found two dissertations and a couple of papers about typing JavaScript. The quintessential is that optional typing is defined as having *no* impact on the dynamic behavior of the program. In that respect type annotations are like comments. I doubt that this is the case with Perl 6, or is it? Regards, TSa. -- The Angel of Geometry and the Devil of Algebra fight for the soul of any mathematical being. -- Attributed to Hermann Weyl
Re: cross operator and empty list
Miller, Hugh wrote: From: Moritz Lenz [mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Technically the Cartesian cross operator doesn't have an identity value. It has. The set which contains only the emty set, or in perl terms ([]); Or am I missing something? Should be a (any) 1 point set for the identity. How about considering models from category theory, rather than set theory ? Seems much more fruitful for computer issues than set theory. No an identity would be a set E such that for any set A: A x E = A, but no such set exists. A singleton set get close, but the result is only isomorphic (there is a natural bijection) not equal. Even in category theory you only get isomorphism. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: cross operator and empty list
Technically the Cartesian cross operator doesn't have an identity value. There
is no set X such that
A x X = A. Now any singleton set gives a result that is naturally isomorphic
to the original set, I.e, there is a obvious bijection between the two sets,
but they are not equal sets.
--
Mark Biggar
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
-- Original message --
From: Darren Duncan [EMAIL PROTECTED]
Adriano, I think perhaps what Tsa is trying to get at is the identity value
for the X operator, and I believe I know what it is.
In the relational model of data, both the version of the model where tuples
have unordered named attributes/elements (which I prefer), and the version
where tuples have ordered attributes/elements (which Perl 6 seems to be
using in its X operator), the relational cross product operator is
analogous to numeric multiplication or logical 'and' in its properties
(except that the ordered version isn't commutative).
With respect to relational join being like multiplication, the special
values 0 and 1 are represented by the nilary (zero attribute) relation with
either 0 or 1 tuples respectively, which in common Perl array-of-hash (or
array-of-array) notation for rowsets is
[]
and
[ {} ] or [ [] ]
respectively; I'll call them R0 and R1 for now. Joining any relation R
with R0 gives R0 (or alternately a relation with the same attributes as R
but zero tuples; its zero tuples either way), and joining any relation R
with R1 gives R.
So R1 is the identity value for cross product, meaning the identity value
for X, in Perl 6 would be a one-element array|seq whose element is the
empty array|seq. That is,
[X] ()
equals this:
( () )
Larry et al, on a related note, the list of identity values for reduce in
S03 should be updated to account for this; [X] wasn't on the list last I
looked.
-- Darren Duncan
Re: cross operator and empty list
Cartesain product with the empty set is empty. A x B is the set of all pairs (a,b) where a is in A and b is in B. If either is empty then there are no such pairs and the result is also empty. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: TSa [EMAIL PROTECTED] HaloO, why is (1,2,3) X () defined to be the empty list and not (1,2,3) as is the case with the cartesian product of sets which X basically is with preserved order. Regards, TSa. -- The Angel of Geometry and the Devil of Algebra fight for the soul of any mathematical being. -- Attributed to Hermann Weyl
Re: Query re: duction and precedence.
Mark J. Reed wrote: I'm a believer in generalizing where possible, modulo the principles of KISS and YAGNI. The latter essentially means at least make it general enough that you can extend it later without major retooling if it turns out YNIAA.. It's pretty surprising what can turn out to be useful, so I've never been swayed by arguments from what is it good for?... Something I'm wondering, though, realistically how often would one actually be reducing on an operator that is not associative? What practical use is there for [-] (3,4,5) for example? The reduce meta-operator over - in APL gives alternating sum, similarly alternating quotient for /, which only works if you right associate things. [-] 1,2,3,4,5,6 = 1-2+3-4+5-6 # pseudo-apl [/] 1,2,3,4,5,6 = (1*3*5)/(2*4*6) #pseudo-apl note that would break the perl 6 simple rule that [-] 1,2,3 = 1-2-3, but gives something much more useful. There currently is no easy way to do alternating sum/quotient in perl6. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Integerizing a rat involves truncating its tail
I think nearest makes more sense. People will be really surprised when /1 turns into 0. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] -- Original message -- From: TSa [EMAIL PROTECTED] HaloO, just re-reading S03 I saw that it defines the Rat to Int conversion as truncation. Why not floor semantics like in %? Actually I would recommend floor semantics whenever an integer is coerced. With the sole exception of Num propably using rounding. Regards, TSa. -- The Angel of Geometry and the Devil of Algebra fight for the soul of any mathematical being. -- Attributed to Hermann Weyl
Re: 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: 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: 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: 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. ab is then defined to be a=b !(a==b). Note these are the properties needed sort a list of something. It is impossible to define = on Complex so that is has all these properties and also that Nums compared using the Complex version of = gives the same result as using the Num version of =. Note that you need this to work that way if you want Num to be a subtype of Complex. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
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: 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(IntStr,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 : IntStr and Int|Str : Int. The normal contravariant subtyping
rules for functions gives
+- : ---+
||
:(IntStr,Int?) : :(Int,Int)
| |
+--- : ---+
and
+- : ---+
||
:(IntStr,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 FooBar of the
two roles Foo and Bar is needed. But here the trick with the
optional parameter doesn't work and it is impossible to reconcile
the two signatures. This could simply mean to drop sub blahh from
the interface. But is there a better way? Perhaps introducing a
multi?
Apart from the arity problem the lub Int|Str works for the first
parameter:
+- : ---+
||
:(Int|Str,Int) : :(Int,Int)
| |
+--- : ---+
+ : ---+
| |
:(Int|Str) : :(Str)
Regards, TSa.
--
Re: special named assertions
The documentation should distinguish between those that are just pre-defined characters classes (E.G., alpha and digit) and those that are special builtins (E.G., before ... and commit. 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 !xyz (as well as +xyz and -xyz) are simply special forms of the named assertion xyz. I should probably compare your list to what PGE has implemented and see if there are any differences -- will do that later tonight. Pm
Re: Implicit current-index variable, scoped inside for-loops
Carl Mäsak wrote:
Yobert Hey do you know what would be cool in perl 6
Yobert A special variable for when you do a for (@array) style loop
Yobert 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 = moose elk caribou;
for @array.kv - $i, $val {
say $i\t$val;
}
But maybe a variable that implicitly carries along the loop index
would be even snazzier?
Whatever is done should also work for grep and map.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Numerification of Order:: constants
-- Original message -- From: Reed, Mark (TBS) [EMAIL PROTECTED] S03, lines 418-420: [cmp] always returns COrder::Increase, COrder::Same, or COrder::Decrease (which numerify to -1, 0, or +1). Shouldn't Order::Increase numerify to +1 and Order::Decrease to -1? In which case it would be clearer to put them in respective order above... $a cmp $b has always been define as sign($a - $b), so the above numerification are correct. Thnk of them as describing the sequence ($a, $b). if the sequence is increasing then $a, cmp $b returns Order::Increase or -1. Mark Biggar -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: ===, =:=, ~~, eq and == revisited (blame ajs!) -- Explained
Darren Duncan wrote: Now, I didn't see them yet anywhere in Synopsis 3, but I strongly recommend having negated versions of all these various types of equality tests. Eg, !== for ===, nev for eqv, etc. They would be used very frequently, I believe (and I have even tried to do so), and of course we get the nice parity. Yes and they should be strictly implicitly defined in term of the positive versions in such a way that you can't explicitly redefine them separately. I.e., $x !== $y should always mean exactly the same thing as !($x === $y). Maybe by a macro definition. To do otherwise would be very confusing as it would make such simple program transformations as: say foo if $x !== $y; into say foo unless $x === $y; very unreliable. Actually a similar argument could be made about '' vs '', '=' and '=' in other words just redefining '==' '' should automatically get you '!=', '=', '=' and ''. -- [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Scans
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
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: 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: 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
code
#EOC
Or like:
#{#
# first comment line
# next comment line
code
# last comment line
#}#
Or POD-ish.
--
Groet, Ruud
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 use Complex, 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: 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: 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: 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: 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/pause regardless.pick/e;
s/cond/resume again.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!!
---BeginMessage---
pgpC3zhriMFzT.pgp
Description: PGP signature
---End Message---
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: 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: 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: 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: 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: %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: 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: 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 !prop X 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 !foo might have slightly wrong huffmanization. Is zero-width the common case? If not, we could use character doubling for emphasis: !foo consumes, while !!foo 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 prop X 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 !prop X 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 !foo might have slightly wrong huffmanization. Is zero-width the common case? If not, we could use character doubling for emphasis: !foo consumes, while !!foo is zero-width. Now prop X 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 prop:X 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: 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: reduce metaoperator on an empty list
There are actuall two usefull definition for %. The first which Ada calls 'mod' always returns a value 0=XN and yes it has no working value that is an identity. The other which Ada calls 'rem' defined as follows: Signed integer division and remainder are defined by the relation: A = (A/B)*B + (A rem B) where (A rem B) has the sign of A and an absolute value less than the absolute value of B. Signed integer division satisfies the identity: (-A)/B = -(A/B) = A/(-B) It does have a right side identity of +INF. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] HaloO Mark, please don't regard the following as obtrusive. you wrote: If as usual the definition of a right identity value e is that a op e = a for all a, then only +inf works. Besdies you example should have been; Or actually $n % any( abs($n)+1 .. Inf ) to really exclude 0 from the junction. $n % any (($n+1)..Inf), $n % $n = 0. That depends on the definition of % and the sign of $n. With the euclidean definition 0 = ($n % $N == $n % -$N) abs($N) and for $n 0 there's no identity at all. The identity element has to be an element of the set, which +Inf isn't. It's a type. BTW, is % defined as truncation in Perl6? That would be a bit unfortunate. Simple but not well thought out. -- TSa (Thomas Sandlaß)
Re: reduce metaoperator on an empty list
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 XY is left associative and returns Y when true then it has a left side identity of -inf, etc. But as I'm not sure if the chained ops are actually going to be defined defined in terms of the associativity of the binary op (the way false results propagates through messes things up), so that argument may not work. -- [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 XY is left associative and returns Y when true then ... 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
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 xyz return x or z on being true. if x then -inf else if z then +inf (don't ask if it returns y). Note that some ops (like '%') don't have an identity value and therefore [%] over the empty list is the equivalent to a divide by 0 and probably throws an exception or at least returns undef. Now this is a problem for user defined operations, so reduce of a user defined op over the empty list is either an exception, return undef or we need a trait that can be specified for an infix op that specifies what to return for reduce over the empty list. The compiler shouldn't bother to check if what you specified is really the Identity value for op, but I'd consider it a bug if it isn't. -- [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: 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: 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 $MATCH or some such. Why can't bare $/ just striingify to the whole match? It's already the case that p5-to-p6 is going to have a *wonderful* time translating $7 to $1[2][0]... Not a real problem. Patrick has already said that his plan is that :p5 REs will return a match object with an already flattened match list using perl5 left peren counting semantics. I wonder how much call there will be for a rule option that uses P6 syntax but P5 paren binding with push semantics. Just add a :flat -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Nested captures
Can I say $*1, $*2, etc, to get perl5 flattened peren counting captures? We need something like that to make perl5-perl6 translation easier; otherwise we'd have to parse perl5 RE instead of just slapping on a :p5. Unless :p5 also means that you get a single already fattened match objct. -- Mark Biggar [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] On Mon, May 09, 2005 at 02:08:31PM -0500, Patrick R. Michaud wrote: : Hmmm, then would $x.$j.2 then be equivalent to $x[$j-1][1] ? Ouch. Larry
Re: available operator characters
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: -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, @LarryDamian.)
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: 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: 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: 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: 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: 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: 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: 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: 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: 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
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: Control flow variables
OOPS, totally miss-read your code, ignore my first part of my last message. -- [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 Celse
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 Celse, though. Maybe CFINISH
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: 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 Cblock
.=
{ more_stuff(); };/C 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 Cinfix:.=(Block, Block) {...}/C.
Especially since the other way turns into:
macro atexit(Block $b) {
get_the_current_sub().eval(my block = {};)
unless defined block;
wrap block: { call; $b(); };
}
Which makes two calls per additional whosit.
Frankly, I think I'd rather see:
macro atexit($code) is parsed(/{ Perl6.line* }/) {
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 Ceval()/C 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: 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: 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: 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]
