Re: how to write literals of some Perl 6 types?
Jon Lang wrote: Darren Duncan wrote: Now, with some basic types, I know how to do it, examples: Bool # Bool::True Please forgive my ignorance; but are there any cases where 'Bool::True' can be spelled more concisely as 'True'? There are; As long as the short name is unambiguous, it can be used. Cheers, Moritz
Regex - Accessing captured subrules could be problematic
Hi,
I found something that could be problematic (haven't yet found out if it
should be a special case) in Synopsis 5. More precisely it is under the
chapter Accessing captured subrules in the test case
t/regex/from_perl6_rules/capture.t lines 67–71:
ok(eval(' bookkeeper ~~ m/single ($/single)/ '), 'Named backref',
:todofeature);
How can the parser know what you mean by $/single? Maybe you want $/
followed by single or maybe $/single?
A rewrite of this to $single would solve this specific problem, but
not situations like: $/singlesth. Variants like $/.single are also
ambiguous.
A solution could be something like like the Perl5 style: ${/singlesth}
Greetings,
gw
Re: Files, Directories, Resources, Operating Systems
* Tom Christiansen [EMAIL PROTECTED] [2008-11-27 11:30]:
In-Reply-To: Message from Darren Duncan [EMAIL PROTECTED]
of Wed, 26 Nov 2008 19:34:09 PST. [EMAIL PROTECTED]
I believe that the most important issues here, those having
to do with identity, can be discussed and solved without
unduly worrying about matters of collation;
It's funny you should say that, as I could nearly swear that I
just showed that identify cannot be determmined in the examples
above without knowing about locales. To wit, while all of
those sort somewhat differently, even case-insensitively, no
matter whether you're thinking of a French or a Spanish
ordering (and what is English's, anyway?), you have a a more
fundadmental = vs != scenario which is entirely
locale-dependent.
If I can make a RESUME file, ought I be able to make a
distcint r\x{E9}sum\x{E9} or re\x{301}sume\x{301} file in a
case-ignorant filesystem?
That’s for the file system to know, not Perl 6. Trying to unify
this in any way on the side of Perl is, in my regard, a fool’s
errand. If the file system is case insensitive, then it will make
the call in whatever way it deems correct, and it’s not for us to
worry about all the possible ways in which all possible current
and future file systems might answer such questions.
Furthermore, from the point of view of the OS, even treating file
names as opaque binary blobs is actually fine! Programs don’t
care after all. In fact, no problem shows up until the point
where you try to show filenames to a user; that is when the
headaches start, not any sooner.
To that, the right solution is simply not to roundtrip filenames
through the user interface; instead, keep both the original octet
sequence as well as the decoded version, and use the decoded
version in UI but refer back to the pristine original when the
user elects, via UI, to operate on that file.
As far as I am concerned, if Perl 6 has a distinction between
octet strings and character strings, then all that’s required is
to have filenames returned from OS APIs come back as octet
strings, keeping the programmer from forgetting to deal with
decoding issues. The higher-level problems like sorting names in
a locale-aware fashion will be solved by the CPAN collective much
better than any boil-the-ocean abstract interface design that the
Perl 6 cabal would produce – if indeed these are real problems at
all in practice.
All that’s necessary is to design the interface such that it
won’t obstruct subsequent “userland” solution approaches.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Support for ensuring invariants from one loop iteration to the next?
* [EMAIL PROTECTED] [EMAIL PROTECTED] [2008-12-03 21:45]:
loop {
doSomething();
next if someCondition();
doSomethingElse();
}
I specifically said that I was aware of this solution and that I
am dissatisfied with it. Did you read my mail?
* Jon Lang [EMAIL PROTECTED] [2008-12-03 20:10]:
Aristotle Pagaltzis wrote:
* Bruce Gray [EMAIL PROTECTED] [2008-12-03 18:20]:
In Perl 5 or Perl 6, why not move the grep() into the
while()?
Because it's only a figurative example and you're supposed to
consider the general problem, not nitpick the specific
example…
But how is that not a general solution? You wanted something
where you only have to set the test conditions in one place;
what's wrong with that one place being inside the while()?
Because readability suffers immensely when ensuring the invariant
takes more than a single short expression. You have to break the
loop condition out over several indented lines. Not pretty.
* Eirik Berg Hanssen [EMAIL PROTECTED] [2008-12-03 22:30]:
I think Perl 5 will always allow:
while ( doSomething(), someCondition() ) {
doSomethingElse();
}
I also think Perl 6 will always allow:
while ( doSomething(); someCondition() ) {
doSomethingElse();
}
... but don't quote me on that. Unless I'm right. ;-)
The Perl 6 version of the two is more bearable, because neither
do you need a `do{}` bracket nor do comma precendence issues
force you to strew parens the expressions. But as I wrote above,
this breaks down as soon as you need to do a non-trivial amount
of work to ensure the invariant.
* Jon Lang [EMAIL PROTECTED] [2008-12-03 22:05]:
I suspect that the difficulty with the while(1) version was the
kludgey syntax; the loop syntax that you describe does the same
thing (i.e., putting the test in the middle of the loop block
instead of at the start or end of it), but in a much more
elegant manner. The only thing that it doesn't do that a more
traditional loop construct manages is to make the loop
condition stand out visually.
There’s no real difference between `while(1)` and `loop` to me.
I don’t like C’s `for(;;)`, but both the Perl 5 and 6 idioms are
equally fine with me. The problem I have is that the number of
iterations is not indeterminate; there is a set amount of work to
be complete, whereupon the loop will terminate. Contrast to the
event loop in a GUI, f.ex., where the termination of the loop is
an exceptional event, and the loop runs for as long as the app is
running.
This is much like being able to have statement modifier forms of
conditionals and loops: I want to put emphasis on what matters.
When I see `while ( @stuff )` that means to me that [EMAIL PROTECTED] is
expected to run out as a consequence of the loop body operating
on it. When I say `while (1)` I generally intend to say that I
don’t expect the loop to terminate any time soon, although of
course some uncommon condition might require termination.
* David Green [EMAIL PROTECTED] [2008-12-03 22:00]:
On 2008-Dec-3, at 12:38 pm, Mark J. Reed wrote:
I think the cleanest solution is the coy one.
Me too. I don't think having the condition in the middle of the
block is necessarily a bad thing -- that's how the logic is
actually working, after all. Fake conditions like while(1)
are kind of ugly, but P6 has loop, and you can always make it
stand out more:
loop
{
doSomething();
#CHECK OUR LOOP CONDITION!
last unless someCondition;
doSomethingElse();
}
See above. When each iteration of the loop reduces some finite
quantity, I want to use a check for that quantity as the loop
condition, to point out that this is the purpose of the loop:
to finish a particular pile of work and terminate.
This is in contrast to a loop which reacts to an infinite stream
of input of whatever sort.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
Re: Files, Directories, Resources, Operating Systems
* Aristotle Pagaltzis ([EMAIL PROTECTED]) [081204 14:38]:
Furthermore, from the point of view of the OS, even treating file
names as opaque binary blobs is actually fine! Programs don’t
care after all. In fact, no problem shows up until the point
where you try to show filenames to a user; that is when the
headaches start, not any sooner.
So, they start when
- you have users pick filenames (with Tk) for a graphical
applications. You have to know the right codeset to be able
to display them correctly.
- you have XML-files with meta-data on files which are
being distributed. (I have a lot of those)
- when you start doing path manipulation on (UTF-16) blobs,
and so forth. I have been fighting these problems for a long
time, and they worry me more and more because we see Unicode being
introduced on the OS-level. The mess is growing by the day.
To that, the right solution is simply nt to roundtrip filenames
through the user interface; instead, keep both the original octet
sequence as well as the decoded version, and use the decoded
version in UI but refer back to the pristine original when the
user elects, via UI, to operate on that file.
But now you simply say decode it. But to be able to decode
it, you must known in which charset it is in the first place.
So: where do we start guessing? An educated guess at OS level,
or on each user program again?
decoding issues. The higher-level problems like sorting names in
a locale-aware fashion will be solved by the CPAN collective much
better than any boil-the-ocean abstract interface design that the
Perl 6 cabal would produce – if indeed these are real problems at
all in practice.
Why? Are CPAN programmers smarter than Perl6 Cabal people?
What I whould like to be designed is an object model for OS, processes
directories, and files. We will not be able to solve all problems for
each OS. Maybe people need to install additional CPAN modules to get
smarter behavior. But I would really welcome it if platform independent
coding is the default behavior, without need for File::Spec, Class::Path
and such. Once, we have made the step from FILEHANDLES to IO::File.
Let's make it go a little further.
The discussion is stuck in filenames, which are a problematic area.
But we started with chown and friends. It really would like to
be able to write:
$file = File.new($filename);
$file.owner($user);
if $file.owner eq $user {}
$file.open()
over
if($has_POSIX)
{ chown $filename, $user;
if((stat $filename)[4]==getpwuid $user) {}
}
else
{ die Sorry, do not understand your system;
}
--
Regards,
MarkOv
Mark Overmeer MScMARKOV Solutions
[EMAIL PROTECTED] [EMAIL PROTECTED]
http://Mark.Overmeer.net http://solutions.overmeer.net
Re: Support for ensuring invariants from one loop iteration to the next?
* Mark J. Reed [EMAIL PROTECTED] [2008-12-03 20:30]:
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?
Yes.
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).
Exactly.
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’s not a goal in itself. It’s just a necessity: you cannot test
the loop condition without ensuring the invariant, so whether or
not the loop runs is irrelevant, you have to run it once before
you can know whether the loop will run at all.
It does seem like a closure trait sort of thing, but I don't think
it's currently provided by the p6 spec.
I don’t see anything suitable there either. And while it does
seems like a closure trait, that seems somewhat problematic in
that the order of evaluation is weird when compared to other
closure traits, which I suppose is what led you to declare the
“coy” solution as the most natural. I am trying to think of a
good block structure to capture these semantics spatially and
not currently coming up with anything very good.
* Mark J. Reed [EMAIL PROTECTED] [2008-12-03 20:40]:
We can guarantee it's set at the top of each loop iteration
with ENTER, but that doesn't get run if the loop never runs.
We can guarantee it's set at the end of the loop with LAST, but
that also doesn't get run if the loop never runs, and doesn't
take care of the first iteration.
For the purposes of this particular problem, there isn’t even
much difference between those two.
* Patrick R. Michaud [EMAIL PROTECTED] [2008-12-03 21:10]:
Perhaps PRE ... ?
while (someCondition()) {
PRE { doSomething(); }
doSomethingElse();
}
The problem is, doSomething() has to be run *prior* to *any* loop
condition check – including the very first. PRE (or ENTER) can’t
do that.
Or, if you wanted to be sure that doSomething() is always called
at least once:
repeat {
PRE { doSomething(); }
doSomethingElse();
} while someCondition();
That will run doSomething() once unconditionally. That’s not what
I’m after.
--
*AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1}
Just-another-Perl-hack;
#Aristotle Pagaltzis // http://plasmasturm.org/
Re: Support for ensuring invariants from one loop iteration to the next?
* David Green [EMAIL PROTECTED] [2008-12-03 22:00]:
FIRST{} can do something on only the first iteration through
the loop, but there's no NOT-FIRST block to do something on the
second and subsequent iterations. Is there an elegant way to do
something on all but the first loop?
Not with a closure trait and without a flag, which I guess does
not count as elegant.
In Template Toolkit this is nice insofar as that the loop
iterator is available as an object in a variable, so you can say
IF loop.first ; ... ; END ;
but equally
IF NOT loop.first ; ... ; END ;
and similarly you can say
IF NOT loop.last ; ... ; END ;
to do something on all iterations but the ultimate.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
why infix:div:(Int, Int -- Rat)
HaloO, I realized from the typed literal thread that S03 now explicitly states that div on two Ints returns a Rat. I remember the state of affairs being that it returns an Int that adheres to the division of an Int $y by another Int $x such that $y == ($y div $x) * $x + ($y mod $x) holds with floor semantics as the default. This is now not the case anymore. Why? Isn't the special handling of integer division by infix:/ enough? There the result becomes a Num only if needed such that it preserves precision as long as possible. Question: does such a 'Num but Rat' type dispatch to the Rat versions of operators? 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: Files, Directories, Resources, Operating Systems
* Mark Overmeer [EMAIL PROTECTED] [2008-12-04 16:50]: * Aristotle Pagaltzis ([EMAIL PROTECTED]) [081204 14:38]: Furthermore, from the point of view of the OS, even treating file names as opaque binary blobs is actually fine! Programs don’t care after all. In fact, no problem shows up until the point where you try to show filenames to a user; that is when the headaches start, not any sooner. So, they start when - you have users pick filenames (with Tk) for a graphical applications. You have to know the right codeset to be able to display them correctly. Yes, but you can afford imperfection because presumably you know which displayed filename corresponds to which stored octet sequence, so even if the name displays incorrectly, you still operate on the right file if the user picks it. - you have XML-files with meta-data on files which are being distributed. (I have a lot of those) Use URI encoding unless you like a world of pain. - when you start doing path manipulation on (UTF-16) blobs, and so forth. I have been fighting these problems for a long time, and they worry me more and more because we see Unicode being introduced on the OS-level. The mess is growing by the day. And all we can do is to avoid making it even bigger. Because the only ones in control here are the OS vendors, and they aren’t solving it, only making it bigger. The only thing *we* can do is not to erect obstacles that users will have to work around when our abstractions invariably leak. I am unconvinced that this problem actually yields to abstraction. All the really hard problems in computing are the ones that intersect with human culture – text in any form, and dates and times. When computers deal with mathematical entities, few problems are even hard, let alone insurmountable, you only need to work at them long enough. Human concepts are not like that, they are messy and inconsistent. To that, the right solution is simply nt to roundtrip filenames through the user interface; instead, keep both the original octet sequence as well as the decoded version, and use the decoded version in UI but refer back to the pristine original when the user elects, via UI, to operate on that file. But now you simply say decode it. But to be able to decode it, you must known in which charset it is in the first place. So: where do we start guessing? An educated guess at OS level, or on each user program again? I am not advocating educated guesses. The mechanism would be whatever interfaces the system provides. Unix does not have any, so you can indeed only ever guess, but if they system can give you something better, that should be used. NTFS seems to say it’s all Unicode and comes back as either CP1252 or UTF-16 depending on which API you use, so I guess you could auto-decode those. But FAT is codepage-dependent, and I don’t know if Windows has a good way of distinguishing when you are getting what. So Windows seems marginally more consistent than Unix, but possibly only apparently. (What happens if you zip a file with random binary garbage for a name on Unix and then unzip it on Windows?) I have no idea what other systems do. But there is no common denominator, so pretending there is one is not going to help. The higher-level problems like sorting names in a locale-aware fashion will be solved by the CPAN collective much better than any boil-the-ocean abstract interface design that the Perl 6 cabal would produce – if indeed these are real problems at all in practice. Why? Are CPAN programmers smarter than Perl6 Cabal people? Of course! There are many more CPAN programmers than cabalists; some of them are bound to have much greater expertise in some relevant area of this problem than anyone in the cabal. Even those who aren’t that smart will have direct access to and specific knowledge of the system they are dealing with, that the cabal may never even hear about. What I whould like to be designed is an object model for OS, processes directories, and files. We will not be able to solve all problems for each OS. Maybe people need to install additional CPAN modules to get smarter behavior. But I would really welcome it if platform independent coding is the default behavior, without need for File::Spec, Class::Path and such. Ugh. I understand the desire, but it is very easy to get into architecture astronautics. I think we should follow the DBI approach and not try to provide a unified interface to system- specific things like permissions and ownership: unify the most general notions of filesystems but leave all the specifics to be dealt with by user code in the concrete. That is the only place where the amount of acceptable abstraction can be decided. Cf. writing apps that run on all of PostgreSQL, MySQL and Oracle vs those that take advantage of specific DBMS features: this is a decision that the programmer has to make, it is not one we can make on his behalf. Regards,
Re: how to write literals of some Perl 6 types?
HaloO, David Green wrote: Using int8 vs Int is presumably a performance issue, but int8 29 and Int 29 *mean* the same thing, so they should be ===. An Enum doesn't mean the same thing as a plain Int, so it shouldn't. IIRC, === is defined to compare only values from the same type domain. For values from different domains it is false. The question I want to have answered here is in which respects int8 differs from Int and which they have in common and how that is expressed in Perl 6. E.g. Int could be a role and int8 is a class that does this role. The standard implementation for integers is some BigInt class that also does the Int role. This class has to be known to other types like int8 for failover when their range of values is left. Well, int8 could failover to int16 first. I wonder if int8 being a class that does the Int role can thus be used as implementation type of a variable: my $x is int8; Would that also imply a constraint of int8? I guess all my concerns boil down to the fact that I don't understand what a protoobject which is returned by WHAT exactly is. E.g. how can int8 and BigInt share the Int protoobject such that === compares them. (As you point out, you can always use something like Weekday::Sun eq Star::Sun or Weekday::Sun == 0 if you want string or numeric equality.) Yes, these comparisons are well defined in the Str and Num domains. 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: how to write literals of some Perl 6 types?
HaloO, David Green wrote: Using int8 vs Int is presumably a performance issue, but int8 29 and Int 29 *mean* the same thing, so they should be ===. An Enum doesn't mean the same thing as a plain Int, so it shouldn't. And how about 'Num 1.0 === Complex(1,0) === Int 1'? Should all these be identical irrespective the fact that they come from three different type domains? How is that implemented? 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: why infix:div:(Int, Int -- Rat)
On 2008-Dec-4, at 9:42 am, TSa wrote: I remember the state of affairs being that [div] returns an Int Something more explicit like idiv was suggested for integral division. Personally, I'm happy not to have anything special provided for it, on the grounds that having to say, e.g. floor($i/$j), forces you to be blatantly clear that you're disposing of the remainder and how. -David
Re: Regex - Accessing captured subrules could be problematic
Hello,
GW wrote:
I found something that could be problematic (haven't yet found out if it
should be a special case) in Synopsis 5. More precisely it is under the
chapter Accessing captured subrules in the test case
t/regex/from_perl6_rules/capture.t lines 67–71:
ok(eval(' bookkeeper ~~ m/single ($/single)/ '), 'Named backref',
:todofeature);
How can the parser know what you mean by $/single? Maybe you want $/
followed by single or maybe $/single?
I don't know if this is the answer to your particular question, but
these questions are usually answered by Longest Token Matching (LTM).
This principle says that every grammar rule that parses the source code
eats up as many characters as possible.
So I think this means here that $/single will be parsed as one long
token instead of two separate tokens.
The same rule applies for interpolation in strings:
my big $house.uc is parsed as my big { $house.uc }, ie $house.uc is
taken as one token, even though a valid interpretation would be to
interpolate $house first and then append .uc to that string.
A rewrite of this to $single would solve this specific problem, but
not situations like: $/singlesth. Variants like $/.single are also
ambiguous.
A solution could be something like like the Perl5 style: ${/singlesth}
The Perl 6 solution is that you disambiguate with whitespace if you
don't want to follow the LTM-rule (ie you'd say '$/ single' in the regex).
For string interpolation embedded closures (my big {$house}.uc) can be
used for disambiguation.
Cheers,
Moritz
Re: Regex - Accessing captured subrules could be problematic
On Wed, Dec 3, 2008 at 6:19 PM, GW [EMAIL PROTECTED] wrote:
Hi,
I found something that could be problematic (haven't yet found out if it
should be a special case) in Synopsis 5. More precisely it is under the
chapter Accessing captured subrules in the test case
t/regex/from_perl6_rules/capture.t lines 67–71:
ok(eval(' bookkeeper ~~ m/single ($/single)/ '), 'Named backref',
:todofeature);
How can the parser know what you mean by $/single? Maybe you want $/
followed by single or maybe $/single?
If you wanted $/ followed by single then you would introduce some
intervening whitespace.
This is just like interpolation into double quoted strings. When you say
my @what = some example string;
my $str = This is a @what[2];
you always get the 3rd item from the @what array interpolated, not the
string '@what[2]'. If you want the latter, you have to use some other
technique (concatenation, single quotes, etc.)
A rewrite of this to $single would solve this specific problem, but
not situations like: $/singlesth. Variants like $/.single are also
ambiguous.
Same for these.
And if you're doing this in a context where whitespace has meaning (e.g.
:sigspace is in effect), but you don't want the significant whitespace, you
can turn that off temporarily (or again, use some other technique).
HTH,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: why infix:div:(Int, Int -- Rat)
On Thu, Dec 4, 2008 at 3:26 PM, David Green [EMAIL PROTECTED] wrote: Something more explicit like idiv was suggested for integral division. Personally, I'm happy not to have anything special provided for it, on the grounds that having to say, e.g. floor($i/$j), forces you to be blatantly clear that you're disposing of the remainder and how. Using div instead of / should make it pretty clear that you're disposing of the remainder. The sorts of calculations that involve heavy use of integer quotients typically also involve heavy use of the remainders, and it's only reasonable that both halves be treated with equal respect in terms of language support. A way to get both in one fell swoop would be nice (e.g. Ruby's Integer#divmod), but at the very least, if we have mod (%), we should have div, too. -- Mark J. Reed [EMAIL PROTECTED]
Re: how to write literals of some Perl 6 types?
On Thu, Dec 4, 2008 at 6:34 PM, TSa [EMAIL PROTECTED] wrote: HaloO, And how about 'Num 1.0 === Complex(1,0) === Int 1'? Should all these be identical irrespective the fact that they come from three different type domains? How is that implemented? IMHO the spec on === is quite clear: two values are never equivalent unless they are of exactly the same type. IMHO, you shouldn't be using === but == anyway when doing that kind of numerical work. That one should DWIM. Regards, Leon Timmermans
