Re: adverbs o operators
Larry Wall larry-at-wall.org |Perl 6| wrote: As for marking each op individually, it might be possible if we add a whitespace dependency between lt:lc and lt :lc, but 1 ..:by(2) 100 is pretty ugly. Larry So do they have to go at the end of the whole expression in the current grammar? I don't follow about the spaces. Do you write $a lt:lc $b le:lc $c or $a lt :lc $b le :lc $c or $a lt $b :lc le $c :lc ? Making the default a contextual variable would allow the library to do it with no core syntax concerns: $+Str::compare = 'lc'; # applies to rest of lexical scope if $a lt $b le $c ... --John
Humorous but serious article
See my latest creation at http://www.dlugosz.com/Perl6/web/APL.html
Another adverb on operator question
What about adverbs on reduction operators? [lt :lc] $a,$b,$c # all in decreasing order --John
Re: new article, A Romp Through Infinity
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
As I recall, it can handle the concept of Inf-1 etc.
Yes. But the Hyperreals do the same and stay within the realm
of set theory.
I'm not sure. A quick reading indicates that ⋆ℝ contains infinitely large
numbers that maintain the properties of addition, but that is not the same as
infinity.
my @evenodd = 0..Inf:by(2), 1..Inf:by(2);
can be indexed as follows
say @evenodd[3]; # 6
say @evenodd[Inf+1]; # 3
say @evenodd[^3]; # 0 2 4
say @evenodd[Inf «+« ^3]; # 1 3 5
Even in the finite case one has to know the index where the transition
from even to odd is made. In the infinite case this point has the nice
name Inf that's all. Good question is if one can expect
say substr('ab' x Inf ~ 'ba' x Inf, Inf-1, Inf+1);
to print 'bb' on the rational that the structure is 'ab...abba...ba'
That's just not the way ∞ works.
I agree that the length of your file comprehension could be some number that is
in ⋆ℝ that is infinitely large and not in regular ℝ, but it will still be less
than ∞. In order to have +1 and -1 make sense, it needs to be some specific
infinitely large integer, not the generic singularity of Inf.
In any case, the fact that there are so many different systems is a reason why
you should be free to choose a module and not have it built in. If you, for
example, C use Conway::Surreal; , then it could export new meanings of
infix:+ between Inf and Num and return a Surreal number.
With the core of the
language mandating the Inf type every programmer must be aware of
potentially infinite loops etc.
The programmer should be aware of how Inf behaves in comparisons and arithmetic.
And the rule is that ∃x: x∈ℝ, ∞+x=∞.
--John
Re: new article, A Romp Through Infinity
On Thu, Aug 7, 2008 at 3:19 PM, John M. Dlugosz [EMAIL PROTECTED] wrote: I'm not sure. A quick reading indicates that ⋆ℝ contains infinitely large numbers that maintain the properties of addition, but that is not the same as infinity. Well *R is a field that has infinitely large and small numbers and contains R. Surreal numbers are in turn kind of a completion of ordinals. You can complete de complex plane with a single infinity point IMO to include something related to infinity you need to stick with some particular model and forget the rest.
Re: new article, A Romp Through Infinity
HaloO, John M. Dlugosz wrote: The proposed Infinite class (see the thread I started on 4/25/2008) does handle transfinite cardinals. Do you mean the thread called The Inf type where I replied to your post of a version of your specdoc? My concern with the approach you take there is to base it on cardinals whereas ordinals are much more practical. The .elems of an array for example should be its order type not its size as a cardinal. For hashes the size is a cardinal, though. But an infinite hash would need infinitely many keys. So a safe bet is that all hashes will be finite and finite cardinals are equal to finite ordinals. BTW, with an infinite precision Num I see no need for the Rat type! The Num type is not infinite precision, but the highest-precision native type that operates at full speed. Since there are high or arbitrary precision float libraries available now, I'm sure CPAN6 will include some. Could we get confirmation for that from @Larry. I remember $Larry mentioning that Num fails over to Rat or so when necessary. IOW, does my Rat $rat = 1/3; # assuming infix:/ returns a Rat my Num $num = 1/3; my Rat $diff = abs($rat - $num); store a non-zero value in $diff? I assume that Num is discrete with a binary representation and infix:-:(Rat,Num--Rat) converts $num to a fraction with a power of two in the denominator. BTW, with floor semantics I would expect $num $rat. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Humorous but serious article
HaloO, John M. Dlugosz wrote: See my latest creation at http://www.dlugosz.com/Perl6/web/APL.html Nice write-up! You say that there's no syntax for refering to a multi as a whole. But is that not simply the short name? E.g. infix:+ is the multi of all targets in a scope. You need infix:+:(Int,Int) to refer to a single target. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Humorous but serious article
Hi See my latest creation at http://www.dlugosz.com/Perl6/web/APL.html A modern decendent of APL is J http://www.jsoftware.com/ http://www.jsoftware.com/jwiki/FrontPage Regards, Todd Olson
windows XP copyfile
I'm trying to do a Perl script (PC has Perl5 installed) in a BAT file
which will open the CMD prompt, interact with the user and copy files
from one location to other directories. Does anyone know how to dir
the files in a directory into an array and sort by date and return the
ones within the past week? So far I have this code and it returns all
the files:
@files = `dir`;
chomp (@files);
print $#files \n;
if ( @files =~ /[Qq]/ ) {
exit 0;
}
if ( @files =~ /xml$/ ) {
print Recently added XML files: $files \n;
printf COPYLOG Recently added XML files: @files \n;
$type = xml;
}
elsif ( @files =~ /tc$/ ) {
print You are copying an expected result file \n ;
printf COPYLOG You are copying an expected result file \n ;
$type = tc;
}
else {
print Invalid file type or @files doesn't exist in current
directory\n ;
printf COPYLOG Invalid file type or @files doesn't exist in
current directory\n ;
$type = bad;
}
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: new article, A Romp Through Infinity
HaloO,
Xavier Noria wrote:
IMO to include something related to infinity you need to stick with
some particular model and forget the rest.
Well spoken. But I think that the model John has chosen is a bit
too restrictive. If a type has a notion of Zero it could have a
similar notion of infinity just at the other side. For the Int
type in a two's complement mindset that means that counting through
the Ints in increasing order from zero is the same as going in
the *same* direction from -Inf where Zero is the unreachable infinity.
Here I assume that both Zero and -Inf are represented as the infinite
string of 0 binary digits. One is little endian the other big endian,
though. If you don't know where you are in your infinite sequence of
0 then Zero is indistinguishable from -Inf and -1 is indistinguishable
from +Inf, both are infinite sequences of 1.
E.g. +('9' x Inf) == -1 could be a true comparison that doesn't
even scratch the memory resources of temporary hardware. With the
above in mind we could e.g. also define ^-4 === -4..-1 most
conveniently as (*-4)..(*-1) for array indexing from the back in
forward order. Or perhaps that is ^(*-4) and the ^-4 is for indexing
in front of the array. The Whatever type is also behaving a bit like
Inf because it represents different numbers in different arrays.
That is
my Whatever of Int $idx = -4;
always indexes arrays from the back but behaves like normal -4 when
no special handling is required, IOW it sets the shift to zero. Note
that infix:op:(Whatever[::X],X--Whatever[X]) but infix:op:(::X,
Whatever[X]--X) are sort of non-commutative. Note that the default
value for Whatever is Inf ;)
Regards, TSa.
--
The unavoidable price of reliability is simplicity -- C.A.R. Hoare
Simplicity does not precede complexity, but follows it. -- A.J. Perlis
1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: adverbs o operators
HaloO, John M. Dlugosz wrote: So do they have to go at the end of the whole expression in the current grammar? I don't follow about the spaces. The problem is term versus operator parsing. Do you write $a lt:lc $b le:lc $c I think that works and looks best. My favorite hope is that $x = log:2 $y; flies, as well. $x = log:base(2) $y; is a bit lengthy and $x = log $y, :base(2); looks more like a two element list assigned to $x. or $a lt :lc $b le :lc $c That is a parse error two terms in a row. or $a lt $b :lc le $c :lc No problem here. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: new article, A Romp Through Infinity
HaloO, [EMAIL PROTECTED] wrote: Let's just make sure we're handling inf and -inf right and leave all that other stuff until later. The point is: what is the minimum we need to be future proof and compatible to other language features. Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: adverbs o operators
On Thu, Aug 07, 2008 at 06:15:07PM +0200, TSa wrote: Do you write $a lt:lc $b le:lc $c I think that works and looks best. My favorite hope is that $x = log:2 $y; flies, as well. $x = log:base(2) $y; is a bit lengthy and $x = log $y, :base(2); looks more like a two element list assigned to $x. That's because it *is* a two element list. In the current scheme of things, you have to put: $x = log $y :base(2); The point being that adverbs are recognized only where an infix is expected. Otherwise they're just pairs used as nouns. Currently after log a term is expected, so log:base(2) would be parsed as log(:base(2)). The whitespace proposal is essentially to require whitespace between any operator any following pair if the pair is intended to be a noun and not an adverb. We actually thought of this years ago in the design meeting and rejected it at the time because, in particular 123,:foo would surprise a lot of people by looking for the ,:foo operator. But maybe we could put in an exception for confusing forms that are guaranteed not to work. I can't imagine why anyone would want a ,:foo operator, for instance. Doubtless there are other confusing operators though. Alternately, we could force everyone to put space after comma. :) Larry
Re: adverbs o operators
HaloO, Larry Wall wrote: The whitespace proposal is essentially to require whitespace between any operator any following pair if the pair is intended to be a noun and not an adverb. So, then my log:base(2) would still look for the positional argument, right? Alternately, we could force everyone to put space after comma. :) Wouldn't it suffice to enforce to disambiguate ',:' as ', :'? Regards, TSa. -- The unavoidable price of reliability is simplicity -- C.A.R. Hoare Simplicity does not precede complexity, but follows it. -- A.J. Perlis 1 + 2 + 3 + 4 + ... = -1/12 -- Srinivasa Ramanujan
Re: Another adverb on operator question
On Thu, Aug 07, 2008 at 05:04:41AM -0500, John M. Dlugosz wrote: What about adverbs on reduction operators? [lt :lc] $a,$b,$c # all in decreasing order I don't think that'll fly because reduce operators are parsed as single tokens to disambiguate them from array composers, and there are already 7000 reduce operators. Currently every basic infix operator adds 88 different possible reduce operators. (We could cut that down somewhat if we removed Texas quotes from the language.) But adding in all possible adverbs will just completely blow the lexer out of the water. Or to put it another way, how should we parse something like your example after someone adds sub lt without resorting to arbitrarily complex backtracking? The only other way I see to distinguish is to require all array composers to contain a space, since reduce operators may not. But I think that's kinda tacky, and your example still would not work unless you changed it to [lt:lc]. There comes a point at which it's just better to force the user to say: my infix:lt_lc ::= infix:lt.assuming(:lc); [lt_lc] $a, $b, $c; Larry
Re: Another adverb on operator question
Perhaps I'm missing something; but why couldn't you say '[lt]:lc $a, $b, $c'? That is, I see the reducing meta-operator as a way of taking a list-associative infix operator and treating it as a function call, albeit one with a funny name. As such, you should be able to do things with a reduced operator in the same way that you could with any function that has a signature of ([EMAIL PROTECTED], *%adverb). Am I wrong? -- Jonathan Dataweaver Lang
Re: Closure vs Hash Parsing
Jonathan ():
That this means the { $_ = uc $_; } above would end up composing a Hash
object (unless the semicolon is meant to throw a spanner in the
hash-composer works?) It says you can use sub to disambiguate, but
%ret = map sub { $_ = uc $_; }, split , $text;
Doesn't work since $_ isn't an automatic parameter for a sub, like it would
be in just a block (in the implementation, and if I understand correctly in
the spec too).
Out of curiosity, would this work?
%ret = map - { $_ = uc $_; }, split , $text;
Or this?
%ret = map { $^foo = uc $^foo; }, split , $text;
--
Carl Mäsak
