Unwanted failure and FAILGOAL
I have the following in a grammar
rule TOP{ ^ + $ };
rule statement { '='
| { { self.panic($/, "Declaration syntax
incorrect") } }
};
rule endvalue { '(' ~ ')'
| { self.panic($/, "Invalid declaration.") }
}
The grammar parses a correct input file up until the end of the file. At
that point even if there is no un-consumed input, there is an attempt to
match , which fails. The failure causes the panic with 'Declaration
syntax'.
Am I missing something simple here?
I would have thought (though this is only a very newbie assumption)
that if the end of the input being sent to the grammar has been reached
after the last has been matched, then there should be no
reason for the parse method to try to match again, and if it
fails to test for the end of input.
Abstractly, it seems to me to be a bit like the difference between
testing for the truth of a condition before entering a loop, and testing
for the truth after the loop.
In trying to find a way out of this, I went looking for some information
about FAILGOAL. I could not find anything in the documentation or in the
specifications.
Google provided me with some conversations about FAILGOAL, but nothing
about how to use it. I do not know enough about the guts of Rakudo to
know where to look.
Would it be possible for someone who knows about this to add something
to the Documentation on Grammars?
(As I write this, I thought may be I need a lookahead pattern in the
TOP rule to ensure there is still input. But even so, that seems counter
intuitive.)
Just to say 'Well Done' to developers
Dear perl6 developers and implementers! Amazing the difference a year makes. I've been following perl6 from the beginning. About a year ago, I had @other-things-to-do. Just started tinkering again. Speed increase is really impressive. It's a joy to use. So I just wanted to say to everyone involved: Well done. Your hard work has had impressive results. I know that thanks from a user are not really why developers do things, but I did want to offer some kind words. Not to say that everything is perfect, but the increase in speed makes a huge difference to the user experience. Regards, Richard Hainsworth (finanalyst)
Re: Backwards compatibility and release 1.0
Moritz rant away! Actually, I think this it is a very significant milestone in the development of a language and its ecosystem when backwards compatibility becomes an issue. There will always be modules that have bit rot, insufficient documentation, inadequate testing, no reviews, etc. The problem is not their existence, but how they are perceived. Newcomers to Perl6 will not know much about which modules are useful, which are buggy, which are OK, etc. If a newcomer comes across some module that promises a lot and fails to work, it may not (unfortunately) be the module that gets the blame, but the Perl6 language/community/culture. Some suggestions: 1) On the perl 6 modules page (modules.perl6.org) , sort the modules by number of Badges, with a label for each category like Good (all of the badges and 'build|passing'), Less Good (some badges and 'build|passing'), Experimental (the rest). Perhaps also a warning about the modules in the category. This way, the better quality modules are listed first by default. If someone wants to use a Less Good or Experimental module, they have been warned. 2) Add another badge for 'reviewed'. I found the CPAN reviews to be existentially useful, even if some of the content may be less useful. The fact that a module has been reviewed by someone other than the author increases my confidence that the module can be made to work. If there are negative comments, I am more cautious. 3) Would it be possible to develop a sort of Citation Index? That is the number of times a module uses another module? Citation Indices are widely used in academia to highlight key articles and papers. It's not an infallible tool as the system can be gamed, but it is much better than nothing. 4) How about developing the 'bundle' idea more? Perhaps, putting Bundles on the Perl6 Modules top page, starting with Task::Star? Bundles could be moderated more strictly. Perhaps Bundle authors would need to supply a mandate, eg. "Bundle for GUI development", or "Essential beginners bundle". Also bundle authors would need to have vetted the modules in the bundle, especially those without all badges. Regards, Richard On 10/14/2015 05:54 PM, Moritz Lenz wrote: On 10/13/2015 10:52 AM, Richard Hainsworth wrote: Following on the :D not :D thread, something odd stuck out. On 10/13/2015 03:17 PM, Moritz Lenz wrote: But hopefully none of them breaking backwards compatibility on such a large scale. The last few backwards incompatible changes still cause pain in the ecosystem. We have 390+ modules, and hand-waving away all trouble of maintaining them seems a bit lofty. Surely, the idea of keeping the release number below 1.0 is to warn early adopter developers that code is subject to change and thus in need of maintenance? It is. But we still should try to limit the module author's burden. In Practice, there's a small number of people who try to update modules to match when the compiler changed. Most module authors don't hang out in #perl6, eager to update their modules to the lastest rakudo change. So a large percentage of the module updates are done by group of maybe five to a dozen volunteers. So, do the math: 5 people updating 70% of 390 modules. Modules they are usually not all that familiar with, and usually don't have direct access. So they need to go through the pull request dance, waiting for reaction from the maintainer. In short, it sucks. The ecosystem hasn't yet fully recovered from the s/done/done-testing/ change, nor from the GLR, nor from the need to prefix 'unit' to some declarations. And this is why I'm getting increasingly frustrated and angry when people propose major breaking changes, brushing off the implications for the ecosystem and its maintainers with "but it's not 6.0", "shouldn't be a problem", "we aren't stable yet". We want to release Perl 6 by Christmas, and it'll reflect *very* badly on us and the language if many modules in the ecosystem are broken. And any change that requires us to touch all .pm files will result in that. Richard, I'm sorry that I'm writing the response in an email of yours; Mark or any number of p6l participants in the last few years triggered the same mental response from me. I only just now articulated it. Cheers, Moritz
Backwards compatibility and release 1.0
Following on the :D not :D thread, something odd stuck out. On 10/13/2015 03:17 PM, Moritz Lenz wrote: But hopefully none of them breaking backwards compatibility on such a large scale. The last few backwards incompatible changes still cause pain in the ecosystem. We have 390+ modules, and hand-waving away all trouble of maintaining them seems a bit lofty. Surely, the idea of keeping the release number below 1.0 is to warn early adopter developers that code is subject to change and thus in need of maintenance? Seems strange that after so long and "Christmas" is finally coming up that Rakudo 1.0 is going to be associated with modules that do not comply with the "standard". So if :D is the default specified by the standards, then all modules should be expected to conform to that standard when V1.0 comes out. It does not matter really what the standard actually is, :D or not, so long as what is defined to be the standard is adhered to. Perl6 gives huge flexibility to developers to change standard for themselves, but surely there should be some common 'starting' ground, and modules for general use should adhere to it. When the language and implementation were being co-developed, it was reasonable to expect that different modules would have different states of compliance. But surely V1.0 is a different sort of milestone? 'Hand-waving' all the trouble of maintaining the modules surely is not the issue. Ensuring that the modules comply with the standard set for Perl6 as implemented by Rakudo V1.0 is a reasonable expectation for anyone using the Rakudo version of Perl6 going forward. Even if there is an argument that I have missed in the above about the need for modules to adhere to the standard prescribed by the Perl6, would it not be in the interests of PR around Perl6 for the very first V1.0 implementation to be accompanied by modules that have been brought as close to the standard as possible? These modules will help future developers to understand how to use the language.
Re: [perl6/specs] 614b6f: doc with/without
Is there an error in the cascade? Shouldn't the indices be 'a', 'b', 'c'; not 'a','a','a' ? On 08/10/2015 11:26 PM, yary wrote: with, without look awesome. -y On Sat, Aug 8, 2015 at 2:38 PM, GitHub nore...@github.com mailto:nore...@github.com wrote: Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 614b6f36e1cae4c787e378bc6ab2afa1f86de1f0 https://github.com/perl6/specs/commit/614b6f36e1cae4c787e378bc6ab2afa1f86de1f0 Author: TimToady la...@wall.org mailto:la...@wall.org Date: 2015-08-08 (Sat, 08 Aug 2015) Changed paths: M S04-control.pod Log Message: --- doc with/without
some thing odd in macro
I was trying out macros and run into an anomaly. Not sure what is happening.
I tried a macro snippet as a standalone script, then tested exactly the
same in REPL. It worked in REPL, as in the hash variable was changed.
But the hash variable stayed the same in the stand alone. What am I missing?
Here is a paste from my terminal.
$ cat macro-test.p6
my %o;
macro attr ( $nm, $val ) { quasi { %o{ {{{$nm}}} } = {{{$val}}} } }
%o.say;
attr 'fst', 42;
%o.say;
$
$ perl6
my %o
().hash
macro attr ( $nm, $val ) { quasi { %o{ {{{$nm}}} } = {{{$val}}} } }
Nil
%o.say
().hash
attr 'fst', 42
42
%o.say
(fst = 42).hash
^C
$ perl6 macro-test.p6
().hash
().hash
$
$ perl6 -v
This is perl6 version 2013.11 built on parrot 5.9.0 revision 0
Revisions to the Intros of Synopses.
Dear Perl6 community, Since this is my first use of git, I did not do what I intended, which was to create a new branch to show my suggestions. Apologies. Some time back, I suggested revising the front part of all the Synopses and rewriting Synopsis 1. Basically, it seemed to me that the word Draft could be completely eliminated from all Synopses. Basically, the whole process of developing perl6 means that the Synopses are all drafts until they are not. The distance from the Apocalypses is so far that they are historical documents rather than useful sources to refer to. It seemed to me that the history should be included in Synopsis 1. I have added several sections based on material in the Rakudo star releases and an email from Patrick. In several Synopses, there are references to editing pod files rather than html files. My suggestion would be to put a note to this effect in the pod-html generator rather than in the pod files. The result of this work should be to allow for a content.pod file to be generated from the pod files. I have demonstrated the idea with a small script. It does not handle pod6 files well (S15 and S26). It doesn't really produce pod. But if the idea is acceptable, then the script can be enhanced/rewritten. I have found the lack of a contents of all the Synopses a pain when looking for references. I hope these suggestions do not cause any offense, none was intended. Regards, Richard finanalyst
Re: memory leak I think.
On 12/19/2013 10:32 PM, Patrick R. Michaud wrote: On Thu, Dec 19, 2013 at 11:27:32AM +0800, Richard Hainsworth wrote: I've been running a perl6 program that runs through a loop, dumps intermediate results and starts again with new initialisation values. [...] Looking at system resources, the program chews up memory resources continually. a) Is this a known problem due to garbage collection problems? If you're using Rakudo on Parrot, then the likely cause of what you are seeing is due to the way Parrot manages memory. Parrot tends to allocate memory pools up to a certain limit (based on system resources) and never releases any of that allocated memory back to the system until the process terminates. So even though Rakudo is likely releasing the resources back to Parrot, Parrot doesn't release them back to the system. Parrot will start re-using the allocated memory for new objects, however, once it's reached the resource limit mentioned above. Pm Yes, using Rakudo * on parrot. Seems worse than hitting a resource limit as the program chews up memory until the system kills it. Richard
memory leak I think.
I've been running a perl6 program that runs through a loop, dumps intermediate results and starts again with new initialisation values. The program runs fine for the first three loops, but does appear to slow down and on the fourth time though hangs. Looking at system resources, the program chews up memory resources continually. a) Is this a known problem due to garbage collection problems? b) Is there a work around to actually release re-initialise objects. For instance, I use several arrays and I reinitialised by setting (in a reset method of a class) @.rray = (); Does this work? c) Is there a better way to find the source of the problem than running the program and looking at system resources? Eg. valgrind? I'm not sure how to use this with perl6. Richard
Unexpected expansion of string with xx
Initially I though the following was a bug, but now I'm not sure.
I got these results
perl6 -v
This is perl6 version 2013.09 built on parrot 5.5.0 revision 0
$ perl6
say '0' xx 4
0 0 0 0
print '0' xx 4
print 's' ~ ('0' xx 4)
s0 0 0 0
I'm not sure why the elements of the expansion are padded with a
trailing space in one context but not in another.
I wasn't sure whether this is the specified behaviour. If it is how can
it be turned off?
Richard
Re: Unexpected expansion of string with xx
OK x not xx.
The doubling of operators is confusing.
Richard
On 12/19/2013 10:01 PM, Jonathan Worthington wrote:
On 12/19/2013 3:47, Richard Hainsworth wrote:
Initially I though the following was a bug, but now I'm not sure.
I got these results
perl6 -v
This is perl6 version 2013.09 built on parrot 5.5.0 revision 0
$ perl6
say '0' xx 4
0 0 0 0
Are you sure you didn't want the x (string repetition) operator,
instead of xx (list repetition)?
print '0' xx 4
print 's' ~ ('0' xx 4)
s0 0 0 0
I'm not sure why the elements of the expansion are padded with a
trailing space in one context but not in another.
print calls .Str, say calls .gist.
I wasn't sure whether this is the specified behaviour.
It is.
If it is how can it be turned off?
Call .Str or .gist on the argument to print/say as needed.
I suspect that the problem will be resolved by using the x operator
instead of xx, however. :-)
/jnthn
Re: Class attribute introspection
This and the response from Elizabeth raise in my mind the following
question:
To what extent are papers/specifications from other parts of the
computer science world implicitly a part of the Perl6 specification?
I found references to 'getters and setters' in the synopsis on objects,
but without the extra references I was unable to do what I wanted in Perl6.
As PM said, whatever answer was given to my MOP question, it should be
included in one of the synopses, thus making MOP functionality
explicitly a part of perl6 synopses.
Richard
On 10/28/2013 09:42 PM, Carl Mäsak wrote:
The MOP is an API to the object-oriented system. With it, you can
query classes and their attributes and methods about their properties.
It can also be used to create whole new classes (or other types)
programatically.
Languages that have a MOP have a great advantage because, even though
the object system is in a sense always arbitrary, at least now it's
programmable.
// Carl
On Mon, Oct 28, 2013 at 2:17 PM, Richard Hainsworth
rich...@rusrating.ru wrote:
Moritz,
You are the everflowing font of knowledge. Thanks.
However, I read the synopsis on objects and did not find the .get_value
method.
Pardon the ignorance, but what is the MOP. I sometimes get floored by the
jargon.
I read about the indirection for methods, but how does that relate to
attributes?
Richard
On 10/28/2013 01:45 PM, Moritz Lenz wrote:
Hi Richard,
On 10/28/2013 08:07 AM, Richard Hainsworth wrote:
Perhaps I am using class incorrectly, but I set up a class, then change
some of the parameters in an instance of the class. Next I would like to
discover what the current state of the instance is.
There is a way to introspect through the MOP:
class A { has $!x = 42; };
my $obj = A.new;
say A.^attributes[0].get_value($obj);
It's not straight forwards, and that's actually a feature :-)
The usual way to go is through the accessors, and indirect method calls
with $obj.$name();
Cheers,
Moritz
issue with checking of sub signature
I ran into a problem at the weekend and reduced it to a fragment and
then looked at alternatives.
The problem is in snippet bug2_2 below. There is a type check that
fails, but the types appear to be the same. This may be an existing bug.
The problem is that when I put the return type in the sub signature, the
type checker does not appear to accept the array type, but the snippet
works fine without the return type being specified.
Also, I am confused about what an Array of A is, if it is not an array
of elements each of which are A, see bug_4.
The following is from my terminal, running Ubutu:
$perl6 -v
This is perl6 version 2013.09 built on parrot 5.5.0 revision 0
$ for a in 1 2 3 4; do echo; echo cat bug_$a.p6:; cat bug_$a.p6; echo
result of: perl6 bug_$a.p6; perl6 bug_$a.p6; done;
cat bug_1.p6:
class A { has $.a };
sub one { my A @rv = gather for 1..3 { take A.new( :a($_) ) }; return @rv }
my %x; %xsyms = one; %x.say;
result of: perl6 bug_1.p6
(syms = Array[A].new(A.new(a = 1), A.new(a = 2), A.new(a = 3))).hash
cat bug_2.p6:
class A { has $.a };
sub one ( -- Array of A ) { my A @rv = gather for 1..3 { take A.new(
:a($_) ) }; return @rv }
my %x; %xsyms = one; %x.say;
result of: perl6 bug_2.p6
Type check failed for return value; expected 'Array[A]' but got 'Array[A]'
in sub one at bug_2.p6:2
in block at bug_2.p6:3
cat bug_3.p6:
class A { has $.a };
sub one { my @rv = gather for 1..3 { take A.new( :a($_) ) }; return @rv }
my %x; %xsyms = one; %x.say;
result of: perl6 bug_3.p6
(syms = [A.new(a = 1), A.new(a = 2), A.new(a = 3)]).hash
cat bug_4.p6:
class A { has $.a };
sub one ( -- Array of A ) { my @rv = gather for 1..3 { take A.new(
:a($_) ) }; return @rv }
my %x; %xsyms = one; %x.say;
result of: perl6 bug_4.p6
Type check failed for return value; expected 'Array[A]' but got 'Array'
in sub one at bug_4.p6:2
in block at bug_4.p6:3
Regards,
Richard (finanalyst)
Class attribute introspection
Perhaps I am using class incorrectly, but I set up a class, then change
some of the parameters in an instance of the class. Next I would like to
discover what the current state of the instance is.
However, I could find no specification of how to access multiple
attributes, as opposed to multiple uses of methods.
Assume, class A {has $.a; has $.b; method abc {say 'some'} }; my A $x
.=new(:a(5), :b(6));
Note that indirection is possible with class methods, using
$x.$methodname, but the same does not exist for attributes.
It is possible to get a list of attributes with $x.^attributes but how
then to turn that list into accessors?
I found the following works inside the class definition:
class B {has $.a; has $.b; method state {for self.^attributes { say
\$x$_ = ~ eval qq[ $_ ] } } };
my B $x .=new(:a(5), :b(66));
$x.state;
but that seems to be a bit of a hack. Also I have not found a nice way
to achieve the same outside the class definition
What have I not seen?
Regards,
Richard finanalyst
Re: Class attribute introspection
Moritz,
You are the everflowing font of knowledge. Thanks.
However, I read the synopsis on objects and did not find the .get_value
method.
Pardon the ignorance, but what is the MOP. I sometimes get floored by
the jargon.
I read about the indirection for methods, but how does that relate to
attributes?
Richard
On 10/28/2013 01:45 PM, Moritz Lenz wrote:
Hi Richard,
On 10/28/2013 08:07 AM, Richard Hainsworth wrote:
Perhaps I am using class incorrectly, but I set up a class, then change
some of the parameters in an instance of the class. Next I would like to
discover what the current state of the instance is.
There is a way to introspect through the MOP:
class A { has $!x = 42; };
my $obj = A.new;
say A.^attributes[0].get_value($obj);
It's not straight forwards, and that's actually a feature :-)
The usual way to go is through the accessors, and indirect method
calls with $obj.$name();
Cheers,
Moritz
Re: Defining Perl 6 for the masses
There are two issues here. a) Using language in a consistent manner in Perl6 space - the word 'specification' is used in Perl6 space both in the way it has become acceptable in computer language design circles, but also in a new and more nuanced way in Perl6. - Perl6 is being developed using Larry Wall's 'whirlpool' model, as opposed to the 'waterfall' model, and this has an impact on the use of 'specification'. - The result of this double use is a sort of schizophrenia in Perl6's documentation when it comes to defining itself. - Possibly the schizophrenia is useful - a manifestion of junctions :) b) Educating the world about Perl6 - There are several attempts to address this issue. - The problems addressed by Parrot Raiser exist and are understood by many of the developers. - My guess is that it will be solved in multiple ways. - We should remember that the way today's mature languages, such as Perl5, C, Fortran etc are taught today has been developed over many years. On 09/30/2013 10:39 PM, Parrot Raiser wrote: This is related to the conversation on the Synopses, but its sufficiently different that it probably justifies its own thread. I want to start by making it clear that I'm not criticising the design of Perl 6, or any of the people working so hard to make it great. I'm just trying to address what I see as an obstacle to its adoption, (but may smply be my personal limitations). I've been following the project from the beginning, and have Perl 6 and Parrot (2nd. ed), http://shop.oreilly.com/product/9780596007379.do which I understand is no longer relevant. snip
Re: Introduction to Synopses
On 09/30/2013 02:16 AM, Patrick R. Michaud wrote: On Mon, Sep 30, 2013 at 02:03:43AM +0800, Richard Hainsworth wrote: Not wising to disagree with PM, but |docs/feather/syn_index.html states on line 1:| The Synopsis documents are to be taken as the formal specification for Perl 6 implementations What follows is just my opinion, there's plenty of room for reasonable disagreement. It would be useful at some stage to come to a consensus about how to describe Perl6. Over the last couple of years I've come to disagree with this statement in syn_index.html . Informally we often talk about the synopses as being the official spec, and I'm as guilty of that as anyone else. Larry Wall's ideas about language development differ from the paradigm that existed before. In one of the paradigms, a language designer creates a specification (eg. C) and then an implementation is created. This leads to the necessity for very tedious and specific specs. As pointed out in Synopsis 1, it implies perfect knowledge before the language has been created. What's new here is the three different components all moving together, and also that the language is defined in terms of both the specification and the tests. In the traditional sense, the specification of Perl6 is the combination of Synopses and Test Suite. But the Synopses on their own do not define Perl6, as you have pointed out. What I have suggested is to use another word describe (or perhaps define might be better) instead of specify. Specification has been used in the Perl6 community to mean the Synopses so I suggest keeping that identity. However, we use another word to describe the combination. Even the name of the repository holding the synopses is given as specs. But as all of us know, some parts of the synopses are incredibly slushy, or even quite fluid, and so it's not something that people can really treat as truly specification. And there are countless parts of the synopses that have radically changed as a result of lessons learned in implementation... (I can tell long stories about S05!). Thus it was recognized early on (in Synopsis 1) that acceptance tests provide a far more objective measure of specification conformance than an English description. There are likely things that need to be spec that cannot be fully captured by testing... but I still believe that the test suite should be paramount. Perl6 language development is a gradual change of specification, test suite and implementation until the specification is proven by implementations, which all pass the test suite, for some sense of 'proven' and some set of 'implementations'. A version of Perl6 is described by the combination of a specification suite and a test suite. I'd prefer that versions of Perl 6 be captured solely by the test suite. I don't know how practical this is, though. I don't like the notion of specification suite... it feels too nebulous to me. A version of Perl6 is declared to be ready when there is at least one full implementation exists that generates code considered to be sufficiently fast and memory efficient. I also don't like the idea of defining readiness in the abstract. Something is ready when it is capable of solving the problem(s) to which it is being put. When is can a version of Perl6 be considered to have evolved? Rakudo is already being used to solve problems. I have used it to solve problems. Maybe not a vast range of problems, nor is the speed impressive. A language is in itself an abstract thing. Pm
Re: Introduction to Synopses
Not wising to disagree with PM, but |docs/feather/syn_index.html states on line 1:| The Synopsis documents are to be taken as the formal specification for Perl 6 implementations I have seen elsewhere, can't remember where, that the parser written by Larry is also considered a part of the specification. Is this correct? From Synopsis 1: Perl 6 is anything that passes the official test suite hacking on any implementation of Perl 6 to make it conform to the test suite ... hacking on the test suite to make it reflect consensus of specification parts of the spec are already effectively frozen ...specced features ... not ... proven in an implementation ... considered ... conjectural May I suggest we add the following language to Synopsis 1 to capture all these statements? Perl6 language development is a gradual change of specification, test suite and implementation until the specification is proven by implementations, which all pass the test suite, for some sense of 'proven' and some set of 'implementations'. A version of Perl6 is described by the combination of a specification suite and a test suite. The specification suite consists of the Synopses and the parser written in Perl6 A full implementation generates code that passes the entire test suite. A version of Perl6 is declared to be ready when there is at least one full implementation exists that generates code considered to be sufficiently fast and memory efficient. On 09/29/2013 09:13 PM, Patrick R. Michaud wrote: On Sun, Sep 29, 2013 at 01:28:48PM +0800, Richard Hainsworth wrote: However, the Synopses are now primary specification and the Apocalypses have only historical significance. Also there are more Synopses than Apocalypses. One correction: The test suite (roast) is the primary specification (see Synopsis 1). To me, the Synopses are the English description of our understanding of the specification / language, as well as a roadmap for growth in the future. Pm
Introduction to Synopses
Some suggestions about documentation. Originally the Synopses were implementation oriented sumaries of the previous description base Apocalypses. That meant that the Synopses were derivative and secondary to the Apocalypses However, the Synopses are now primary specification and the Apocalypses have only historical significance. Also there are more Synopses than Apocalypses. I suggest the introductory paragraphs to the Synopses are changed to reflect this. It might also be useful to have a Synopsis 0 or Synopsis - index that documents the historical progression and indexes the Synopses. For completeness of language specification, Synopsis 0 could list the other documents that form a part of the language definition, such as the test suite.
Are set operations needed?
Are set operations needed in Perl6? No implementation of the perl6 set specification yet exists (AFAIK). The question occurred to me as I have been working my way through a new book on foundational maths not based on sets (http://homotopytypetheory.org/book/). Foundations of maths, until recently, has been done in terms of set theory and first-order logic. I wondered whether the desire to have sets in perl6 was driven by mathematical fashion sensitivity (in some roundabout unconscious way) and because sets are important to mathematical foundations. Given that foundational maths may now be done (strictly the goal has not yet been fully achieved) in homotopy type theory (HoTT), perhaps the imperative to have sets in perl6 is no longer as strong? An interesting thing about HoTT is that part of it, namely type theory, has been driven by computer science. Indeed, part of the power of HoTT is that it is possible to create computer-aided proof assistants. Sets do not implement well on a computer. In other words, perhaps sets, which have already been ring-fenced by existing implementations, can be cut from the perl6 specification altogether? Richard Hainsworth finanalyst
Re: [perl6/specs] 34fddf: [S32::Str] substr is not rw anymore, but substr-rw...
I noticed that subst-rw does not have is export in the definition. Does this mean that subst-rw is not available outside the module? Richard On 06/09/2012 02:20 PM, GitHub wrote: Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 34fddf7788493098ac569f1cea7f214ce1ea1f2c https://github.com/perl6/specs/commit/34fddf7788493098ac569f1cea7f214ce1ea1f2c Author: Moritz Lenzmor...@faui2k3.org Date: 2012-06-09 (Sat, 09 Jun 2012) Changed paths: M S32-setting-library/Str.pod Log Message: --- [S32::Str] substr is not rw anymore, but substr-rw is
On fashion, in Re: The trouble with awesome
On 05/23/2012 03:35 AM, Parrot Raiser wrote: Perl 6 is awesome. agreed snip In short, Perl 6 is awesome: Extremely impressive or daunting, inspiring awe. http://oxforddictionaries.com/definition/awesome?view=uk That is a problem, if we want to get it adopted widely and quickly. Not convinced 'getting it adopted' should be a goal in itself. A major goal is to ensure perl6 implementations can be utilized in every relevant environment. We have unix and windows, but I'm not sure we have android or iOS. And other important environments include browsers (scripts embedded in html). The popularity of a language amongst programmers seems to be a function of fashion and ease of doing something that is fashionable. So perl became THE language for the internet at one time because it linked in so easily to the scripting url syntax. php became popular due to the ease of mixing html code with scripting language, and so on. Personally, I would like to be able to write perl6 scripts (even if only a subset of perl6 was available) that can be embedded in html files. Since perl6 is just so much more elegant than javascript, it would attract a lot of programmers. Fashion is not everything of course. perl was well designed, so even though the internet fashion for perl declined, to be replaced by other languages, programmers continue to use it for other reasons. For the same reason, once perl6 infects the programmer population, it will be used more widely because it is well designed. At some point, I think, there will be a fashionable problem area which will be most easily solved using perl6 - eg., the grammar aspect is just so different from anything else I have seen that I am sure it will find a use. In short, the gap between the status of perl6 as an interesting phenomenon for computer language scientists and the status of perl6 as a widespread standard for programming will be bridged - I suggest - by the appearance of a killer problem domain, a type of problem that is faced by many programmers and which is more easily handled in perl6 than in any other language. It would also help for perl6 activists to demonstrate just how well perl6 works in that domain, and that will require tutorials, articles, etc. So educational texts are important, but secondary to the problem domain. snip The problem we have is to provide a path for learning 6, that presents a comprehensible but useful subset of the language to the average user as soon as possible, while leading the programmer with more complex needs, (and greater abilities), to the features they need or will appreciate. Crucial to this post is the set of assumptions around 'average user', assumptions that appear to me to be US-centric. The population of programmers resident outside the USA will soon exceed (if it has not already exceeded) the number within the USA. perl6 has been designed to be agnostic to human readable languages and scripts, and that might have an effect too if it is easier in perl6 to deal with non-English texts.
Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul
If you're asking for an explanation of the humour, then it's easy. There is no word play or a significant reference to a program only available to a special audience. Seems to me that when Damian got to the end of his email he noticed that each sentence ended in a '?' That's not usual. Most emails contain assertions and questions. The humour is really when he appended a ? to his own name. Was he really questioning what he was called? Richard On 08/23/2011 02:19 PM, philippe.beauch...@bell.ca wrote: Help us always-explains-the-joke-man!!... :) Philippe R. Beauchamp Secure Channel | Bell Business Markets Associate Director - Application Services Phone: 613-781-8953 Cell:613-327-6928 - Original Message - From: Moritz Lenz [mailto:mor...@faui2k3.org] Sent: Tuesday, August 23, 2011 04:56 AM To: perl6-language@perl.orgperl6-language@perl.org Subject: Re: [perl6/specs] a7cfe0: [S32] backtraces overhaul Am 23.08.2011 10:46, schrieb Damian Conway: It's a trivial point, but why hidden_from_backtrace instead of hidden-from-backtrace? Especially given that the associated method is is-hidden, not is_hidden? The current stance seems to be that low-level things are spelled with underscores, while we reserve the minus character for user-space code. Try grepping the specs for identifiers of built-ins that have a minus in it -- I didn't find any in a quick search. And why is this entire message written in questions? Is it? I'm afraid I don't understand what you mean. See https://github.com/perl6/specs/commit/a7cfe02002f665c120cf4b735919779820194757 maybe it's a charset problem on your machine, or something. Cheers, Moritz
Re: exponentiation of Duration's
On 11/17/10 14:03, Moritz Lenz wrote: Am 17.11.2010 10:31, schrieb Kris Shannon: $duration * $duration# WRONG, durations aren't geometric $duration * 2# ok, a duration twice as long 2 * $duration# same What are your thoughts? I've summarized my thoughts here, before I read your email: http://perlgeek.de/blog-en/perl-6/real-world-strikes-back.html Ignoring the sarcasm, Moritz's blog and reply seem reasonable about what should be defined by perl. Once a number has been generated, viz., by obtaining a duration, that number can be manipulated however necessary. The interpretation of the number is a matter for the programmer, not the language designer. To illustrate, lets take a different problem. Suppose we have lengths in $x and $y, then the dimension of $a = $x * $y is of area, not of length. Is it really consistent to forbid $x = $x * $y in case the $x may be mistakenly interpretted as a length and not an area? In the same vein, $duration * $duration has the physical dimension of duration squared. True that is not the dimension of duration, and so assigning it to a duration variable might cause a problem of physical interpretation. Neverthless, it doesn't seem to me that trapping dimension errors is something a programming language should be doing. Or am I missing something? Richard
Re: [perl6/specs] 761178: remove some some duplicate words words
I do want the diffs back: its the only way I have to keep at least some idea of what is changing any why. Dont care if I'm called an old foggy either - 1997 wasnt that long ago for me. On 09/08/10 13:32, Jan Ingvoldstad wrote: On Wed, Sep 8, 2010 at 07:41, Jason Switzerjswit...@gmail.com wrote: I'm surprised anyone actually ever read the diff part of the message. I would prefer to never see that feature again. This has a link to the commit, which has a much better diff viewer than plaintext email (hello? 1997 called, they want their change notices back). In some respects, I want 1997 back, since people learned how to work efficiently rather than not. ;) I both like and can read the contextual diffs just fine. It links to the actual change and even highlights the changes. Yes, it's all very nice, and nothing that needs to go away. Having it both ways can't hurt. Now I'll actually take a moment to sift through the changes. I vote to never see those diff emails ever again. In fact, if the diffs are brought back, I'll just subscribe to the commit feed and skip the email notice all together. That seems like a reasonable solution for you, then.
Filesystems and files [Was: Re: The obligation of free stuff: Google Storage]
If I might offer a late viewpoint after reading the Aaron's expanded
email (attached below).
When originally I suggested using 'open' instead of 'connect', the aim
was to keep consistency with the paradigm of files on the local system.
However, as Aaron's post suggests, when dealing with remote 'files',
there is an additional layer of functionality that must be introduced,
namely the need to 'connect' to the filesystem so that files on it can
be opened. Thus it is wrong to conflate 'open' with 'connect'.
It is normally implied that a program already has a 'local' environment,
including a 'local' filesystem. Thus the syntax
my $fn = open('/path/to/directory/filename', :r) or die $!;
implies a local file sytem.
The idea of an implied local system suggests an implied local
environment. The contents of %*ENV and @*INC seem to be assumed to be
local, thought this is not specified. Given the development of the
internet, this is an assumption I think should be made implicit, as well
as the mechanism for adding remote resources via paths through a network.
Would it make sense to define $*FS as the implied local file system, and
thus that a bare 'open' is sugar for
my $fh = $*FS.open('/path/to/directory/filename', :r);
This then means that there is an implicit
$*FS.connect();
that makes the local system available to the program.
I wonder whether this would also be a way of unifying the program
interface for difference Operating Systems, in that a program running on
a *nix machine would have $*FS of type IO::Filesystem::POSIX, while $*FS
for a Windows machine would have type IO::Filesystem::Windows, etc.
Then it would be possible, as Aaron has suggested to have
my $remote-fs = IO::Filesystem::Google.connect(%args);
my $fh = $remote-fs.open($path-or-url, :r);
and then treat $fh as specified elsewhere.
Morover, it would then be possible to do
$*FS = $remote-fs;
I would propose that this sort of flexibility would be useful for
programs that are embedded in other virtual environments, such as
browser plugins, or programs intended to run on thin clients that do not
have their own filesystems.
Another possibility would be to have
my $windows-from-linux = IO::Filesystem::Windows.connect(%args);
my $linux-system = $*FS;
$*FS = $windows-from-linux;
And then the files on a dual boot system can be accessed by the program.
On 06/21/10 02:35, Aaron Sherman wrote:
First off, I again have to caution that this thread is conflating
open with filesystem interaction. While open is one of many ways of
interacting with a filesystem, it isn't even remotely sufficient (nor
my immediate focus). One can ask for and modify filesystem metadata,
security information, and so on as well as that for individual objects
within the filesystem (which in the POSIX model is mostly files and
directories). In a traditional POSIX/Unix model, programs (other than
key OS utilities) don't usually do much with the structure of the
filesystem. That's meant as an interactive task for an admin. However,
in building a cloud-storage aware VFS-layer, managing the filesystem
in terms of layout, allocation, security (access methods,
authorization and authentication), payment models, and many other
features are expected to be embodied in the access model. Just as an
example, choosing and laying out what Amazon calls buckets is the
equivalent of partitioning. That does need an interface.
Now, we can just translate the Python bindings for Google Storage (and
I believe there are already Perl 5 bindings for Amazon S3), but my
inclination is to build a generic VFS that can handle POSIX-like
filesystems as well as everything else from Windows/Mac specific
features to full-blown cloud storage to more user-oriented storage
options (Dropbox comes to mind).
Every addressable storage model which could be treated as a filesystem
should have a place in the Perl 6 VFS.
Now, as to the question of overloading open... I'm not sure. I mean,
it's pretty easy to say:
URI.new($path).open(:ro)
or
open(URI.new($path), :ro)
When what you want is a VFS object, and I kind of like the idea of the
standard open on a string having POSIX semantics.
Now, to your question, C.J.
On Fri, Jun 18, 2010 at 3:03 PM, C.J. Adams-Collier
c...@colliertech.org wrote:
Define opening a file for me. Is it something that's associated with a
filehandle, by definition? Do TCP sockets count?
Opening a file isn't a well defined operation. You have to be more specific.
In your question you're conflating the evaluation of a filesystem
namespace token (which is one of many possible modes of filesystem
interaction), returning a filehandle object that represents access to
the named object with evaluation of a socket namespace token and
returning a similar filehandle object that represents that object.
There are, of course crossovers (filesystem pipes) and other
operations that yield filehandle objects (various IPC operations that
aren't exactly
Re: The obligation of free stuff: Google Storage
Ideally [at least, what I would like], managing a file on a remote
resource should be the same as managing one locally, eg.
my Amazon $fn = open($path-to-input-file-location/$file-name, :r) or
die $!;
for $fn.readlines { };
$fn.close;
my Google $fn = open($path-to-output-file-location/$file-name, :w) or
die $!;
for @lots-of-data - $item { $fn.say: $item };
$fn.close;
If it is possible to make file on a cloud system as easy to manipulate
as a local file, that will aid the acceptibility of perl6.
Hence, the use of 'open', 'close', 'say', 'readlines', rather than
'connect', 'put', 'get'.
The issue - it seems to me - is that the connection between a computer
and its local filesystem has such a low probability of failure (viz.,
disk failure or disk full) that is can normally be ignored, but there is
relatively high probability of a connection failure between the computer
and a remote site and so it would be normal to have exception handling
in the code.
That means the designer of the API should indicate how these exceptions
should be handled so that a program doesnt hang in a loop that is
expecting data from a remote resource whose server has disconnected.
On 06/10/2010 03:24 AM, Aaron Sherman wrote:
On Wed, Jun 9, 2010 at 10:04 AM, Aaron Shermana...@ajs.com wrote:
Has anyone begun to consider what kind of filesystem interface we want
for things like sftp, Amazon S3, Google Storage and other remote
storage possibilities? Is there any extant work out there, or should I
just start spit-balling?
In the absence of anything forthcoming and a totally arbitrary sense
of urgency ;-) here's what I think I should do:
IO::FileSystems (S32) gives us some basics and the Path role also
provides some useful features.
I will start there and build an IO::FileSystems::VFS roughly like:
class IO::VFS is IO::FileSystems {
...
# Session data if applicable
has IO::VFS::Session $.session;
# Many methods take a $context which, if supplied
# will contain back-end specific data such as restart markers
# or payment model information. I'll probably define
# a role for the context parameter, but otherwise
# leave it pretty loose as a back-end specific structure.
# A simple operation that guarantees a round-trip to the filesystem
method nop($context?) { ... }
# list of sub-IO::VFS partitions/buckets/etc
method targets($context?) { ... }
method find_target($locator, $context?) { ... }
# Means of acquiring file-level access through a VFS
method find($locator, $enc = $.session.encoding, $context?) { ... }
method glob(Str $matcher, $enc = $.session.encoding, $context?) { ... }
# Like opening and writing to filehandle, but the operation is totally
# opaque and might be a single call, senfile or anything else.
# Note that this doesn't replace $obj.find($path).write(...)
method put($locator, $data, $enc = $.session.encoding, $context?) { ... }
# Atomic copy/rename, etc. are logically filesystem operations, even though
# they might have counterparts at the file level. The distinction being that
# at the filesystem level I never know nor care what the contents of the
# file are, I just ask for an operation to be performed on a given path.
method copy($from, $to, $enc = $.session.encoding, $context?) { ... }
method rename($from, $to, $enc = $.session.encoding, $context?) { ... }
method delete($locator, $enc = $.session.encoding, $context?) { ... }
# service-level ACLs if any
method acl($locator, $context?) { ... }
}
The general model I imagine would be something like:
my IO::VFS::S3 $s3 .= new();
$s3.session.connect($amazonlogininfo);
my $bucket = $s3.find_target($bucket_name);
$bucket.put(quote.txt, Now is the time for all good men...\n);
say URI: , $bucket.find(quote.txt).uri;
or
my IO::VFS::GoogleStorage $goog .= new();
$goog.session.connect($googlelogininfo);
my $bucket = $goog.find_target($bucket_name);
$bucket.put(quote.txt, Now is the time for all good men...\n);
say URI: , $bucket.find(quote.txt).uri;
or
my IO::VFS::SFTP $sftp .= new();
$sftp.session.connect(:hoststorage, :userajs, :passwordiforgotit);
my $filesystem = $sftp.find_target(/tmp);
$filesystem.put(quote.txt, Now is the time for all good men...\n);
say URI: , $filesystem.find(quote.txt).uri; # using sftp:...
Notice that everything after $obj.session.connect is identical except
for my choice of variable names. In fact, you shouldn't have to worry
about what storage back-end you're using as long as you have a valid
VFS handle. Really path names are the only thing that might trip you
up.
Thoughts?
I think that in order to do this, I'll need the following support
libraries which may or may not exist (I'll be looking into these):
IO::FileSystems
Path
HTTP (requires socket IO, MIME, base64, etc.)
Various crypto libs
I don't intend to provide a finished implementation of any of these
where they don't already
Parallelism and Concurrency was Re: Ideas for a Object-Belongs-to-Thread threading model
After reading this thread and S17, I have lots of questions and some remarks. Parallelism and Concurrency could be considered to be two different things. The hyperoperators and junctions imply, but do not require, parallelism. It is left for the implementors to resolve whether a single or multiple processor(s) is/are used. Hence, parallelism could be considered to be something under the hood of perl6 and not directly specified. Given that: - concurrency is a topic of ongoing research - several models of concurrency have been tried, including two in perl5 - there are a variety of contexts (internet, clouds, multiple cores, etc) - different operating systems provide different resources then: How much needs to be specified and implemented in perl6 so that different concurrency models can be implemented in modules to take into account the above diversity? The less, or rather the more abstract, the specification in perl6, the less likely perl6 will 'age'. On 05/12/2010 09:12 PM, Dave Whipp wrote: Daniel Ruoso wrote: Hi, The threading model topic still needs lots of thinking, so I decided to try out some ideas. Every concurrency model has its advantages and drawbacks, I've been wondering about this ideas for a while now and I think I finally have a sketch. My primary concerns were: 1 - It can't require locking: Locking is just not scalable; 2 - It should perform better with lots of cores even if it suffers when you have only a few; 3 - It shouldn't require complicated memory management techniques that will make it difficult to bind native libraries (yes, STM is damn hard); 4 - It should suport implicit threading and implicit event-based programming (i.e. the feed operator); 5 - It must be easier to use then Perl 5 shared variables; 6 - It can't use a Global Interpreter Lock (that already said in 1, but, as this is a widely accepted idea in some other environments, I thought it would be better to make it explicit). The idea I started was that every object has an owner thread, and only that thread should talk to it, and I ended up with the following, comments are appreciated: comments? ideas? Before discussing the implementation, I think it's worth while stating what it is that you are attempting to abstract. For example, is the abstraction intended for a mapping down to a GPU (e.g. OpenCL) with a hierarchical address space, or is it intended for a multicore CPU with linear address space, or is it intended to abstract a LAN, with communication via sockets (reliable TCP? unreliable UDP?), or is it intended to abstract the internet/cloud? Are you thinking in terms of streaming computation where throughput is dominant, or interacting agents where latency is the critical metric? I'm not sure that it makes sense to talk of a single abstraction that supports all of those environments. However, there may be bunch of abstractions that can be combined in different ways. object belongs to thread can have two interpretations: one is that the object-thread binding lasts for the life of the object; the other is that a client that wishes to use an object must request ownership, and wait to be granted (in some scenarios, the granting of ownership would require the thread to migrate to the physical processor that owns the state). In many cases, we might find that specific object-state must live in specific places, but not all of the state that is encapsulated by an object lives in the same place. Often, an object will encapsulate state that is, itself, accessed via objects. If a model requires delegated access to owned state to be passed through an intermediate object then this may imply significant overhead. A better way to think about such scenarios may be that a client would request access to a subset of methods -- and thus we have role belongs to thread, not object belongs to thread. One could imagine that a FIFO object might have a put role and a get role that producer/consumer clients would (temporarily) own while using (note that granting of ownership may imply arbitration, and later forced-revocation if the resource-ownership is not released/extended before some timeout expires). It may be wrong to conflate role as a unit of reuse with role as an owned window onto a subset of an object's methods. Perl6 has a set of language primitives to support various aspects of concurrency. It is indeed interesting to consider how these map ot vastly difference computation platforms: OpenCl Vs OpenMP Vs Cloud. It deeps a little premature to be defining roles (e.g. RemoteInvocation) without defining the mapping of the core operators to these various models of computation. Dave.
Proposal for a new Temporal time-measurement paradigm
and one calendar, do date-time arithmetic at the Instant level, then use the resulting Instant to find the result date-time in another time-zone and another calendar. All the leap second, leap days, and daylight saving differences would automatically be taken care of. Regards, Richard Hainsworth (finanalyst)
Re: underscores vs hyphens (was Re: A new era for Temporal)
Damian Conway wrote: Personally, I'd prefer to see the English conventions carried over to the use of general use of hyphen and underscore in identifiers in the core (and everywhere else). By that, I mean that, in English, the hyphen is notionally a higher precedence word-separator than the space (or than its intra-identifier stand-in: the underscore). More is better. It was better to have upper as well as lower case letters in variables. It is better to have - as well as _ The more specialised use of upper case letters, such as SYSTEM identifiers, seems to have evolved over time. Depending on my fancy, I sometimes use variables like OriginalValue and sometimes Starting-value. If the program is just for me, who cares? If the software is for a company, they will set the rules. Communities at large generate their own standards. Where it matters, people obey them. Where rules are set because it is supposed to be a good thing, programmers take delight in breaking them. Personally, the rule use only - or _ consistently throughout a module reeks of a rule for rule's sake, one for the breaking. Damian's suggestion seems to me very useful because (for those that wish to follow it) it imposes an extra precision of thought, which almost always facilitates better programming. Adopting it will, I think, lead to more elegant code, for those that like that sort of thing. Regards, Richard
Re: perl6 compiler
I too re-read PM's journal. Note his explicit desire to avoid 'stability' as a goal at this stage for rakudo because of its imprecision. We often use words that have different shades of meanings for different people/situations, eg., what is a 'short' time? Consider how a child might answer, as opposed to an old person. Suppose a historian is speaking, as opposed to an archeologist, or a geologist, or an astronomer. So 'stability', which is related to a concept of time, depends on the nature of the task. If you want a language so set in stone that every aspect of it is known and imutable, and has a syntax and functionality that will not be changed for the forseeable future, then you need a language that is a fossil. Given the short history of computer science in the context of human history, fossilised languages are no longer interesting to modern developers. Indeed, virtually nothing in the computer world has much stability: how often do operating systems change - Ubuntu updates every six months and people consider this a feature rather than a flaw. The Windows cycle is something like two-three years, with changes in the formats of MS Office files, eg., doc/docx. Consequently, Patrick chose a definition for rakudo * that is appropriate for this stage in the development of perl6. It will not be appropriate for everyone, but that is the nature of life. Personally, I am looking forward to rakudo *. Richard Matthew Wilson wrote: As written in pmichaud's journal entries, stability is explicitly *not* (and never was) one of the goals of the April 2010 release of Rakudo. On Fri, Mar 19, 2010 at 7:24 AM, Steve Pitchford steve.pitchf...@gmail.com wrote: I think this question was largly addressed in the first link? On Fri, Mar 19, 2010 at 12:59 PM, Wendell Hatcher wendell_hatc...@comcast.net wrote: I actsully read the fact sheets in the past and want to confirm that a stable production qaulity release of perl6 is coming out this April or at the berry least the summer snip
Stability domains in rakudo *
I know PM does not like the word 'stability' for language development, and I have just posted a response to Wendell Hatcher's question justifying Patrick's approach. However, some other questions arose when I was considering 'usability', which Patrick sets as a goal for Rakudo *, as opposed for 'stability'. I have already written an application in Rakudo (alpha) to process data in my commercial field and to indirectly obtain graphical output, and the results were published in a banking journal (in Russian). So in a sense, Rakudo alpha was usable. The problem is that each time I want to reuse the program, I need to tweak some part to handle changes in spec. I want to be able to re-run the application each month to handle incremental data, but before I can hand this off to the operations people, there needs to be some form of stability in the areas that are utilised in the application. This is a very small real-world application. But in order for more real-world applications to be written, there has to be some assurance that once the code is working and tested, it can be left unattended for some reasonable period of time, eg., a year. Without some form of assurance about the type of maintenance, it is not possible to justify allocating resources to 'real-world' applications, and thereby provide the feed-back needed by language designers. Suppose we define a domain of stability as syntax/functionality/features that will not be changed until a milestone is reached, with the guarantee that if the language specification changes before then, backwards compatibility will be retained so that the syntax/feature/functionality will continue to function without a need to change it or the surrounding code. Perhaps different levels of stability could be defined for different domains, eg., 'fossilized' : syntax/functionality/features set in stone for the lifetime of the language, eg., until perl7. 'stable': syntax/functionality/features are stable until the next major review, eg., perl6.1 'organic': ... may change but modifications will be flagged with a deprecation notice and a deadline after which syntax/feature/functionality will not be supported in current form. 'experimental': subject to change at will, to be avoided if 'stable' code is needed. In this way, subsets of the language can be defined to have different levels of stability, thus allowing developers to choose how to write code and to know what level of maintainability will be needed. It seems to me this sort of approach is consistent with the whirlpool / strange attractor concept of language design, whilst addressing the desire of commercial developers to be able to predict the resources needed to write and maintain code.
[Fwd: Re: Where's the release announcement?]
Re-posting to list. Original Message Subject:Re: Where's the release announcement? Date: Sat, 20 Mar 2010 07:39:17 +0300 From: Richard Hainsworth rich...@rusrating.ru To: Darren Duncan dar...@darrenduncan.net References: 4ba329a0.7030...@rusrating.ru 4ba32f1e.70...@darrenduncan.net a45468e31003190603l65d068fqa695e0bb34174...@mail.gmail.com 4ba3c76e.1050...@darrenduncan.net But I have no messages at all for March 18! Before posting to the list, I asked on #perl6 about the announcement, and at least one other person responded that they had seen no announcement on p6l. Actually, I dont particularly care either way about the announcement as I update perl6 from git. Its just that the absence of a milestone announcement is a sort of benchmark. I think I am having some sort of email reception problem. I am not sure where in the chain it is occurring. Hence, I wanted to know whether the release was posted to p6l. If yes, then why do I not see it in my in-box? I also suspected my anti-spam software, but I think I have ruled that out. Another comment on #perl6 indicated that there were some weird timing problems and that p6l was being moderated. Just raising a red flag. So basically it seems that there might be something akilter with the p6l distribution system. Richard Darren Duncan wrote: Will Coleda wrote: On Fri, Mar 19, 2010 at 4:00 AM, Darren Duncan dar...@darrenduncan.net wrote: Richard Hainsworth wrote: Is there a glitch in the mail list system for p6l? I got the Copenhagen release announcement on the parrot developers list but not on p6l. Maybe there aren't Parrot release announcements on p6l because they aren't as directly relevant as say on p6c. In some ways, having Parrot release announcements on p6l is about as relevant as having Perl 5 release announcements on mailing lists for individual Perl modules, or DBI release announcements on the DBIx-Class list, say. -- Darren Duncan FYI, Copenhagen was a Rakudo release, not a parrot release. Ah yes, that's 2 mistakes I made. I read the original message as Richard saying he saw the Rakudo Copenhagen release on both p6l and the Parrot list but only saw the Parrot 2.2 on the Parrot list. In any event, to address the original question, Rakudo #27 Copenhagen was announced on p6l on March 18th. -- Darren Duncan
Re: Versioned Dependencies (Was: Re: Stability domains in rakudo *)
Not really a versioned dependencies. When a working module is updated to have new functionality, the old version continues to work. Here it is the very language that is changing. For instance, =$fh was used to generate input from a file. Now it is $fh.lines Old examples that I wrote using =$fh have to be changed. But there are parts of the language that have stablized, such as regexen, if/given/take statements. There are others that still havent been written, such as sets and the specs on concurrency. Suppose you have a solution that would be neat using sets. If you are scratching an itch, use sets. But if you want something even semi-permanent, avoid sets. In other words, I am suggesting a sort of mapping of the syntax of perl6 so that stable areas can us be used, perhaps avoiding instruments that are not yet explicitly stable. Daniel Ruoso wrote: Em Sáb, 2010-03-20 às 12:16 +0300, Richard Hainsworth escreveu: Suppose we define a domain of stability as syntax/functionality/features that will not be changed until a milestone is reached, with the guarantee that if the language specification changes before then, backwards compatibility will be retained so that the syntax/feature/functionality will continue to function without a need to change it or the surrounding code. I think this is more a case for versioned dependencies. I'm not sure this is written down anywhere in the spec, but I guess there should be a way to tell this code was written targetting version $x of the implementation $y - if the code is compiled to bytecode that is really easy. Then the implementation might have a way to adapt itself to provide the intended semantics. Of course this requires an entire different set of maintainance challenges, including a very precise delta documentation and probably a lot of coercion functions, i.e: coerce from Int version 0.003 to Int 0.004 back and forth. That way we have both the grammar, the CORE and the setting being versioned, and it will be easier to adapt for the future... daniel
Where's the release announcement?
Is there a glitch in the mail list system for p6l? I got the Copenhagen release announcement on the parrot developers list but not on p6l. Also activity on p6l seems light recently, but this may just be random flow fluctuation.
Re: Temporal seems a bit wibbly-wobbly
To add to Daniel's comment. Lets recast the time/date discussion in another way. The way times and dates are quoted (human time) depends on: - religion denomination: the Jewish, Muslim, and Bahai religions have their own calendars as part of their religions; Orthodox and Catholic (including Protestant) denominations have different calandars. - Time Zone, which can differ from GMT by halves of an hour. - The legal jurisdiction. - Zero instant. Specifying any mechanism for providing a 'human' time requires a decision about all of the above. Perl6 is agnostic and so does not specify anything that requires a religious or location bias. Clearly, such decisions are necessary, but these will be made by the implementor, rather than being set in stone in the specification. Clever implementors will provide mechanisms to adapt the Time/Calendar decisions to suit the individual programer. In all situations, how time is counted is crucial and the current reasonable standard is TAI. Hence this is in the Perl6 specification. In terms of usage, most people, if you think about it, are actually more interested in durations, what happens between a finite start and a finite end, than we are in some form of eternity, viz, time from a distant beginning to the present. Regards, Richard Daniel Ruoso wrote: 2010/2/22 Mark J. Reed markjr...@gmail.com If the interface between Perl time and human time is going to be done through UTC, then I don't see the point in specifying that it's TAI behind the scenes. Especially if you're not specifying the epoch. The number of seconds between two points in time in UTC is exactly the same as the number of seconds between two points in time in TAI, by definition. Only the labels differ. And if, as you imply above, the labels will be UTC - which they pretty much have to be since that's what humans use - then Perl6 is using UTC, not TAI. It's just using *real* UTC, not POSIX's broken idea of it that claims 24 seconds out of the past 40 years never happened. Okay, most replies are in the same tone, so I'll reply just here... The problem is with the idea that TAI or UTC are the interface between Perl time and Human Time, because that implies we could neglect the semantics of the input type and store everything in a number of TAI seconds since the epoch (after converting from the localtime to UTC) and store it like that. DatesTimes are just not that simple, if I say 2009-01-01T00:00:00-0300 it can't simply be converted to UTC then to TAI and be stored like that. because that would mean a different year, and that semantic is not neglectable. That is why the Instant is not just a number, but a full specification of a given instant. Which might say 2009-01-01T00:00:00 BRT which happens to be GMT-3 but a few years ago had DST (it's in the south emisphere, so summer time), but it doesn't have it nowadays. More importantly, an Instant is not a Duration since some epoch. Instant and Duration are completely different beasts, for instance... a Gregorian duration of 1 day is not the same as 86400 seconds, simply because we have days with 23 hours and days with 25 hours. and adding a day should ignore the number of seconds in that day. As well as adding a month should ignore the numbers of days in the month and so on... So, there isn't one interface between Perl time and Human time, simply because there isn't just one Human time, so we deal with all human times... Note that the same way we have Gregorian::DateTime and Gregorian::Duration, we can have TAI::DateTime and TAI::Duration, Instant and Duration are just the most abstract roles for that types (also note that TAI doesn't have timezones, it started aligned with UTC and drifted away ever since). So why have the duration TAI-based? Simply because TAI is supposedly immutable as a scale, so it's predictable. Gregorian time is not immutable and timezone definitions are not anyhow predictable. So when you get a duration (in the precision of seconds) it specifies an immutable amount of time. But if it's not in the precision of seconds, then well... it can be anything... daniel
Re: r29770 - docs/Perl6/Spec
+the calls stack is actually unwound to run. That is, just because an +exception is thrown past a stack frame does not leave the block, since +the exception might be resumable. It is only if an exception is not +resumed that the stack is unwound the the phasers called. 'just because ...' and? The grammar is out of kilter here and I cant understand what is intended. 'It is only if an exception ...' I would find the following easier to understand: The stack is unwound and the phasers are called only if an exception is not resumed.
Re: Gripes about Pod6 (S26)
a) How many of the gripes are affected by Damian's new draft ? I found many of my pet irritations were eliminated by the new one. b) I suggest that Damian's new draft is committed as S-26 forthwith and development begin on it. c) Some of the comments in threads on documentation have been more aggressive than any of the other perl6 development discussion. More courtesy would be more productive. d) The S-26 document - I think - needs a section at the beginning stating the design goals for the documentation system. Documentation can be written for more than one purpose and not all purposes can be catered for at the same time with a simple specification. By stating goals, it will be clear why and where compromises have to be made. Richard Damian Conway wrote: Carl observed: Partly that is because documentation isn't at the forefront of things that need to be implemented for Perl 6 to be useful, so it's kind of lagging behind the rest. Partly it's because Damian is the owner of that synopsis, and he practices a kind of drive-by-updating to it. As a case in point of this latter effect, the extensive changes made by Damian in August *still* haven't hit the Pugs repo. The latter is entirely true but, fortunately, also very easily remedied. I hereby disclaim all present and future ownership of S26. :-) By all means put the latest update on the repo (or maybe remove S26 entirely), and start redesigning it collaboratively. Please note that I am not in any way upset, angry, petulant, or otherwise disaffected. I only want the very best for every aspect of Perl 6. If the experience of respected and active developers suggests that Pod 6 isn't a step in the right direction, I can only feel disappointed in myself, apologize for my failure, and gratefully turn the task over to those with better ideas and more time and energy to devote to the problem. As regards Pod vs Pandoc (which is pretty clearly the leading contender of the structured text notations), I do think Pod has some decided advantages. For example, I feel it's better to have four basic metasyntaxes (X, =IDENT, :OPTION, #=) and most with identifier-based labels, than to have over two dozen (plus embedded HTML and TeX) all with symbolic labels. I guess I feel that Pandoc/Markdown/ReST/etc. are optimized for writing documentation source, whereas Pod is optimized for reading documentation source. I'm not sorry I aimed for the latter, whatever the deficiencies in the result. Carl also suggested: I think that the future of S26 is very much dependent on whether it'll be able to respond to the needs of Perl 6 developers. Right now it doesn't respond to much of anything. Outwardly this is self-evidently true. One need only look at the (lack of) commit log for S26. :-( Inwardly, something else entirely is happening. A design(er) can only respond effectively when subjected to a clear net force pushing or pulling in some well-defined direction. The redesign of Pod has been subject to an enormous number of such forces. Unfortunately they push and pull it in every possible mutually contradictory direction, thereby producing very little overall impetus. So I would encourage those of you who are going to collectively take over the shepherding of this synopsis to go back through the p6l archives and review the many many posts commenting on and requesting features for Perl 6 documentation. In particular, please look carefully at the very different needs of those who document OO code, procedural code, frameworks, modules, applications, design documents, presentations, and Perl itself. You will find that many of these contributors ignore, discount, or actively disparage the needs of their fellow users. For example, in this very thead: I'm not writing a book, I'm writing code. And if I was writing a book, I wouldn't be dumb enough to write it in POD. Yet what is the Perl documentation itself but a series of book chapters? And surely that documentation is the largest single use of Pod anywhere? Should we not write Perl's own documentation in Perl's own documentation notation? Should we really discourage the use of standard headings to consistently mark the common components of these (and most other) Perl-related documents? I sincerely hope that the future community of designers of Perl 6 's documentation format will find a way to honour and support the very different needs of *all* the creators and users of Perl, not just the needs of the most prominent, or the needs of the most experienced, or the needs of the most loquacious. I have always thought that was the *real* challenge of post-modern language design. Damian
'constitute' is the word. Re: r29540 - docs/Perl6/Spec
Suggest: =head1 Regexes constitute a first-class language, rather than just being strings Brandon S. Allbery KF8NH wrote: On Jan 16, 2010, at 01:47 , pugs-comm...@feather.perl6.nl wrote: -=head1 Regexes are now first-class language, not strings +=head1 Regexes are now a first-class language, not strings I'm not sure if that's the correct reading, or ...now first-class language [elements]. Or possibly using language as a collective concept (compare `$phrase' is now acceptable language in a natural language context).
Re: But vs. With
David Green wrote: I'm wondering whether we can make use of the contrary sense implied by the word but, and have it apply specifically to cases where something is being overridden. In cases where there isn't something to override we could use a different word, such as with. I must admit to finding it difficult to grok the use of 'but' as currently specified. This suggestion (and Jon's amendment) does make the concept much easier to understand. Richard
error installing Perl6
Just got error from new clone rakudo directory, Viz. rich...@jupiter:~/Development$ git clone git://github.com/rakudo/rakudo.git Initialized empty Git repository in /home/richard/Development/rakudo/.git/ remote: Counting objects: 22035, done. remote: Compressing objects: 100% (5908/5908), done. remote: Total 22035 (delta 16176), reused 21484 (delta 15720) Receiving objects: 100% (22035/22035), 2.92 MiB | 925 KiB/s, done. Resolving deltas: 100% (16176/16176), done. rich...@jupiter:~/Development$ cd rakudo/ rich...@jupiter:~/Development/rakudo$ perl Configure.pl --gen-parrot Generating Parrot ... /usr/bin/perl build/gen_parrot.pl --prefix=/home/richard/Development/rakudo/parrot_install --optimize Checking out Parrot r42403 via svn... Can't exec svn: No such file or directory at build/gen_parrot.pl line 47. Configuring Parrot ... /usr/bin/perl Configure.pl --prefix=/home/richard/Development/rakudo/parrot_install --optimize Unknown option: prefix Unknown option: optimize ===SORRY!=== Unable to locate parrot_config To automatically checkout (svn) and build a copy of parrot r42403, try re-running Configure.pl with the '--gen-parrot' option. Or, use the '--parrot-config' option to explicitly specify the location of parrot_config to be used to build Rakudo Perl. Building Parrot ... ===SORRY!=== Unable to locate parrot_config To automatically checkout (svn) and build a copy of parrot r42403, try re-running Configure.pl with the '--gen-parrot' option. Or, use the '--parrot-config' option to explicitly specify the location of parrot_config to be used to build Rakudo Perl.
Re: Freezing role methods
Ovid wrote: At the BBC, we never encounter this because semantically different methods are renamed and semantically identical methods are refactored (aliasing and excluding being code smells). However, if roles start making their way on to the CPAN, you won't necessarily have control over the source code, forcing you to fork or simply not use the role in question. Regrettably, that defeats the purpose of roles -- namely, to facilitate code reuse. Taking this idea further. If roles make their way to CPAN, and code reuse becomes practical, aliasing and excluding are no longer code smells, but appropriate ways of filtering what is wanted from generic code.
Re: Freezing role methods
Ovid wrote:
I recently was trying to research some composition issues with roles and one of
the researchers directed me to this paper:
http://scg.unibe.ch/archive/papers/Duca07b-FreezableTrait.pdf
Basically, the problem they have is this T1 (Trait 1) and T2 each implement a public x()
method and other methods in T1 and T2 rely on their respective versions of x() and trying to rely on another version breaks those
methods. When class C tries to compose these roles, it has a problem. It can't exclude one x() because
that breaks the role which needs the excluded x(). It can't override x() because you'll likely break both roles. You *could*
(this wasn't explained in the paper) extract those methods into C::x(), check your callers and dispatch as appropriate, but that
would get very problematic, particularly with roles composed of other roles.
snip
How would Perl 6 approach this issue?
S14 states:
Roles may be composed into a class at compile time, in which case you
get automatic detection of conflicting methods. A role may also be mixed
into a class or object at run time to produce an anonymous derived class
with extra capabilities, but in this case conflicting methods are
overridden by the new role silently. In either case, a class is
necessary for instantiation--a role may not be directly instantiated.
This indicates to me that for perl6 the conflict is detected and
reported to the programmer to resolve. The compiler is not required to
resolve the conflict.
Later S14 has:
There are several ways to solve method conflicts. The first is simply
to write a class method that overrides the conflicting role methods,
perhaps figuring out which role method to call.
Alternately, if the role's methods are declared |multi|, they can be
disambiguated based on their long name. If the roles forget to declare
them as multi, you can force a multi on the roles' methods by installing
a proto stub in the class being constructed:
proto method shake {...}
Am I wrong in thinking the spec answers the question?
Re: Freezing role methods
Ovid wrote: --- On Thu, 15/10/09, Richard Hainsworth rich...@rusrating.ru wrote: Later S14 has: There are several ways to solve method conflicts. The first is simply to write a class method that overrides the conflicting role methods, perhaps figuring out which role method to call. snip Am I wrong in thinking the spec answers the question? Reading the paper I linked to could help to clarify the issue. In short, there are times under my current understanding of roles where you *can't* resolve the conflicts. Two roles, each providing and dependent upon a method x(), such that if either tries to use the other's x(), the code will fail. Thus, you cannot choose one x() over the other. The paper you linked to states: 2.2 Trait conflict resolution limits While trait composition lets the class composer resolve conflicts by redefining in the composer or ... The paper explains how conflicts arise and they are detected because fundamentally different methods have the same name. But the assumption in the paper is that the class composer resolves the conflict, without further programmer intervention. The perl6 spec does not require the class composer to resolve the conflict only to detect it. Given the explanation in the spec about conflict resolution, it is my understanding that it is the programmer's task to rewrite to eliminate the conflict.
Re: Looking for help updating Perl 6 and Parrot part of Perl Myths talk
For the slides on Rakudo, I would suggest adding the modules that are associated with proto as measure of code written in perl6. There is a list of 27 projects. proto in itself is an interesting installer. Also, the number of tests written for perl6 is substantial (18,000 vs 1,400 for Ruby - your figure). Richard Tim Bunce wrote: page 77 - quantity of code writen in Perl 6 are there any other significant perl6 codebases?
s/ DateTime - Instant / TAI /
Carl Mäsak wrote: Darren (), commit-bot (): +Returns a TAI epoch value for the current time. Shouldn't the result type of time() be an Instant object (Instant and Duration are defined in S02) rather than a Rat? I fear that the Instant from S02 is a fossil. Instant was renamed by Dave Rolsky to DateTime on 2009-02-19. There was fairly extensive discussion. My recollection was that 'Instant' and 'Duration' were preferred. The problem arises because in English the word 'instant' can be several parts of speech (noun - 'in an instant', adjective - 'instant coffee'), and that the adjective is the most common. DateTime is uglier. I cant remember whether there was a definitive resolution to this discussion, other than Dave Rolsky changing the spec and the discussion fading into other questions. Since a TAI epoch value is the underlying metric, how about a 'TAI' as the type (in place of DateTime)? Richard
Re: r28061 - docs/Perl6/Spec
Suggest s/right argument/right-hand argument/ Also suggest s/** 2/** $y/ since it seems strange to be referring to a right-hand argument which, in the example, is a constant. pugs-comm...@feather.perl6.nl wrote: Author: carlin Date: 2009-08-25 08:48:35 +0200 (Tue, 25 Aug 2009) New Revision: 28061 Modified: docs/Perl6/Spec/S03-operators.pod Log: [S03] Don't not use no double negatives Modified: docs/Perl6/Spec/S03-operators.pod === --- docs/Perl6/Spec/S03-operators.pod 2009-08-25 00:26:56 UTC (rev 28060) +++ docs/Perl6/Spec/S03-operators.pod 2009-08-25 06:48:35 UTC (rev 28061) @@ -569,7 +569,7 @@ $x ** 2 -If the right argument is not a non-negative integer, the result is likely to +Unless the right argument is a non-negative integer the result is likely to be an approximation. If the right argument is of an integer type, exponentiation is at least as accurate as repeated multiplication on the left side's type. (From which it can be deduced that CInt**UInt
Re: directories of interest, a multiplicity alternative to CWD
I think this is a much more flexible system than those suggested so far.
It seems to me that this approach
- lets the OS and the implementation deal with pathways that are valid
(taking into account locale and OS constraints).
- defines only that part of the location/directory tree/file system on
which perl6 programs operate, rather than having to understand the whole
environment in which software could run
- delegates to a module if perl6 is to be used to manage a specific
environment/OS
- offers more future proofing and portability than constraining what can
or cannot be in a pathname.
- allows users to configure via Policy.pm standard pathnames to
something non-standard for development and testing, leaving the software
itself unchanged.
Darren Duncan wrote:
snip
When you write a path, then rather than rooting it with /, you
instead root it with doi/.
Examples of doi can be:
fsroot - the root of the real file system, analogous to /
fscwd - the dir that was the fs CWD when Perl started up
docs - the dir that contains the usual files we want to work with
temp - the dir where we can put temporary files
home - the current user's home dir
mycwd - some other cwd-dir, which is virtual-changeable in Perl
To define a new doi at runtime, something like:
%DOI{'mycwd'} = %DOI{'fscwd'};
%DOI{'mycwd'} ~= 'subdir';
# later
my $fh = IO.open( 'mycwd/myfile.txt' );
For ease of use, we can still have vars like $*CWD, which might be an
alias for a doi with a specific name.
Note, please ignore my specific syntax for denoting Path objects. I
defer to other discussions and synopsis for those details, and mainly
what I'm trying to put across here is concepts.
My main point here is that we effectively can have multiple CWD in the
same Perl thread, and it shouldn't be too much trouble to make this
work well.
-- Darren Duncan
Re: Filename literals
I like this way.
Would it be possible to remove the special purpose of \ from strings
within IO constructs?
This would mean '\' could be used in naming paths as an alternative to
'/', thus allowing windows and unix strings to be equivalent, eg.
IO(:path{$root-path}/data/new) would be equivalent to
IO(:path{$root-path}\data\new)
The usefulness would be most evident for sub-directories as windows and
unix have different ways of describing root, viz. 'C:\' versus '/'
David Green wrote:
We should start thinking about the fundamental objects for doing IO as
IO-objects. They *have* names, but they aren't names, or strings, or
even filehandles (although they might *have* filehandles encapsulated
inside to do the actual work). A filename is merely a way to get at
the actual object, just as the string 2009/1/1 can be used to get a
Date object. A string, or a handle, or an inode, or some unique
filesystem spec number, or anything else you can get your hands on
should be fed to a constructor:
Of course, this being P6, we can have some kind of io macro that
parses the single item after it:
my $file1 = io file://some/dir/some%20file; #
the quick way
my $file2 = IO.new(:protocolfile :urifoo/bar/a file.html); #
the verbose way
Rukudo-Star = Rakudo-lite?
Referring to Patrick's blog about an official 'useable' version of Rakudo, a suggestion: Since Rakudo* (not sure how it is to be written) is intended to be a cut-down version of perl6.0.0 that is useable, how about Rakudo-lite? Its just that */star/whatever doesnt convey [to me] the fact that its a sub-set of of Perl6. -lite seems [to me] to be used to define a functional, but stripped down version of a larger spec. Richard (finanalyst)
indentation with multiple languages
One of Masak's irritations with perl6
(http://use.perl.org/~masak/journal/39334) concerns interspacing POD and
code.
I ran into an analogous problem with a project I am trying to do with
perl6. Since perl6 doesnt yet link to the gd library, and I need
graphical output, I use perl6 to compile a script for another utility
(in my case ploticus). The result is that I have code which looks a bit like
perl6 code;
perl6 code;
$script.say(
output code
output code
);
perl6 code {
perl6 code
perl6 code
$script.say(
output code
indented output code
indented output code
);
}
perl6 code
In other words, I have two languages intermixed, each with its own
indentation.
I would like to have the indentation of the output (or secondary
language) to be dependent on the primary languages indentation. As in
the comments to masak's blog, I use indentation to help me with
understanding the structure of my program (in perl6). When the output
language over-rides the indentation hierarchy in the primary language, I
loose the usefulness of indentation.
Thus I would like to be able to see:
perl6 code;
perl6 code;
$script.say('
output code
output code
');
perl6 code {
perl6 code
perl6 code
$script.say('
output code
indented output code
indented output code
');
}
perl6 code
For this case, a solution that occurs to me is to add an optional
parameter to 'say', eg., unspace=' ' which would remove that
amount of white space to the start of the output line.
The difference between this form of unspace and the one already in the
spec is that there is an end to the unspace string, which can then be
followed by white space.
It seems to me that some sort of approach like this could be very
useful, for example, when using perl6 to generate html pages.
Richard (finanalyst)
Re: say followed by lines - inconsistencies
Larry Wall wrote: snip Well, regardless of whether there are extra spaces, please note that the default stringifications are not intended as a serialization format. They are intended only to provide a bit of human readability for the common case of small, spaceless items such as numbers and words; they make no guarantee about the sanity of the delimiters. Fair enough. But then ... see below So now I want to read in the data again. (The problem arises because perl6 has a memory leak and my program segfaults after five loops, so I need to store the intermediate data; this is a serialisation problem, but I dont need to go to the extreme of yaml for it). Hmm, if you think yaml is extreme, yowie, the world is a harsh place... If all I want is a tab delimited list, any serialisation standard is overkill I guess I can only suggest that you use .perl instead, for a minimal serialization format. Or write your own explicit formatting and serialization using .fmt calls. Larry That I had not considered. Using perl5, I am used to outputing simple data with print, and reading in with Extra spaces dont get inserted at random. I got to thinking that .say is .print with \n. It seems to be slightly more. But having stringification that aims for legibility is extremely useful. What it comes down to is education of users. Am I right in saying: .say is for outputing legibly .fmt.say is for when you want precise control over the output Maybe there should be a health warning on documentation about .say, or at least a reference to .fmt whenever .say is mentioned.
say followed by lines - inconsistencies
I came upon the following, which seems to be in line with spec, but I
think is inconsistent.
I write a hash to a file delimited by tabs, eg
my $fn=open('data.csv',:w);
my %x=one two three four Z 1,2,2.1,3;
$fn.say('record-name'~map(\t$^a\t$^b),%x);
$fn.close;
The output sometimes contains either the keys or the values padded with
single spaces on either side (I cannot find a pattern for the spaces). I
am not sure whether this a bug of say (or $fn.say() ).
So now I want to read in the data again. (The problem arises because
perl6 has a memory leak and my program segfaults after five loops, so I
need to store the intermediate data; this is a serialisation problem,
but I dont need to go to the extreme of yaml for it).
my $fn=open('data.csv',:r);
my $record-name;
my @fields;
($record-name,@fields)=$fn.lines(1).split(/\t/);
my %x = %(map{$^a = $^b}, @fields);
Except that the spaces added by .say are included in the key/value
parts. This screws up the program as spaces are not expected.
The spec specifically says that split will not trim the results. Hence,
the solution is
($record-name,@fields)=map {.trim}, $fn.lines(1).split(/\t/);
This does seem to be a bit inconsistent in that I am outputting and
inputting with essentially the same sort of scripting, but I am not
getting a predictable end result.
The spec also seems to recommend .comb
I have a problem with this because some of the data I want to read in
has empty cells, eg.
datum1\tdatum2\t\tend-datum
I want this to end up in an array
['datum1','datum2',*,'end-datum']
Yet I cant see how .comb will accomplish this. Could someone enlighten me?
But even if it was not a problem with .say, I could see that white space
trimming would be useful with split.
So, is there some good reason why .split does not automatically trim?
Richard
slowness in grammar
Is this a good place to come with code that runs into speed problems? I am writing a program in perl6 to read the xml file from a Sony book reader, list the books, and move books into collections (the Sony software to do this will only work on windoz and not on wine). I have a grammar that works with abbreviated test versions of the xml file, but it just hangs with the full version. Since I have a line my $parsed= sony_grammar(slurp media.xml); and the problem is in the parsing, I dont know how to insert trace statements to determine at what stage the problem is being generated. In addition, there is a great deal in the Synopses about code points and backtracking and the like, which I dont quite understand. However, it seems to me that an intelligent use of these possibilities could increase the efficiency of the parsing, if only I knew how. For example, only three of the tags in the file are of interest, and within them three of the attributes. So how do I tell the regex engine to skip processing if the tag is not of interest? Richard
Re: Module naming conventions
Daniel Carrera wrote: Mark Overmeer wrote: Currently in CPAN you have modules like: Digest::MD5 Digest::SHA Digest::MD5::Perl Digest::SHA::PurePerl The difference is that the first two are implemented in C and the later two in Perl. This is comparible to adding a target to each of the modules, a suggestion when you started this long thread. I'm thinking of a different problem. Regardless of how CPAN works, once stuff is installed in my system, I need a way to tell Perl which of the three different (installed) SHA modules I want to use. If there is no good solution, people will just use the module names in ad-hoc ways as exemplified above. Do we really want each person adding their own thing to the module name (::Perl vs ::PurePerl)? I figure that the ways to avoid that is to change the language semantics or add a naming convention. I assumed that changing the language semantics was a non-starter. We have here an implied relationship between what is in a program (which the perl6 specifications handle) and what is outside the program - the implementation of functionality (eg., in C, parrot, Python, tcl-tk). Lets call this 'external functionality'. My view is that the program should be provided with a link to the external functionality by the implementation. We have a normal set of rules, viz., the name used by the program has a simple relationship to the files containing the software implementing the functionality. BUT we also should have the ability to change via a configuration process the external name. Hence, 'use MyModule::submodule;' by default would be located in lib path/MyModule/submodule.pm' but if we set the perl6 program manager's configuration file appropriately, it could be located in /home/test/submodule.test Without touching the program, different modules with the same functionality and interfaces could be tested. For me the crucial thing is not the design of a CPAN replacement, but the design of the perl6 module manager. I would like something that functions in a similar way to the alternatives system that Ubuntu (all linux?) uses. Such a system (a simple reference inside a program aliasing to a more complex path by the perl6 manager) would make it much easier to enhance the portability of perl6 programs both cross platform and cross language. Suppose inside a perl6 program there is a unicode named module and it needs to be run on a platform that does not fully support unicode. The perl6 management system would provide a means for the unicode name to be 'mangled' into a platform-dependent physical path. The system would also provide a means for specifying more complex locations, such as in a database or somewhere else on the internet. Finally, we would be able to implement layering without touching the perl6 software. Thus the perl6 program would be in one layer, the perl6 module manager in another layer. It would then be possible to have different implementations of the module manager, such that some provide only minimal aliasing, whilst others offer database or zip file sources.
Module Library - aka CPAN
Before joining in the previous CPAN threads, here are some personal wish lists regarding what the perl6 version of CPAN should do. But in order to get some distance from CPAN, I want to call it the Module Library system. Some of the debate threads impact on the internal software environment, and here I think the internal and external environments must be designed in harmony. A library paradigm is different from an archive paradigm, although a library is a form of archive. However, a library is a single place to go to obtain information. It is set up to enhance searching and finding. An archive is a place where things are stored; the users of an archive know what and where they are storing. Hence the difference between an archive and a library is a set of assumptions about what a user knows. Archives are essential for large libraries (often called stacks), but there must be standardised metadata about what is in each archive for it to be useful for a library. So my wish list. I would like: 1) a single place to go for modules that will help me solve programming problems; 2) a variety of ways to look through modules and the information on them - reviews, documentation, dependencies - so that I can choose between them and know what a choice entails; 3) a variety of classifications of modules and module contents that can lead me to modules which may achieve what I want but are named in a manner I did not expect, or contain functionality I could use in another context; 4) a means to extract from the library the module(s) I want, (better still only the parts of the module) and all their dependencies; 5) the ability to access existing CPAN perl software. Extending the library paradigm, there are generalist libraries, which only contain commonly requested books, and specialist libraries and also libraries in other languages. However, good libraries share systems for requesting books from other libraries, even if they are not stored locally. The difference between libraries then boils down to the metadata available to the user, eg., more accessible user catalogs, librarians who know about subjects and can point to related books, etc. The library paradigm breaks down somewhat for software because there is an intimate link between my environment and the software I choose. Hence, it is important to consider the internal environment (my computer) as well as the external environment (the module libraries). Not only is there the problem of different operating systems (*ix, windows*, mac, etc), there is also the possibility of outdated software installed, eg., different versions of languages, such as perl 5.8, perl 5.10. Within my environment, there are multiple possible locations for different aspects of software, eg. binaries, configuration data (which can be global to all users and local for a single user), documentation, data, results. In a corporate environment, these locations may exist across a network. For example, documentation may be on a server, binaries and local configuration data on the local computer, results posted to a web site, input data taken from a database. My wish list for the internal environment; I would like: 1) a single system to manage all my software modules; 2) a method to see where different aspects of software are located, and to change them; 3) an ability to manage in parallel different dependency hierarchies (such as might result from a need to use modules from different generations (eg. perl 5.8 and 5.10). 4) a comprehensive method to determine what my local environment is, so that I can see whether it matches the environment required by software that I want to download, and if not, what I need in addition to be able to run the software. Some commentary on the above: I use the CPAN archive, CPANPLUS, and synaptic (a GUI frontend to the apt tools) for perl since I use Ubuntu/Gnome. In some cases I have to load binaries using synaptic because I cant get the sources to compile properly from CPAN. I do not have the time or inclination to discover why. The result is a mishmash of dependencies. Moreover, I cannot get updated software without breaking something. This occurred when the one Ubuntu generation was distributed with perl5.8 even though perl5.10 was out, and I really wanted to use some of the new software. The result was that I had both 5.8 and 5.10 modules. Although most things worked, perldoc wasnt recognised by some Configure scripts. I am not interested now in discovering the reason. I use this simply as an example about how multiple distribution channels that make different assumptions can lead to problems. But because there is no single method for monitoring the perl environment, it is difficult to solve some of the problems. The current setup works extremely well, except when it doesnt. My difficulty is finding out how to solve the problems that occur. So I think there should be a system that
Re: Module Library - aka CPAN
Dont think this is workable. If the local environment is non-standard, requiring your own solution, then where would you store the binary? And how would you inform future users sufficiently about the local environment for them to access the binary. Besides for most binaries, it is not really a time or space issue to create the binary locally. Mind you, the mindset for a unix person is different to a Windows person. There is a form of linux - gentoo - in which everything is compiled from scratch. In windows, compilation of modules is extremely rare. Richard John M. Dlugosz wrote: Richard Hainsworth richard-at-rusrating.ru |Perl 6| wrote: Once a module has been decided on, you look to see if there is a binary that matches your internal environment. If not, you have to roll your own from source. Why not have it generate the binary for you, and safe it for future users? It can cross-compile things if needed, or draw upon a network of different kinds of machines that are registered to allow that. Something similar is used for testing modules, right? --John
Add link to STD.pm where official documentation listed
On #perl6 Larry said that STD is a part of the specification for perl6. Would it be possible to include a link to STD.pm in the list of official documentation? There are things in STD that are not in the specifications, eg., default values for optional parameters should come after traits assigned to the parameters.
Re: simultaneous conditions in junctions
Larry Wall wrote:
On Wed, Apr 01, 2009 at 08:40:12AM -0700, Dave Whipp wrote:
That said, the semantics of a chained relop really should work correctly
for this. If you only reference a junction once in an expression, then
it should behave as such: {abc} !=== {ab bc}.
Yes, that is the intent. I consider a chained 1 $x 2 to be a
single function from the standpoint of autothreading, something like
chained(1, infix:«», $x, infix:«», 2);
and the semantics would fall out of that naturally, more or less.
Something similar could also work for the blocks of conditionals
if we were to treat the conditional as a function that autothreads
consistently over both its condition and its blocks; this implies the
junction autothreader must be given enough access to the scope of the
block in question to temporarily override the value of $x within the
block to its autothreaded value somehow. The tricky bit is that
autothreading is setting up extra scopes around variant captures
without explicit blocks. That alone is reason enough to keep
the mechanism all internal.
Do I understand correctly from this that
my $x = 1|5; say ?(2 $x $4) ; # False
my $x = 1|3|5; say ?(2 $x $4); # True
If so, then the current implementation of rakudo is generating an error,
viz.,
$ perl6
my $x=1|5; say ?( 2 $x 4)
1
May be something extra needs to be added to the specs?
If we do give access to universe of values the junction is interested
in, it should probably just be via a coercion to Set.
This would give the necessary extra syntax to ensure that the programmer
knows what s/he is doing. It means that junctions could be threshed and
sieved when desired.
There would have
to be some caveats about using that as the universe of values, however,
since none() junctions define a set outside of the eigenstates.
Interesting. Do I understand this correctly: If the junction is finite,
then none() defines an infinite set, and vice versa.
But then if perl6 is lazy, an infinite set would also be possible
With access being lazily evaluated. Just as 0 .. inf is lazily evaluated?
For that reason I'd still prefer people to track their universe of
values outside the junctions rather than rely on junctions for that.
And of course, a Set in list context is its members, so any(%set) isn't
a problem going the other direction.
Larry
simultaneous conditions in junctions
Thinking about Jon Lang's -1|+1 example in another way, I wondered about simultaneous conditions. Consider $x = any (1,2,5,6) How do we compose a conditional that asks if any of this set of eigenstates are simultaneously both 2 and 5? Clearly the desired answer for $x is False, but my $x = any(1,2,5,6); say ?( 2 $x 5); # true Is there some combination of any/all that will achieve this? Here it would seem that we would want to have some sieving, so that eigenstates that are true for one test can be given to another test.
[Fwd: Re: junctions and conditionals]
This email was mistakenly not sent to the p6l list. Jon writes: On Wed, Apr 1, 2009 at 12:54 AM, Richard Hainsworth rich...@rusrating.ru wrote: Jon Lang wrote: In Junction Algebra, Martin Kealey wrote: On Mon, 30 Mar 2009, Mark J. Reed wrote: ( $a = any(-1,+1) = $b ) == ( $a = any(-1,+1) any(-1,+1) = $b )(*A) Clearly, the RHS is true for $a == $b == 0, but I'm not sure the LHS shouldn't also be. Isn't it just syntactic sugar for the RHS? I suspect not. Rather I think that $a = any(-1,+1) = $b corresponds to $tmp = any(-1,+1); $a = $tmp = $b and thence to $tmp = any(-1,+1); $a = $tmp $tmp = $b (*B*) Quite how the lines I have labelled (A) and (*B*) are different, I do not understand. Unless wrapping a junction in a variable produces a different result. That was my initial reaction as well. A closer examination of Martin's message indicates that he tends to think that hitting a junction ought to thread the entire program throughout the rest of the lifespan of said junction, so that (e.g.) the thread that runs the comparison $a = -1 in (*B*) is the same thread that runs the comparison -1 = $b. OTOH, since (*A*) spells out two separate junctions, it would thread each one separately; resulting in four threads being used to resolve the expression. In theory, at least; in practice, he's looking for ways to simulate such threading without actually having to mess with all of the overhead that a literal implementation thereof would entail. In both cases, the problem arises when you apply a predicate to a junction, and then use the junction within code that only gets executed according to the truth of the predicate. Using a junction implies the extraction of the eigenstates. That is being frowned upon - I understand I've been doing my utmost to avoid making said implication. The possible solution to both of these: junctions collapse when they hit conditional statements - but only within the conditioned scope. So: within the code block for the if $x 0 statement above, $x only equals +1, since -1 didn't pass the test. This is the sieving functionality. Since perl6 is being written explicitly to avoid sieving out eigenstates, this will not happen. What I'm hearing is that a decision has already been made on this matter, so we're stuck with it no matter how counterintuitive the results of that decision are. Thus, say $x is the same as say 1. In the case of the range test, the code on the RHS of the only executes if the code on the LHS evaluated to true; therefore, when evaluating the RHS, $tmp doesn't include any of the possibilities that would have failed on the LHS. That means that: 0 = -1 | +1 = 0 which is true, because using standard chaining semantics we have 0 = -1|1 and -1|1 = 0 Since the first condition is true (+1 = 0) and the second condition is true (-1 =0), the compound is true. Why you might want such a condition, I dont know. But that is the way junctions are designed to work. Right now, yes. I'm arguing that the way that they're designed to work doesn't DWIM. Try a slightly different example: 0 = $x = 1 # 0 is less than $x is less than 1. $x ~~ 0..1 # $x is in the range of 0 to 1. I submit that most people would expect these two statements to be conceptually equivalent to each other: they may go about tackling the issue from different angles, but they should always end up reaching the same conclusion. But as things stand now, if $x = -2 | 2, these result in two very different conclusions: the first evaluates as true, the second as false. This most certainly doesn't do what I mean until I have been indoctrinated into the intricacies of Perl and learned to think like it does - which runs directly counter to the principle of DWIM. Perhaps instead of 0 = any(-1,1) = 0, the programmer might want 0 = all(-1,1) = 0, which is false. You're assuming that the programmer gets to choose which junction he's sticking in the middle of the comparison chain. ...becomes: 0 = -1 | +1 +1 = 0 ...which, obviously, is false. The question really is what is the desired meaning of this conditional. Yes. And my answer is that the desired meaning of 0 = -1 | +1 = 0 is closer to (0 = -1 = 0) or (0 = +1 = 0) than it is to (0 = -1 or 0 = +1) and (-1 = 0 or +1 = 0). The trick is to figure out how to get this result without needing a nightmarish amount of overhead to do it. -- Jonathan Dataweaver Lang
Re: On Sets (Was: Re: On Junctions)
Daniel Ruoso wrote: The thing is that junctions are so cool that people like to use it for more things than it's really usefull (overseeing that junctions are too much powerfull for that uses, meaning it will lead to unexpected behaviors at some point). What are the general boundaries for junctions? We know that engineering type problems should be solved using floating point variables rather than integers (although it is probable that an integer solution probably would be possible - it would be excessively complicated). Perhaps, it might help to see some more examples of how junctions should be used? Regards, Richard
Junction Algebra
Included in my 'On junctions' message were some questions that have not
been directly answered. I simplify and expand them here.
Here I use === to mean 'is the same as'.
(I am not sure which of == or === should be used.)
1) Is the following true for an any junction?
any( ... , any('foo','bar')) === any(...,'foo','bar')
If yes, then
if an 'any' junction is contained in an outer 'any', the inner 'any' can
be factored out?
2) Also, is the following true for nested 'all' junctions? viz.
all(... , all('foo', 'bar')) === all(...,'foo','bar')
3) Conjecture: The following is true of all junction types, eg.,
junc(..., junc(...)) === junc(..., ...)
4) Are there any transformations of other nested junctions?
Richard
On Junctions
The following arose out of a discussion on #perl6. Junctions are new and
different from anything I have encountered, but I cant get rid of the
feeling that there needs to be some more flexibility in their use to
make them a common programming tool.
Background: Imagine a hand of cards. Cards may be Ace, Two, Three. Ace
having either the values 1 or 11, depending on context, the other cards
their face value. Sums of a hand over 21 are invalid.
Hands with multiple junctions become interesting, eg.,
p: Ace, Two, Ace
d: Ace, Three, Ace
Given that Ace has a value of 1 or 11 depending on context, it would
seem natural to use a junction. Hence the two hands can be expressed as:
@p = 1|11, 2, 1|11;
@d = 1|11, 3, 1|11;
If we use [+] to add these, we get
$p = [+] @p; say $p.perl; # any(any(4,14),any(14,24))
$d = [+] @d; say $d.perl; #any(any(5,15),any(15,25))
Since the values of 24 25 are greater than 21, they must be eliminated
from consideration.
What we want is for hand @d to beat hand @p because 15 14
On #perl6, rouso, masak and moritz_ explained that I am incorrectly
thinking about junctions as sets and that for this task I should be
using another perl idiom, namely lists. Something like:
moritz_ rakudo: ([1,11], 3, [1,11]).reduce({@($^a) X+ @($^b)})
p6eval rakudo bb22e0: RESULT«[5, 15, 15, 25]»
Then the out-of-limit values (in the above case 25) can be stripped off
using grep, viz.,
# here we have ([1,11],3,[1,11]) instead of (1|11, 3, 1|11)
my @dlist = grep { $_ 21 } ([1,11], 3, [1,11]).reduce({@($^a) X+ @($^b)});
Then the two lists (do the same for @p) can be compared by a junction
comparison of the form
if any(@plist) all(@dlist) { say 'p wins' };
The problem is not just that [+] @p produces a junction with undesired
(21) eigenstates, but that the [+] @d produces a junction of the form
any(any(5,15),any(15,25)) which should collapse to any(5,15,25)
whereas we want a junction of the form
all(5,15,25)
After the #perl6 conversation, I thought some more. A junction is a neat
way of expressing the hand, but the junction needs to be converted to a
list to do some processing, and then the lists are compared using junctions.
I think (I might be wrong) that the conversion from a junction to a list
is specified by the .eigenstates method, but it doesn't seem to
completely flatten a junction yet - it produces the
any(any(4,14),any(14,24)) output shown above.
So my questions to the language list are:
a) Am I trying to fit a square peg in a round hole by applying junctions
to this sort of problem? If so, would it be possible to explain what the
limits are to the junction approach, or another way of expressing this
question: what sort of problems should junctions be applied to?
b) Why would it be wrong to have a method for eliminating eigenstates
from a junction? (The answer to this might naturally arise out of the
answer to a). However, ...
In a wider context, I would conjecture that some algorithms to which
junctions could be applied would be optimised if some states could be
eliminated, a bit like tree-pruning optimisations that eliminate paths
which can never produce a correct answer. Consequently, providing a
filtering method would increase the usefulness of the junction as a
programming tool. Perhaps
$new-junction = $old-junction.grep({ $_ = 21 }); # not sure if the
parens are needed here
c) On junction algebra, am I wrong or is always true that a junction of
the form
any('x','y','z', any('foo','bar'), 1, 2, 3) should collapse to
any('x','y','z','foo','bar',1,2,3)
In other words, if an 'any' junction is contained in an outer 'any', the
inner 'any' can be factored out?
This would eliminate the nested junctions produced by .eigenstates
d) Am I right in thinking this is also true for nested 'all' junctions? viz.
all(1,2,3,all('foo', 'bar')) collapses to all(1,2,3,'foo','bar')
e) Conjecture: This true of all junction types, eg.,
junc(..., junc(...)) == junc(..., ...)
f) Would it be possible to have a means to coerce an 'any' junction into
an 'all' junction or vice versa? eg.
my $old-junction = 1|2|3; my $new-junction = all{$old-junction}; say
$old-junction.perl
# all(1,2,3)
Using () creates a new junction all(any(1,2,3))
{} are undefined for junctions.
If my suggestions prove acceptable, then for my problem I would have:
# @p @d get defined as arrays of junctions, eg.
my @p=1|11,2,1|11;
my @d=1|11,3,1|11;
#later
my $p = ([+] @p).grep { $_ 21 };
my $d = ([+] @d).grep { $_ 21 };
if $p all{$d} { say 'p wins' } else { say 'd wins' };
Richard (finanalyst)
Camelia - Queen of Perl
Just read nearly 100 emails on Re: Logo Considerations, a whole lot in reverse order and repeated! Is this the result of a perl6 implementation of a listserver using junctions? But I agree with Brett, Camelia is the first logo idea I really liked. I vote we tell Camelia she has the prize she so earnestly wants - being the logo of Perl6. Question to Larry: Would Camelia prefer to be considered a Queen Bee, a Butterfly, or is she a junction of both? Richard
Logo considerations
Hats off to the designer of the gimel symbol - the associations with anarchy are probably right for perl6. But to be honest, a letter didnt quite inspire me. Since, I dont want to criticize without providing other ideas, here are some thoughts. Logos can contain meaning. I am not sure whether the Camel was chosen for a meaning, or because it was something to put on a book cover. But one could say, it is an animal that goes into a desert where no others can. Sort of going where no one has gone before. There seem to be a lot of animals attached to software things, such as a camel, but also a penguin and a parrot. So how about choosing another animal for perl6? My choice would be a lion, perhaps one lazing in the sun. The meaning that it is lazy, but it has raw power when it needs, and is the king of the jungle. Alternatively, if we stay away from animals, then how about something to do with parallelism, or super-positioning, or even a strange attractor, since perl6 can be strange and yet it is attractive. Richard
Dot forms of adjectives
But I recently read this on irc:
2009-03-12
23:16pugs_svnr25809 | lwall++ | This decrease in consistency on
the syntactic level is offset by an
23:16pugs_svnr25809 | lwall++ | increase in consistency on the
semantic level, as suggested by rouso++.
23:16pugs_svnr25809 | lwall++ | (We'd already gotten rid of the
dot forms of adverbs some time ago,
23:16pugs_svnr25809 | lwall++ | for similar reasons. We just
didn't quite carry the idea through.)
and then read this:
S03 Changes to Perl5 Operators
...
if $filename ~~ :e { say exists }
is the same as
if $filename.e { say exists }
The 1st form actually translates to the latter form, so the object's
class decides how to dispatch methods.
Is there an inconsistency here?
Re: Dot forms of adjectives
Original post not very clear. So here goes again:
First statement (below) says: dot forms of adverbs eliminated.
Second appears to say: adverb form is translated to dot form.
Richard Hainsworth wrote:
But I recently read this on irc:
2009-03-12
23:16pugs_svnr25809 | lwall++ | This decrease in consistency
on the syntactic level is offset by an
23:16pugs_svnr25809 | lwall++ | increase in consistency on the
semantic level, as suggested by rouso++.
23:16pugs_svnr25809 | lwall++ | (We'd already gotten rid of
the dot forms of adverbs some time ago,
23:16pugs_svnr25809 | lwall++ | for similar reasons. We just
didn't quite carry the idea through.)
and then read this:
S03 Changes to Perl5 Operators
...
if $filename ~~ :e { say exists }
is the same as
if $filename.e { say exists }
The 1st form actually translates to the latter form, so the object's
class decides how to dispatch methods.
Is there an inconsistency here?
a junction or not
The following (the n: is to mark the lines) are legal:
1: my @x = 1,2,3,4; ([+] @x).say; # output 10
2: my @x = 1|11,2,3,4; ([+] @a).perl.say; # output any(10,20)
3: my @x = 1|11,2,3,4; ([+] @a).eigenstates.min.say; # output 10
However, the next line isnt
4: my @x = 1,2,3,4; ([+] @a).eigenstates.min.say; # Method
'eigenstates' not found for invocant of class 'Integer'
But suppose I dont know until runtime whether @x contains a junction or
not, eg.,
my @s = 1|11,2,3,4,5,6,7; # as in the value of an ace in 21
my @x;
loop {
@x = @s.pick(3);
([+] @x).eigenstates.min.say;
};
Eg.
$ perl6
my @s=1|11,2,3,4,5,6;my @x; loop {...@x=@s.pick(3);([+]
@x).eigenstates.min.say}
8
6
Method 'eigenstates' not found for invocant of class 'Integer'
I suggested to Masak on irc that an integer is a singleton, hence a
degenerate Junction. He said not.
So, how to determine whether a junction is being used or not?
Richard
Re: a junction or not
Jonathan Worthington wrote:
Richard Hainsworth wrote:
snip
Eg.
$ perl6
my @s=1|11,2,3,4,5,6;my @x; loop {...@x=@s.pick(3);([+]
@x).eigenstates.min.say}
8
6
Method 'eigenstates' not found for invocant of class 'Integer'
You can detect junctions by smart-matching against the Junction type
(e.g. $sum ~~ Junction).
my @s=1|11,2,3,4,5,6;
loop {
my $sum = [+] @s.pick(3);
say $sum ~~ Junction ?? $sum.eigenstates.min !! $sum;
}
Jonathan
Except it doesnt work :(
$ perl6
my %h=a b c Z 1|11,2,3;%h.perl.say
{a = any(1, 11), b = 2, c = 3}
my %h=a b c Z 1|11,2,3;my $s = [+] values %h;$s.perl.say
any(6, 16)
my %h=a b c Z 1|11,2,3;my $s = [+] values %h;say $s~~Junction ??
$s.eigenstates.min !! $s
Null PMC access in get_integer()
Predefined rules - clean up
Various Appocalypses, Exegeses, and Synopses use rules in example codes. These were gathered together by PM and implemented in PGE. Larry asked for them to be listed in S05 for a short description to be added. Timothy Nelson added them and I have just described them. This yielded some extra changes I am documenting here. a) Some reordering grouping similar functionality. b) Removal of deprecated items from the S05.pod (it seems odd that a language Specification should declared something to be deprecated). They are evolutionary artifacts taken from Exegeses. Specifically, the removed items lt gt dot sp are mentioned in E05. (Are simply '' '' '.' ' ', respectively) c) Addition of word as alphanumeric plus '_' - the definition from perl5. The definition for wb needed some attention. In the PGE code wb is described as having the same definition as perl5. But perl5 documentation states A word boundary is a spot between two characters that has a \w on one side of it and a \W on the other side of it (in either order), counting the imaginary characters off the beginning and end of the string as matching a \W . Perl6 does not mention the equivalent of \w, obviously word, which yields the compliment -word automatically. d) null and fail were first mentioned in the Appocalpses but changed to ? and !. Replaced null and fail
S28
The official Perl6 Documentation site http://perlcabal.org/syn/ list this document as special-names not special-variables variables is more constrictive, so suggest a change in name of pod. pugs-comm...@feather.perl6.nl wrote: Author: wayland Date: 2009-02-23 04:47:22 +0100 (Mon, 23 Feb 2009) New Revision: 25490 Added: docs/Perl6/Spec/S28-special-variables.pod Log: Created the draft spec here. It's very drafty, but no more than some.
Rules mentioned in specifications, etc
Here is a list of rules (see below) that are spread around the language design documents, but which lack a home in which they are systematically canonically defined. I suggest they be added to the new S28 (which is possible if S28 is special-names, not special-variables) Richard Where can I find a list of rules that are provided by default? I don't know that a canonical list exists. However, I can tell you what rules PGE provides by default (these came from scraping various versions of the synopses, apocalypses, and exigeses): ident null fail upper lower alpha digit xdigit space print graph blank cntrl punct alnum sp lt gt dot ws wb before after Pm
Re: Temporal revisited
Dave Rolsky wrote:
After some discussion I made a number of drastic revisions to
S32-setting-library/Temporal.pod
What I want to see in Perl 6 is a set of very minimal roles that can
be used to provide a simply object from gmtime() and localtime().
These objects should not handle locales, proper Olson timezones,
string parsing, user-defined formatting, or math.
They're basically simply little data blobs with some overloading and a
few handy methods.
I imagine that a real classes which do math, handle leap seconds,
formatting, and so on will _also_ do these roles, but this should be
done out of core.
Some comments arising from reading the ensuing threads/emails:
a) I am strongly in favour of Instant over DateTime for several
reasons, one being that it marks a new approach.
b) Although for business we use a calendar derived from the one decreed
by Julius Caesar, via Pope Gregory, additional days, and leap seconds,
there are many calendars in use, and there is no overwhelming logical
reason why a different calendar might not be used in the future. For the
interested, the Jews, Muslims, Baha'is and Chinese all use different
calendars.
c) Fixing the core6 time processing functionality to a specific calendar
is restrictive, whereas focussing on an underlying handling of time
using an accepted synchronisation standard allows for easier extensions.
d) This would mean that the functionality of dates should be handled by
modules.
Thus Temporal::Gregorian would include functionality that leads to
years from 1AD, 7 days of the week, 12 months with unequal day lengths,
days starting at midnight, and a mapping from the core perl6 values to
current calender values, eg. 20 Feb 2009.
e) Perhaps we could define the minimum time functionality in core perl6
by some set of principles:
- attributes that will allow time keeping within a program;
- attributes that provide access to a global synchronisation standard;
- attributes that make it easy to map the global synchronisation onto a
given calendar structure;
- duration measuring (basic stopwatch functionality).
f) Date arithmetic is calendar-related because
$days_2_Xmas = Date('25 Dec 2009') - today();
requires information about the structure of months dependent on the
year, but it is also related to synchronisation to provide the today() term.
g) Depending on the software needs, date arithmetic can be simple, only
dealing with the next few years. Other times, it needs to be more
complex, to handle dates across centuries. Hence, there would be
Temporal::Gregorian::1907AD, Temporal::Gregorian::1AD etc.
h) Time functionality seems to me to need both immutable parts, viz.,
links to the global synchronisation, and mutable - timezone and daylight
saving. (I would include these as part of the time-keeping part of the
system). The time of day depends on the position of the computer, but
not on the calender date. But if software is being written to be used on
a portable or travelling computer, there needs to be the means to change
these offsets, perhaps as the software is running.
i) It seems to me that the core should give access to years, days,
minutes, seconds from the standard. Then some time arithmetic will be
possible in terms of these units. Given the use of leap seconds, these
measures may not be exact multiples.
j) A question to the list: to what extent are sub-second intervals from
the start of the era needed? I can see the need for sub-second
granularity when measuring durations, eg., how long a subroutine takes
to run. But I cant see the need for sub-second granularity in knowing
the current time. It seems to me that the two are different.
k) The reason for the question above is that whereas synchronisation
units (eg., seconds since the start of era) should always be defined,
subsecond attributes need only be defined for duration measurements
(stopwatch functions).
l) The definition of the attribute that holds subsecond information
(viz., number of nanoseconds, or fraction of a second) seems to me to be
be moot. We require a specification decision, eg., perl6 allows duration
timing accurate at least to nanoseconds. Even if subseconds are
fractional at some point the decimal places, even though they can be
printed, would have no physical meaningfulness. In the problem domains
where femtoseconds can be meaningfully measured and manipulated,
specialised software will be needed in any case. If, moreover, it
becomes necessary to specify some other accuracy, then that will be a
part of perl6.2001 :)
Since the meaningful precision is defined, I think it would be easier
for there to be a stop-watch attribute that is defined to be in (eg)
nanoseconds.
Sorry for the length.
Re: IO, Trees, and Time/Date
Timothy S. Nelson wrote:
On Tue, 17 Feb 2009, Richard Hainsworth wrote:
Timothy S. Nelson wrote:
snipbe specifying our files; it's prettier than File::Spec :), and
unified.
Anyway, HTH,
I like all the default suggestions.
Not sure whether this means you completely agree with me, or
completely disagree.
Like == agree
Like !=== agree
It seems to me that a path, whether within a file system or across
the internet, leads to a location. A location is a container for
files. A file is a container for data.
Given the strong typing paradigm of Perl6, it seems to me that the
specification should distinguish between files and locations.
snip
I think you're confusing the inside and the outside of files. For
me, the inside of a file is everything you can do to it when you've
done an open (eg. read and write). The outside of a file is the other
stuff (stat, chown, etc).
Interesting. But how is inside/outside different from container/contents ?
Methods on a container are different to methods on the content.
My idea is that a location is a container, file is also a container, but
of another sort.
I was thinking that by identifying locations as specific types of
containers, it would be possible to create an abstraction for perl6
specification that is less OS sensitive.
Let me give you an example. Say I wanted to specify a path to a
particular XML element, starting from the root of a filesystem. Say
also, for argument's sake, that when the search path came to a file
ending in .xml, it would, if there were children requested, read the
file and dig through the tree. Then I could do something like this:
/home/wayland/xml/foo.xml/html/head/title/text()
Also there is the case of archived directories and files, eg.
/home/richard/archive/version2.zip/foo/text.txt
Version2.zip is considered by the OS as a file.
Note that the directory called xml doesn't contain the file
called foo.xml. Instead, it contains a filesystem entry called
foo.xml. This filesystem entry in turn points to the contents
(which I look at with an XML path).
In other words, note the distinction between the *contents* of the
file, and the entry in the file system that refers to it. Which is
the file? Colloquially, both, but I'd argue that technically, the file
is the *contents*, not the filesystem entry.
Well, even here, html head and title all define conceptual
containers within the marked up datastream. But the datastream is
defined as a string of octets, and in this example, the initial string
with something like
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.01 Transitional//EN
has been ignored in your example. So it is not the perl6 core that is
allowing path definition to an html fragment.
For example, it is sensible to have a .files() method for a
directory, but it is not sensible for such a method to exist for a
file. Meanwhile, print/say/putc are not sensible for a
directory/location.
So I was not entirely right in saying .files has no meaning for a file,
if the file is a zip archive. But both can be considered locations, even
though for unix/windows a zip file is considered a file.
But isnt that a feature of the OS?
I'd argue that we want three things here, if we go down this path:
IO::Dir.files()
IO::FileNode.lines()
IO::File.printf()
No I dont think so. There is a difference between a source of data and
data.
For example, suppose we set up a connection to a database that generates
multiple lines
and we associate (I am guessing about the syntax here) the data base
response with a filehandle
my $fh = $database.connect('select Month,Name, Capital,
Total_Assets from Banks where id month 20071201 ');
for =$fh - @record {...};
The data stream is in lines, but the source is not a file. Yet
supposing, the same data had been saved to a file and $fh had been
associated with the file as a source. As far as the code in the for loop
is concerned, it is the same data stream.
But the data stream generated from querying a location where a number of
files are located in a filestore is different from the datastream from
file.
However, it seems to me that maybe the .files() method is heading
in the direction of PHPs 1001 string functions. It might be better
like this:
$dir = new IO::Dir(/home/wayland);
@files = grep { -f } @$dir;
But this is exactly what I think should be avoided. -f implies that the
location $dir contains things other than files. But that is an artifact
of the OS and should be hidden within the implementation of perl, or
made available by a OS-specific package.
When I started learning perl (I used Windows platform at that time) I
was confronted with a bewildering array of functionality. Some was part
of perl and I could use, nearly all the IO functions were specific to
Unix, and I never ever used. But I spent a considerable amount of time
working out what was and wasnt useful to me at the time.
I know @$dir is bad
Re: IO, Trees, and Time/Date
Actually, it seems to me that we do agree fundamentally, although using
different terminology.
And like I said in an earlier email, I do like/agree with the way you
are taking the Spec.
Also, it seems to me a re-ordering of the material in the Specs would
make more sense.
On our disagreement:
Timothy S. Nelson wrote:
On Wed, 18 Feb 2009, Richard Hainsworth wrote:
snip
$dir = new IO::Dir(/home/wayland);
@files = grep { -f } @$dir;
But this is exactly what I think should be avoided. -f implies that
the location $dir contains things other than files. But that is an
artifact of the OS and should be hidden within the implementation of
perl, or made available by a OS-specific package.
I suspect this is where our disagreement comes in. I don't agree
that it's an artifact of the OS. Can you give me an example of an OS
that doesn't work that way?
OK and when I wrote this I knew I was half-wrong.
Its just that in my view of a directory as a location container, my idea
was that the methods available on the container would yield different
sorts of contents. Hence,
my $dir .= new IO::Dir($path); # Note the .= is perl6 for the mutating
method new, not a = as in perl5
my @files = $dir.files; # I think this is correct in that here the array
is not typed.
my @subdirectories = $dir.children;
#But if File is a type, then I am not sure what the correct syntax would
be. Perhaps
my @files of IO::File == $dir.files; # lazily evaluated
my @subdirectories of IO::Dir == $dir.children;
I dont think your @$dir is correct because you have an object $dir, not
a pointer to an array, which is implied in perl5 by the '@$' syntax.
For what you want, I would think, you need
@files = grep { :f } $dir.contents; # note the adverbial form, which is
mentioned in one of the other specs.
By analogy there would be
@subdirectories = grep { :d } $dir.contents;
And here, as above in my example, although we have explicitly declare
dir as a IO::Dir object, we have not declared the directories in
@subdirectories as IO::Dir, which they are too.
However, in so far as our disagreement is concerned, it seems to be one
of style rather than substance.
I would prefer methods on objects that yield the various types of
content, you would prefer adverbial tests to be used on all contents.
Mind you, I think in one of the other Synopses, I read that the
adverbial form actually translates into a method, so both are equivalent.
snip
None, I agree. But even things on the Internet can have container
attributes. That would be eg. HTTP headers. Maybe not *everything*
has attributes on the container, but it seems to me that almost
anything I can think of does.
I'll be interested to see where this heads next :).
Me too :)
So, for starters:
Can we abstract enough so that there is no difference between a database
producing data and a file producing data?
Given that a file containing archive data or xml/html data is both a
source of data, but also a container / location. Consequently, if File
and Directory are types, then if a file does contain data then the
filehandle associated with it can be coerced into the Directory type?
Just as Int can be coerced into Num.
What needs to be abstracted so that a perl6 program can know that a
Writeable may not be able to accept data (eg., because the file system
is full)?
How about connections eg., to internet sites, that were working, but
have broken during software operation.
Re: IO, Trees, and Time/Date
Timothy S. Nelson wrote: Hi all. I know we usually run on forgiveness instead of permission, but I'm suggesting a big change (or extension, anyway), so I wanted to run the ideas by you all before I put the effort in. If I don't get feedback, I'll just make the changes. The first thing I wanted to suggest was that in S16, the OS-specific stuff be split out into separate roles. I suspect this is mostly non-controversial, so I'll do that unless someone complains. My second thought is that we need to specify tree objects (see http://www.mail-archive.com/perl6-language@perl.org/msg28579.html ). I'll put them in S16 unless someone complains. My third thought is that it would be very useful also to have date/time objects that integrate well with eg. ctime, mtime, and the like; I'd start with Time::Piece as a model. http://search.cpan.org/dist/Time-Piece/Piece.pm My final question is, since people are now getting somewhat familiar with the file: URI scheme (ie. file:/home/wayland/Notes.txt or file:/C/Documents and Settings/wayland/Notes.txt or whatever), I'm wondering if this isn't how we should be specifying our files; it's prettier than File::Spec :), and unified. Anyway, HTH, I like all the default suggestions. It seems to me that a path, whether within a file system or across the internet, leads to a location. A location is a container for files. A file is a container for data. Given the strong typing paradigm of Perl6, it seems to me that the specification should distinguish between files and locations. It seems to me that unix blurs the difference between a file and a directory (at least readdir returns both file and directory names and the programer then needs a test to distinguish them), but that does not mean they are not conceptually different. For example, it is sensible to have a .files() method for a directory, but it is not sensible for such a method to exist for a file. Meanwhile, print/say/putc are not sensible for a directory/location. Moreover, if perl6 distinguishes between a location and a file, then the spec can distinguish between a .children() method that provides a list of child locations (viz., sub-directories) and .files(), which provides a list of the contents of the location. Regards, Richard
Re: Periodic Table of the Operators, version 3
VERY stylish! For example, some questions: To what extent is the vertical alignment important? Does it indicate some form of seniority within a category? Where do the terms iffy dotty fiddly, etc come from? STD.pm? Where do the categories Jungian, Jungior etc come from? Just an excellent piece of work, really excellent! Richard Mark Lentczner wrote: Friends - Just a note to let you know that the third version of the Periodic Table of the Operators is complete: http://www.ozonehouse.com/mark/periodic/ Thanks again to all those who helped me dive deep into perl6. - MtnViewMark Mark Lentczner http://www.ozonehouse.com/mark/ m...@glyphic.com
Re: r25172 - docs/Perl6/Spec
Daniel Ruoso wrote:
Em Seg, 2009-02-02 às 09:37 -0800, Larry Wall escreveu:
It's also not clear how this should interact with buffering systems
like stdio. But in any case, speaking directly to the IO stack is
likelier to give consistent results than playing mix-n-match with
various calls on the IO stack that make various assumptions.
The question here is, will Perl 6 IO use stdio.h or re-implement its
features?
My first shot at it would be...
role IO {
has $.fd;
}
I strongly believe the current S16 needs rewriting from scratch. This
approach seems far more more perl6-ish. I tried to draft a new S16, but
realised I simply dont have the knowledge (or the time to acquire the
knowledge) necessary for even an initial draft. But in trying, these are
some of the ideas I had.
a) 'open()' seems to me to be syntatic sugar for something else, such as
the creation of a File object. Perhaps in the Setting, 'open()' would be
defined to include any necessary OS specific roles (eg, chown, chmod).
b) the :r and :w adverbs on 'open()' are adverbs because they modify the
way 'open' as a verb operates.
c) the file tests :r and :w are not adverbs. They are methods on File
objects to determine the properties readability and writeability and
return Booleans. Things which are different should be named differently.
Also, in my (very limited) experience, testing readability and
writeability are less frequent in use than opening for read and write,
thus for Huffman reasons, they should be longer. May be .readable
.writeable?
d) The vast majority of S16 seems to be about functions that are
essentially wrappers around unix calls. To be honest, I have never used
most of them within a perl program.
( As an aside, may I suggest that this is because the nature of the perl
language has changed. When originally developed, it was to fill a need
directly related to managing unix systems. There are now better tools
for these tasks, so perl6 does not need to address them in the core. The
success of perl on the internet was due to the much deeper design values
incorporated in perl and that these deeper insights were more adaptable
to a different environment. There are now a variety of tools for
handling the internet environment. Perl6 - I believe - is now addressing
an even wider set of issues - a larger problem space. Leaving unix
wrappers in the core specifications will tie it down and perhaps hinder
its development. Suppose perl6 becomes the defacto language for an
internet browser, IO would not even be related to files or an operating
system.)
e) Only the minimum tests (readability and writeability and
executability) and minimum adverbs (:w and :r) are mentioned in the
other specifications, together with =$filehandle, open, print, and say.
f) radical suggestion:
if the syntax '=$filehandle' lazily takes something from the file
handle, then
$filehandle = output;
should send something to it.
This means that the syntax
my $filehandle = open(name, :r);
needs to become
my $filehandle .= open(name, :r);
which, I would suggest, is more in line with calling a .=new() method on
an object.
In this way '=' replaces 'say' (or 'print') on a filehandle. Bare 'say'
(or 'print') could be retained as syntactic sugar for
$*STDOUT=
We would also have
$filehandle = map { s/ html_entities / %html_entities/ } @lines;
as a filtering idiom.
Given the frequent use of 'say' in any program, this is more Huffman
efficient for a filehandle.
g) Statbuf is mentioned in S03. It is not really dealt with in S16. It
seems to me from the context in S03 that Stafbuf is a sort of 'eager'
filehandle, in that the whole file is pulled into memory and then can be
operated on. If this is the case, would it not be more appropriate for
the eagerness to be defined as an adverb for 'open()' ? eg.
my $filehandle .= open(name, :r, :e);
Wouldn't this eliminate the need for Statbuf as a defined object type?
h) Would it not be possible to write the IO specification in such a way
as to make everything 'outside' the program a single category of IO?
Thus files, http and ftp connections are all streams into containers and
the same verb ( 'open()' ) with attendant adverbs (:w, :r) are used to
establish them and the same set of tests (.readable, .writeable) used to
verify the steams have the required properties at some point in the
programe. All directories and urls would all be locations with the same
methods to discover container objects (files, archives, databases) in them.
Richard Hainsworth
Re: RFD: Built-in testing
(Daniel Ruoso also proposed to call the adverb :test
instead of :ok, making it easier to read but a bit
longer; my happiness doesn't depend on the exact name,
but of course we can discuss it once we have settled
on this scheme, if we do so).
My two-cents worth:
The adverb on a boolean changes the nature of the statement, so that if
the statement is true we get the diagnostic message in :OKdiagnostic
message but if the statement is false we get a failure message from the
compiler / software
Given that the diagnostic appears when the test succeeds, I - like
Fagyal - would prefer :OK to :TEST because this is the way I use OK,
that is I expect a positive answer.
However, the nature of a test is that a program consisting of test
commands continues to run even if there is a failure. This is not a
problem if the boolean statements are 'standalones' meaning that the
consequent flow of the program is not dependent on the test, eg.,
$x.value == 2 :OKValue correctly assigned;
$x.color eq 'red' :OKColor assigned;
...
But if this is part of perl6, then it will be possible (I think) to write
if $x.value == 2 :OKvalue was 2 {dosomething()} else {dosomeotherthing()};
What sort of behaviour would be expected? I see several alternatives:
a) Suppose it is decided that :OK could be a part of ordinary software,
then a fork in the program would occur depending on the boolean value.
Hence :OK in general generates a trace commentary that is explicitly
defined for the TRUE case, but is implicitly defined by the compiler for
the FALSE case.
b) However, if it is considered best for :OK only to operate in Test
contexts. That would mean a boolean test with :OK should be illegal
unless it is a standalone statement, eg., the test should not be in a
control construct.
In this case, I would think :TEST should be the variant chosen. The
reason being that it focusses attention on the test behaviour.
c) Suppose, as Damian suggested (I think), that tests should be included
in normal software, but that they are ring-fenced into a separate block
with a TEST {}. That way, TEST blocks would not normally run in
production software.
In this case, the extra semantic hint of ok expecting a positive
response would be useful. Hence :OK would be the preferable variation.
Richard
Re: getting the face value of an enum
Can I suggest a new method to be declared with enums, viz. .face enum day Sun Mon Tue Wed Thur Fri Sat; my $today does day; $today = prompt Type in a day of the week ; #later say $today ; # prints 3 say $today.face; #prints Wed Whilst having an enum being a list of values is useful, not being able to restore the name can be frustrating. Carl Mäsak wrote: Richard (): S12 defines enums and rakudo impliments them, so perl6 enum wkend Sat Sun; my $x = Sun; say $x 1 But suppose I want to get the face value of $x, viz., 'Sun'? How do I get it? say $x.key doesnt work. Far as I know, the answer to your question is unspecced. (Yes, that sucks. I've also wanted the name of an enum value sometimes, but so far I've had to work around it in various ways.) // Carl
Working with files wish list
Following the request for ideas on IO, this is my wish list for working
with files. I am not a perl guru and so I do not claim to be able to
write specifications. But I do know what I would like.
The organisation of the IO as roles seems to be a great idea. I think
that what is suggested here would fall in naturally with that idea.
Suggestions:
a) I am fed up with writing something like
open(FP, “${fname}_out.txt”) or die “Cant open ${fname}_out.txt for
writing\n”;
The complex definition of the filename is only to show that it has to be
restated identically twice.
Since the error code I write (die blaa) is always the same, surely it
can be made into a default that reports on what caused the die and
hidden away as a default pointer to code that can be overridden if the
programmer wants to.
b) Why do I have to 'open' anything? Surely when software first
identifies a File object (eg., names it) that should be sufficient
signal to do all the IO things. So, I would love to write
my File $file .= new(:namemydatafile.txt);
my File $output .=new(:namemyresults.txt, :modewrite);
and then:
while $file.read {…};
or:
say “Hello world” :to$output;
The defaults would include error routines that die if errors are
encountered, read as the default mode, and a text file with EndOfLine
markers as the file type. Obviously, other behaviours, such as not
dying, but handling the lack of a file with a request to choose another
file, could be accommodated by overridding the appropriate role attribute.
The suggestion here is that the method say on a File object is
provided in a role and has some attributes, eg., $.error_code, that can
be assigned to provide a different behaviour.
c) I want the simplest file names for simple scripts. As Damian Conway
has pointed out, naming a resource is a can of worms. I work with
Cyrillic texts and filenames and still have problems with the varieties
of char sets. Unicode has done a lot, but humans just keep pushing the
envelop of what is possible. I don't think there will ever be a
resolution until humanity has a single language and single script.
It seems far better to me for standard resource names to be constrained
to the simplest possible for 'vanilla' perl scripts, but also to let the
programmer access the underlying bit/byte string so they can do what
they want if they understand the environment.
The idea of 'stringification', that is providing to the programmer for
use inside the program a predictable representation of a complex object,
also seems to me to be something to exploit. In the case of a resource
name, the one most easily available to the programmer would be a
'stringified' version of the underlying stream of bytes used by the
operating system.
Eg. if a File object located in some directory under some OS would have
both $file.name as a unicode representation and a $file.underlying_name
with some arbitrary sequence of bits with a semantics known only to the
OS (and the perl implementation).
d) It would be nice to specify filters on the incoming and outgoing
data. I find I do the following all the time in perl5:
while (FN) {chop; …};
So my example above, viz.,
while $file.read { … };
would automatically provide $_ with a line of text with the EOL chopped off.
Note that the reverse (adding an EOL on output) is so common that perl6
now has 'say', which does this.
Could this behaviour (filtering off and on the EOL) be made a part of
the standard “read” and “say” functions?
Allowing access to the filter function (allowing a programmer the
ability to override an attribute) could be quite useful. For example,
suppose the role providing getline includes an attribute with default
$.infilter = { s/\n// }; # a good implementation would have different
rules for different OS's
and this can be overridden with
$.infilter = { .trans ( /\s+/ = ' ' ) }; # squash all white space to a
single space
or
$.infilter = { s/\n//; split /\t/ };
then a call to $file.read would assign an array to $_ ( or would it be
@_ ?)
Filtering the outgoing data would be similar to using a format string
with printf, but associating it with the IO object rather than with a
specific printf statement. Thus suppose instead of a file, the IO object
is a stream associated with the internet and the role that provides
“say” as a method on a stream object has $.outfiler as an attribute,
then overidding
$.outfilter = { s[(.*)] = “$1\n” };
with
$.outfilter = { s[(.*)] = “htmlbody$1/body/html” }
would mean (I think) that
say “hello world” :to$stream;
would generate the http stream
htmlbodyHello World/body/html
(Yes I know, the space should be coded, but hopefully the idea is clear.)
e) When dealing with files in directories in perl5 under linux, I need
opendir(DIR,'./path/') or die “cant open ./path/\n”;
my @filelist = grep { /^.+\.txt/ } readdir(DIR);
I would prefer something like
my Location $dir .= new(:OSpath'./data');
and
Re: Files, Directories, Resources, Operating Systems
Just as a variable name in perl6 must conform to a standard and abide by
a set of constraints, why should file or other resource names be an
exception?
The constraints on variable names in perl6 are very flexible, but there
are some rules that must be enforced for a program to work.
It seems to me that resource (eg. file) names too should also be
constrained so that software portability can be ensured. A reasonably
constructed set of constraints for the perl6 core should deal with most
locale/OS/character set considerations, and where a particular
environment cannot cope, then a module will be needed to eigenmunge
the names appropriately.
Suppose for the sake of argument we state that resource names in perl6
shall comply with the rules for variable names; and the sort sequence of
such names is the one defined for unicode strings.
Where software in perl6 is written for a specific domain, eg. Catalan or
Russian, the programmer will know more about the domain and how to deal
with resource names in that locale. This would include sort sequences
and the complexities Tom outlined. Such things would be relegated to OS
/ domain specific modules.
Would this help?
Tom Christiansen wrote:
In-Reply-To: Message from Darren Duncan [EMAIL PROTECTED]
of Wed, 26 Nov 2008 19:34:09 PST. [EMAIL PROTECTED]
Tom Christiansen wrote:
I believe database folks have been doing the same with character data, but
I'm not up-to-date on the DB world, so maybe we have some metainfo about
the locale to draw on there. Tim?
AFAIK, modern databases are all strongly typed at least to the point
that the values you store in and fetch from them are each explicitly
character data or binary data or numbers or what-have-you; and so,
when you are dealing with a DBMS in terms of character data, it is
explicitly specified somewhere (either locally for the data or
globally/hardcoded for the DBMS) that each value of character data
belongs to a particular character repertoire and text encoding, and so
the DBMS knows what encoding etc the character data is in, or at least
it treats it consistently based on what the user said it was when it
input the data.
Oh, good then. That's what I'd heard was happening, but wasn't sure since
I've steared clear of such beasties since before it was true.
I wish our filesystems worked that way. But Andrew said something to me
last week about Ken and Dennis writing quite pointedly that while you
*could* use the f/s as a database, that you *shouldn't*. I didn't know
the reference he was thinking of, so just nodded pensively (=thoughtfully).
There is ABSOLUTELY NO WAY I've found to tell whether these utf-8
string should test equal, and when, nor how to order them, without
knowing the locale:
RESUME,
Resume
resume
Resum\x{e9}
r\x{E9}sum\x{E9}
r\x{E9}sume\x{301}
Re\x{301}sume\x{301}
Case insensitively, in Spanish they should be identical in all regards.
In French, they should be identical but for ties, in which case you
work your way right to left on the diactricals.
This leads me to talk about my main point about sensitivity etc.
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? There is no good answer, because we might think it
reasonable to
lc(strip_marks($old_fn)) eq lc(strip_marks($new_fn))
Theee problem of what is or is not a mark varies by locale,
* Castilian doesn't think ~ is a mark; Portuguese does, and
so if you strip marks, you in Castilian count as the same
two letters that it deems disinct, but in Portuguese, you
incur no lasting harm.
* Catalan doesn't think ¸ is a mark; French does. and so if you strip
marks, you in Catalan count as the same two letters that it deems
disinct, but in French or Portuguese, you incur no lasting harm.
* Modern English (usually) decomposes æ into a+e, but OE/AS and
Icelandic do not.
* Moreover, Icelandic deems é and e to be completely
different letters altogether. If you strip marks, you
count as the same letters that that language does not.
Similarly with ö, which is at the end of their alphabet,
(like ø in some), and nowhere near o or ó. BTW,
Files, Directories, Resources, Operating Systems
The S16: chown, chmod thread seems to be too unix-focussed. Perl6 is being born in a world dominated by the internet. Whilst perl was the glue for the internet when the internet was born, it was a unix child. I learned perl from a Windows perspective and I found the discussion of ownership and file tests odd. Moreover, there were things I wanted to do with perl that seemed unduly cumbersome in Windows because the paradigm perl used was a unix one, but adapted to Windows. To be portable, the minimum assumptions need to be made about the environment in which a program operates. Alternatively, the software needs to be able to determine whether the environment it is operating in meets a minimum set of conditions. Where software is written for a specific environment, the developer already knows more about the environment. Thus I would suggest that the perl6 specifications should be written in an abstract way, one not related to a specific operating system and in a way that can be adapted by an implementor to specific systems. Following the general perl6 philosophy, perhaps too there should be an abstract definition for the language that is core and additional modules that are specific to operating systems. Thus when generic software is distributed, it comes with an installer that determines the operating system chooses whether to use IO::Unix, IO::Unix::Gnome, IO::MS::WindowsXP, IO::MS::Vista, IO::Apple, etc. Maybe also IO::Internet::Http, IO::Internet::Ftp? Thus, questions concerning ownership, chown, etc would be left to modules. Modules for specific systems would make it easy to deal naturally with those systems. Software written specifically for one OS would explicitly use the appropriate module, and hence would be able to rely on constructs natural for that system. The interesting questions then would be what abstract concepts should be core to perl6 and which ones should be left to Do we continue to talk about a file, or do we talk about a resource or datastream? When considering internet resources, the concept of trust is more important than the concept of ownership. It would seem to me that a program should be aware of the continuing ability of the datastream to operate, viz., supply / accept data, so that a program doesnt hang waiting for data from a source that has been disconnected.
Re: Speccing Test.pm?
Two sorts of testing - a) compiler, b) modules. Each category has different environment and function. a) compiler. An official test suite is defined (and probably will be added to as corner cases / ambiguities are discovered and disambiguation decided, so presumably some standardisation of testing must exist, either implicitly or explicitly). Hence tests are canonical. Compiler is changed to conform to tests. Function of test suite - validate compiler implementation as perl6. b) modules. Valid compiler is assumed. Tests and module are changed to conform to compiler. Function of test suite - validate that a module works in an expected manner on a valid complier. Clearly, the functionality in Test.pm (for modules) could/should be a superset of the functionality in test_compiler.pm, and can assume a valid compiler. The interesting question - I think - is how practically and elegantly to ensure the tests in the compiler validation suite achieve their task. Two alternatives it seems are possible: a) Define the code for test_compiler.pm which is guaranteed to run all the test suite. This make test_compiler.pm a part of the language, viz., implementation as specification. Tests will be needed in the official test suite to ensure that test_compiler.pm running under the new compiler conforms to specification (eg., an error in the compiler reverses the meaning of the test functions). b) Define the core functions for testing the compiler as part of the language, allowing no others in the official test suite. Alternative implementations of test_compiler.pm are possible (though a prototype could be provided). Tests needed in the official suite to validate conformity of implementations of the test functions to specification. Whatever, it does seem to me that if perl6 is to be defined by its specification and its test suite, then the testing process has also to be defined within the language. If the testing process is not defined at the same level as the language itself, then at some point the validity of a compiler of the language will be dependent on the implementation of a part of the testing process. Patrick R. Michaud wrote: On Tue, Sep 02, 2008 at 12:32:49PM -0700, Darren Duncan wrote: Patrick R. Michaud wrote: I think it's good to have a prototype Test.pm that we can point to as a reference, but I don't think we need to try to designate it as being official. [...] 2. The Perl 6 language spec itself would specify a basic set of test routines built-in to the language, in a Test namespace, much as it defines collections of routines now for such as numbers and arrays and standard I/O. And so the basic test routines would be formally defined in a Synopsis document. I disagree. The testing we're likely want to do as part of the language test suite may be substantially different from what we want to provide to module writers for testing. In particular, I think that the test suite harness should require only a minimal Perl 6 implementation (note I said harness, not the tests themselves), whereas it's much more reasonable that a testing system used by module writers could/should assume a fully working Perl 6 implementation. It's a difference of bootstrapping versus running environment. I also don't see the possibility of our getting it wrong in the design to be such a big deal, since the odds are anything we think of now will work well for many years, as Test.pm/Test::More has been fairly stable already and meanwhile Perl 6 is versioned now, so we could make an incompatible change to the Test related language spec in the future, and as long as users say use Perl-6.0.0 their code relying on the older/current Test.pm like interface won't break. Perl 6 is versioned now is a misnomer. The *spec* calls for a versioned Perl 6, but I'm not aware that any of the implementations do much with that. At any rate, relying on handling multiple versions of Perl 6 to run Test.pm is exactly one of those things I'd like to avoid in the official test suite. Pm This mail was received via Mail-SeCure System.
Re: All classes imply the existence of a role of the same name.
All classes imply the existence of a role of the same name. -- c Please justify that. --John As a 'Joe Blow' type programmer trying to follow this thread, I went back to the traits paper http://web.cecs.pdx.edu/~black/publications/TR_CSE_02-012.pdf and read John's Polymorphism paper. From the traits paper and some of what I have picked up, I think we have: An object is an instance of a class. A class is composed of roles (traits) + state + glue. Roles can be composed of other roles, but not from classes. Hence conceptually the programming sequence is a) make roles; b) make classes; c) make objects. (This makes roles more 'fundamental/granular' than classes.) So: - if u want an object direct from a role, perl6 automatically completes the sequence by making an anonymous class for you - if u want to add a role to an existing object, perl wraps the object into a class, adds the role, reinstantiates the object. Is my understanding correct? I'm not sure, but am I right in thinking that a role can have objects from other classes? It seems to me that the jargon of 'inheritance' normally applied to a relation between objects and classes is misplaced in perl6. It is rather classes 'inherit' roles (like animals inherit genes from parents). Objects emerge as exact copies of each other from a class (template), only becoming individuals when their 'state' is changed. This is more like asexual reproduction. Sexual reproduction requires that individuals come from two predecessors and genes are not all passed on. inheritance therefore implies a loss of information (not all genes from both parents are expressed) and the complete individuality of nearly each child. In trying to understand the idea of types, am I correct in understanding that perl6 is seeking to define the 'type' of an object by something other than the name of its class? If this is true, then from the equation class=roles+state+glue we see that the type of the class could be defined in terms of 'role' and 'state'. If we assume that 'glue' is not involved in type, then objects born from different classes may have the same type if their 'roles' and 'state' are the same (but not the content of the state), or they can be made into the same type by having wrappers to emulate said roles and state. If this is true, then anything that is not 'roles' or 'state' is 'glue', which should be ignored by the type system. If the programmer wants things currently defined in his/her class as 'glue' to be a part of the type, then it should be factored out into a 'role'. As for input and return values, couldnt these simply be considered aspects of 'state'? Return is a sort of accessor that gives the end value of a process, while input variables change the state of the object at the start of a process. Is this too simplistic? However, I find myself completely lost when it comes to 'super-', 'generic', and 'duck' typing. What extra capacities do these concepts give a programmer that cannot be obtained from the roles/class/object hierarchy? Regards, Richard Hainsworth
Re: Nomenclature Question - BEGIN etc.
How about 'contingent blocks', because they are contingent on some event, without having to use the word 'event'. Richard TSa wrote: HaloO, Larry Wall wrote: Hmm, maybe control event blocks and control events, then... I would call them flow blocks because this is where they are called and what they influence: the flow of execution. This nicely matches the flow charts used to describe the control flow. The other term I would thing is synonymous to flow is stream. But that's already taken for event stream, data stream and implies linearity whereas flow naturally implies branching. The third term I come up with is context blocks. But context in Perl 6 is something very different. Regards, TSa.
Re: Perl 6 fundraising and related topics.
Uri, Consider the position you put me, or another sponsor, in. You mention a specific person, someone who is highly respected and extremely talented. You ask if I consider this person to be as flaky as a character that was a figment of my imagination, and if I say 'no he is not so flaky', then the implication is I will provide sponsorship. And if I demur, you might say 'put up or shut up' and I feel under pressure to do something I might not really want to. But even if I say 'sure, how much?' to Damian Conway, what do I say to another request for a Klingon of altogether unknown character? And suppose I cant manage the whole amount, but I can pay a part, who makes up the rest? And suppose I pay my money, but the trip is cancelled, who pays me back? And suppose I want to sponsor the development of perl6 over parrot, leaving training to someone else? Can I respond easily to your direct request without implying some slur on Damian? The whole point about having an institutional channel for sponsorship is to remove the need for personal judgments, for sponsors to specify exactly how their money should be used, for the procedures to be in place to cover shortfalls from a central budget, for rules to be clear about what happens to money that is in excess of earmarked programmes, and for there to be clarity in all possible grey areas that happen in life. What the perl6 language needs now is a systematic development plan, with broad aims and clear goals that will lead to good quality software and to the tools to enable ordinary programmers to use perl6 for a variety of tasks. More than that it needs the excitement that comes when there is tangible progress (just look what has happened to parrot as a result of the funding arranged via The Perl Foundation). Ad hoc, piecemeal processes will yield ad hoc piecemeal results. I have absolutely no issues with the excellent series of courses you run, especially if they are taught by Damian. But where do they fit into the general scheme of things? Are they essential to the development of perl6, or do they only benefit a small group of regional companies. Do they benefit me (bear in mind that the company I run is based in Moscow, Russia)? Sorry. You asked questions I am not prepared to answer because the questions were posed in a manner that prevents me from answering. Do this through The Perl Foundation and you will get a clear answer. Richard Hainsworth Uri Guttman wrote: RH == Richard Hainsworth [EMAIL PROTECTED] writes: RH No one likes bureacracy. But I feel much happier about handing over RH money, or persuading someone else to hand over money, to a group of RH people with established procedures and collective responsibility, than RH to some enthusiatic individual who promises the earth and whose the RH world-number-one genius at code writing, but might also go and blow RH the whole lot on girls and booze cos his cat died. would you think damian has enough anti-flake genome in him to qualify for a more direct donation? :) if you do and agree that damian is worth supporting, i have an opportunity to propose. i am producing the perl college which is a set of classes taught by damian in boston, aimed at junior perl hackers. the college is sponsored by companies looking to hire intermediate level perl developers. your company or you as an individual, can be a sponsor which will support damian to come to the states for this set of classes and also for the conferences (which he missed last year because his funding came up short). if you are interested contact me off list at uri AT perlhunter.com. for more info on the perl college go to: http://perlhunter.com/college.html thanx, uri, dean of the perl college.
Re: Perl 6 fundraising and related topics.
In my $life, I raise money from sponsors. It is not difficult to spend money, once you have it. It is not difficult to raise money, once you know how to spend it wisely. What's difficult is putting the two together. Some donors know what to contribute to - they choose specific projects and people. Some donors want to help achieve a general aim - they give to a foundation that will wisely spend the money for them (eg. Warren Buffet giving gazillions to Bill Gate's foundation). Any sponsorship program should enable both ear-marked and general contributions (and I am certain if the paper-work's done right, this can be achieved within TPF). To be frank, the ONLY reasonable systematic way of managing a sponsorship process is to have a Foundation, and the foundation should have people who are trusted, who already have contributed to the process, and who are prepared to report back on how the money has been spent. The Perl Foundation meets these criteria. If you spend time on administration, you are using resources, in just the same way as programmers hacking on the code. So if the officers of the Foundation are paid for their efforts, that is acceptible so long as the payments are commensurate with resources spent in other directions. It is not a mathematical formula, its a question of balance and fairness and transparency. No one likes bureacracy. But I feel much happier about handing over money, or persuading someone else to hand over money, to a group of people with established procedures and collective responsibility, than to some enthusiatic individual who promises the earth and whose the world-number-one genius at code writing, but might also go and blow the whole lot on girls and booze cos his cat died. Whilst debating issues like parrot vs pugs, or single-track vs parellel track development, can be quite interesting, especially if it induces Larry to compare straight lines to mountains and railroads, it is likely to be more useful to have suggestions like chromatic's - 1month of dedicated work for $5000. How about adding a page to one of the web sites where offers of help, time and expense, can be made? The micro-grants idea is great. What I have seen of the results and reporting is fine. More grants, more people, and more results are needed. How about everyone reading this thread thinking about a micro-project they can do. Finally, there needs to be recognition for the sponsors, both those that donate their talent resources such as volunteer designer, implementors, hackers, and those that donate just cash. How about a mandatory section of text at the top of each core and sponsored module that lists the sponsors? Just like license text. That way all contributors are recognised when/if perl6 becomes the predominant programming environment, those names become distributed around the world.
Re: Perl 6 fundraising and related topics.
Me too. $500. That's 3*500, so far. Can I do this through the Perl Foundation as an earmark? Conrad Schneiker wrote: On Thursday 21 February 2008 06:25:42 Joshua Gatcomb wrote: On Thu, Feb 21, 2008 at 4:23 PM, chromatic [EMAIL PROTECTED] wrote: I could take a month's sabbatical from my day job for $5000 without losing insurance coverage or other benefits. That's slightly more than Audrey's $100/day, I know, but it's substantially less than my consulting rate and somewhat less than my salary too. I could probably make 100 - 150 high-quality commits to Parrot in that 30 day period. Perhaps more. I'm probably not the only Parrot/Perl 6 hacker in this situation. I was beginning to wonder if my post to the thread had gotten eaten. Thanks for replying. I probably didn't do a good job of tying the two portions of my reply together, but if I were to go to the donation page and I saw Project: Allow chromatic for 1 month to work exclusively on parrot Deliverables (if applicable): 100 - 150 high quality commits Required: $5000 Current: $0 I would be very inclined to make a donation. In fact, if you can find 9 other people willing to do so - I will cut a check for $500 any time you are ready. That's besides the point. Not to me it isn't. :-) Count me in as person #1 of the 9 others. I don't believe just getting more money is the solution. I think we need to do a number of things: 1. Identify people, like you, who are in a position to trade time for money and the projects they will work on 2. Allow people to choose where their money will go (if that's what they want to do) 3. Do it in a way that causes the least amount of fighting Good ideas. Best regards, Conrad Schneiker www.AthenaLab.com http://www.perlfoundation.org/perl6 — Official Perl 6 Wiki http://www.perlfoundation.org/parrot — Official Parrot Wiki
Re: Perl 6 fundraising and related topics.
OOOWWW my tail is burnt!!! But I wasnt on the committee... promise. Sorry about the cat... So lets get some money into this Foundation, so that, perhaps, Larry might possibly, if he deserves, get a little more money. Richard Larry Wall wrote: On Fri, Feb 22, 2008 at 11:03:03AM +0300, Richard Hainsworth wrote: No one likes bureacracy. But I feel much happier about handing over money, or persuading someone else to hand over money, to a group of people with established procedures and collective responsibility, than to some enthusiatic individual who promises the earth and whose the world-number-one genius at code writing, but might also go and blow the whole lot on girls and booze cos his cat died. Let me make a clear statement here. I have no trouble with the committee making its decisions--that's what the committee is obliged to do. The committee is *not* obliged to feel secure about that; (nor do I feel obliged to allow them to feel secure about that ;) nevertheless, the committee is also not obliged to demonstrate its insecurity by heaping scorn upon such persons of indeterminate feline attachment while turning them down. A simple no would suffice without the we-had-to-say-this-because-you-suck bits. By the way, it's possible that I might deserve a little more money, because *my* cat died last year, and as near as I can tell, I didn't spend any money on girls and booze because of it... :) Larry
Re: pluralization idea that keeps bugging me
Brandon S. Allbery KF8NH wrote: On Feb 9, 2008, at 11:43 , Richard Hainsworth wrote: I posted an idea about pluralisation could be handled in a way that would not be English-centric (Subject: interpolation contextualisation). There were no responses to the idea. Was it so bad? Did no one see it? Was it too un-perlish? Was the title too horrible? I saw one response, noting that you can define in a module your own quote characters with their own interpolation rules; no core changes needed. Why then did Larry ask the original question? Why also did others with far better knowledge than I indicate that hooks should be present in interpolation to make language-dependent modules possible, thus indicating the hooks might not be there? How - in sketch form - would I go about creating a module to do what I suggest? I am not suggesting someone writes a module I have suggested, but the barebones steps to creating a new metacharacter. I have written infix multidispatch functions in pugs with Unicode characters to investigate that part of the language. But I dont quite see how to go about creating a new interpolatable metacharacter.
Re: pluralization idea that keeps bugging me
Warnocked!
I posted an idea about pluralisation could be handled in a way that
would not be English-centric (Subject: interpolation contextualisation).
There were no responses to the idea. Was it so bad? Did no one see it?
Was it too un-perlish? Was the title too horrible?
The basic idea would be to add hooks into interpolation to allow for
context suppliers and context sensors. The context sensors change words
depending on data supplied through context suppliers.
Note that even in English, if you change a noun from singular to plural,
you need to change the verb from singular form to plural form.
Larry Wall wrote:
Last night I got a message entitled: yum: 1 Updates Available.
Of course, that's probably just a Python programmer giving up on doing
the right thing, but we see this sort of bletcherousness all the time.
After a recent exchange on PerlMonks about join, I've been thinking
about the problem of pluralization in interpolated strings, where we
get things like:
say Received $m message{ 1==$m ?? '' !! 's' }.
My first thought is that this is such a common idiom that we ought
to have some syntactic sugar for it:
say Received $m message\s.
which reads nicely enough since the usual case is plural.
Basically, \s would be smart enough to magically know somehow whether
the last interpolation was 1 or not. It would be particular nice when
the interpolation is a closure:
say Received {calculate_number_of_messages()} message\s.
That would cover most of the cases for English speakers using regular
nouns, but I wonder whether there's some kind of generalization that
would help for cases like:
say There was/were $o ox/oxen
But that doesn't work since / isn't a metacharacter. Using an adverb
seems like overkill, if we can piggyback on an existing metachar.
Maybe something like
say There was\swere $o ox\soxen
where if anything alphabetic follows the \s it is the alternative
plural. But note that the first \s there would have to be looking
forward rather than backward to do the verb, which constrains the
possible mechanisms, and makes it problematic to use \s multiple times:
say There was\swere $o ox\soxen and $g goat\s.
though that could be made clearer with explicit concatenation:
say There was\swere $o ox\soxen ~ and $g goat\s.
say There was\swere $o ox\soxen , and $g goat\s.
Or maybe instead of using \ we should use a sigil:
say There $was|were $o $ox|oxen
except, of course, that $ is already taken. Seems tacky to
use up a real variable name like:
say There $Xwas|were $o $Xox|oxen
I suppose one could make a case for Num vars having a . method though:
say There $owas|were $o $oox|oxen
That nicely resolves the ambiguity of
say There $owas|were $o $oox|oxen and $g goat$gs
but doesn't really help when you really need it, which is when you
interpolate something hairy:
say There $j.k.l.m.owas|were $j.k.l.m.o $j.k.l.m.oox|oxen and $j.k.l.m.g
goat$j.k.l.m.gs
It's even less helpful when you interpolate a closure since there's
no variable name to refer to (unless you assign one, but then we're
losing much of our syntactic sugary wonderfulness). So maybe we should
just make \s dwim and leave it at that. Two dwimminesses, really.
The first dwim finds the associated interpolation, either the first
interpolation of a variable or closure before the \s, or if there
is none, the first one after. Call that interpolated value $X for
the moment. (It doesn't really have to have a real variable name,
but the important thing is not to evaluate the expression multiple
times since it might have side effects (including the side effect of
being inefficient to compute).)
The second dwim looks at the alphabeticality of the next character
(defined Unicodically, of course) to decide if there is one argument or two:
foo\s means $X == 1 ?? 'foo' !! 'foos'
foo\sbarmeans $X == 1 ?? 'foo' !! 'bar'
Internally, you end up multiply dispatching to something like
pluralize($X,'foo') or pluralize($X,'foo','bar'). (Arguably we
could make pluralize interpolate the $X as well, but that only
works for noun agreement, not verb agreement.)
I think that probably handles most of the Indo-European cases, and
anything more complicated can revert to explicit code. (Or go though
a localization dictionary...)
Any other cute ideas?
Larry
Re: pluralization idea that keeps bugging me
Perl - when I first met it - was great because it handled text easily
and 'naturally'. I now use perl for everything, even when another
language would probably be better.
Perl6 has gone a long way to making things more universal by using
UNICODE, (The difficulties of non-Latin fonts and coding are horrendous).
Mark and chromatic are right that an ability to manipulate multiple
languages naturally and in core would be something no other
programming language does.
Perl6 seems to handle most of the necessary things, but not all - I
think. Hence Larry's original question.
There are - it seems to me - several different aspects to consider. My
breakdown would be:
a) having the language constructs that make text interpolation easy -
that is the *text* morphs itself to adjust to the context brought in by
the interpolated data. What is necessary is not a plurals fix for
English, but a mechanism for fixing that can be applied to other
languages. (Here I think perl6 grammars will help, but I am not sure,
and without proof of concept actually doubt the facility exists in perl).
b) Translating the perl core itself - the use of other languages to
write code in. Given perl6 grammar, and given that any programming
language is a rigidly circumscribed subset of words, I think this is
entirely possible in most natural languages. Clearly for the compiler to
work, an non-English coding language must uniquely map to and from an
equivalent English coding.
c) Having the mechanisms in perl6 core not just to interpolate text
contextually, but also for different texts to be used with the same
interpolations (when a text is translated, different sentence structures
result). As Mark pointed out, this can be accomplished with Templates.
d) Ensuring that different information streams can each be directed
through templates. As Mark pointed out, more is needed than standard
input, output, and errors. Moreover, it would be fantastic if the output
from the perl6 compiler could be constructed so that its information
streams (warnings, errors, etc) could be attached to translation filters.
I think item (a) is not quite there in perl6. But I really want to use
perl6 and I hope this line of development does not derail the fantastic
amount of momentum we have seen in recent months.
Mark Overmeer wrote:
* Larry Wall ([EMAIL PROTECTED]) [080126 16:58]:
Last night I got a message entitled: yum: 1 Updates Available.
After a recent exchange on PerlMonks about join, I've been thinking
about the problem of pluralization in interpolated strings, where we
get things like:
say Received $m message{ 1==$m ?? '' !! 's' }.
Any other cute ideas?
I totally agree with many responses, that special support for the English
language is not preferred, certainly when it bothers developers for
other natural languages. Imagin that you wrote your code this way for
snip
To syslog in English (what I understand), and to the website in Chinese
(what I do not understand) Of course, there are quite some more features
in the module.
snip
Concluding:
- hopefully, there is a way to simplify the work for all of us who do
need to support many languages within one application
- create one standard, so all CPAN modules integrate in the same way
- let's try to get Perl to handle languages!
Re: pluralization idea that keeps bugging me
Its only English centric if the idea is fixed to plurals, because its
only for plurals where English words are mutated by grammar rules.
In other languages, words are mutated by other factors, such as the
gender of the word, the case, and the number.
The problem can be quite difficult, say in Russian. Suppose you want to
say something like Respected customer name and interpolate customer
name from a database. In English, its a doddle. But in Russian, all
adjectives (eg. 'respected') have both male and female forms, so the
gender of customer has to be determined in order to correctly interpolate.
And for plurals, some languages have different words for single, double
and many forms. In
Russian, the noun after the number has one form for 1 (nominative
singular), another form (genitive singular) for numbers 2 to 4, and then
a third form (genitive plural) for 5 and above. So, a simple plural hook
is insufficient.
Then take Welsh, its words mutate with prefixes as well as suffixes
dependent on context.
Whilst it would be nice for there to be a neat syntax for such things
(thus avoiding English-centricity), the complexities of all languages
might be too burdensome for core perl6.
Amir E. Aharoni wrote:
On 26/01/2008, Larry Wall [EMAIL PROTECTED] wrote:
After a recent exchange on PerlMonks about join, I've been thinking
about the problem of pluralization in interpolated strings, where we
get things like:
say Received $m message{ 1==$m ?? '' !! 's' }.
...
Any other cute ideas?
No matter what you do it will remain too English-centric. It might
work for Catalan, too. But it will remain totally useless for Arabic
or Chinese.
In any case, i don't understand why should this be in the core language at all.
Re: what should be the default extension?
May I suggest the following extension to the 'use ' pragma, viz. use module name written in unicode and case sensitive in filename as constrained by local system For justification, see below. asideThere were some hot replies to what I thought was a fairly trivial question. A corollary perhaps of an observation in Parkinsons Law - people on committees argue longest over the item with the smallest cost. :)/aside The broken operating system, or rather family of systems (and I converted away from them about three years ago), still is used by 90% of users. In practice, it does matter what happens in that environment. But also consider, whatever operating system is in use, it has to know how by default to handle a file - interpret it as a script, run it as a native executable, pipe it to an editor or renderer etc. That information has to be associated with the file in some way. One operating system uses name extensions, another looks at the first line for a #! etc. Personally, I find it useful to have a visible clue in the name (via an extension) as to the content of the file. This seems to me more widespread than just an OS requirement, as otherwise why have *.tar *.tar.gz *.pdf *.doc *.png etc or even .* for hidden files in unix? If it doesnt matter - as far as perl6 is concerned - how the module is named (see Larry Wall's response regarding unicode and case-sensitivity), then the extensions too are irrelevant, no? So if I choose to call my perl6 scripts *.p6 it should not matter? Other than for the sake of tradition or conformity with the tribe's sense of propriety :) And that brings me to another question. Should it matter what the name of the file is? For modules in perl5 as far as I can discern, the name of the module in the file name has to conform with the package name inside the script. I have found this default behaviour annoying at times. By extending the 'use' pragma to include information about which container it can be found in, filenames become truly irrelevant. Moreover, the initiation file for a large project might just be a configuration file containing all the module names, together with use Main main in ProjectDebugStage.v03 [EMAIL PROTECTED] wrote: No, some people put .pl on the end of their scripts because they are running on broken operating systems. So, I imagine, for Perl6, I'll be making the same strong recommendation that Perl6 scripts, just like Perl5 and Perl4 scripts before them, have *no* extension. Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 Enthusiastically seconded! Why should we let the language of Mordor corrupt our discourse? -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
calling parrot from perl6
Not sure whether this should be p6-lan or p6-users. Posted to p6l only. Given a function implemented in parrot, how can it be called from a perl6 program? Suppose I have a file (in current path) myfun.pir which contains .sub myfun .param pmc passed_variable .local int an_int an_int = passed_variable[1] .local string string_var #code .return (string_var) end# is this necessary? .end how do I create a mymodule.pm so that I can in a perl6 program do use mymodule; my $parameter = 30; my $string_var = myfun($parameter); ??? If this is documented, please just send a pointer. Richard
Re: Standards bearers (was Re: xml and perl 6)
Why thank you Mr. Chromatic! In between all my other activities, I have been trolling along this list from its inception, and followed eagerly every Appocalpse, Exegisis and Synopsis as soon as they came on line. I download pugs and parrot from SVN repositories, written tests - one of which still hangs the compilation of pugs. Indeed the test I wrote for pugs concerned the ability of pugs to use existing CPAN modules. I have tried parrot with SDL and the tests fail. My aim was to write a P6 GUI module so that from the start it would be easy for P6 users to generate UI interfaces easily. Unfortunately, despite my eagerness, I am not a professional programmer with the time or the skill to fix the problems. Where I can contribute is to express a view about how P6 might best be developed. Moreover, I do think that sketching out the way modules should (at least initially) be written, and skteching out which modules should be written as soon as possible, are as much a part of the language design as deciding how best to use the colon. Moreover, consider the development of pugs. The first modules to be developed were Test and Test::Harness. Vital for the development of the language. Not a part of the core. Equally, Something to replace CGI or DBI will be essential to the uptake of P6. I would far prefer to have a skilled and resourceful professional, such as yourself or Damian Conway write these modules than leave it to enthusiastic amateurs such as myself. And as for singularities, I appreciate Larry's idea of language development as being akin to a strange attractor (expressed in answer to a question I posed on this list nearly a year ago about when P6 would be complete), but I also fear that the orbits that describe solutions to some strange attractors have a great deal of volatility and it is never possible to define at any time exactly what the orbit is - a bit like not being able to define all aspects of an electron due to Heisenberg's uncertainty principle. But if that is the case with P6 (and why should it not given the wholly new areas of programming that P6 is defining?) where does that leave people like me? Does it mean that we must abandon P6 to the professionals, just as strange attractors and quantum physics are the domain of professional scientists? Does it mean that I must, as it now seems to be the case, move my own programming and the main language of my firm's IT department to Python? I realise that @Larry have their own priorities, their own pressures, their own limited resources. I would like to help, yet there are limits to what I can do. And I am sure what is true for me is true for many others trolling on this list. You are doing a fine and wonderful job. Your efforts - I sincerely believe - should be applauded and appreciated. My impatience is due to a heightened expectation and desire to use P6 that in fact is a result of the fantastic achievements I have already seen. Richard chromatic wrote: On Saturday 08 December 2007 06:50:48 Richard Hainsworth wrote: Surely, some concentrated thought by the inventive and resouceful minds of who lead this project should go into language utilisation and popularisation. My goodness, @Larry's pretty darn busy trying to build the core kernel of Perl 6 in such a way that the rest of the world can build beautiful and useful things around that kernel much in the same way that the CPAN as a whole is the shining gem of Perl 5. You, Mr. Hainsworth, and every other person reading this message from December 2007 through the singularity (aka Perl 7) officially have my permission to think about this yourself and pitch in! (Fixing the mixed metaphor in my first paragraph is a good start. Reading S11 is step two.) No one ever needed permission, but if it makes anyone feel better, there it is. -- c
Re: Switch/Given and English, Was perl 6 grammar
snip I've never said that switch ... case was better than given ... when or that switch ... case was even a good construct. I have said that given ... when sounds weird as a construct (not mentionning the use of past participle and on top of that of an irregular verb). I understand the meaning and I can get over it but is proliferation of English idioms, words a good idea? There're bunch of words that could describe the same idea in a sligtly different manner. Perhaps writting a la smallTalk could be the solution. getting rid off all shortcuts and change them into explicit description entities and write english sentences, not programs. This could be nice but I will first have to learn English. Anyway, I will write my own 'Lingua::Given::Francais' with avec ... lorsque^^: (well, if I can - ^^; xx 1000 ) And that for me is the power of P6 - the fact that you WILL be able easily to write such a module. In fact, why not write a module Lingua::Francais that maps all the P6 constructs into French, thus making it much more accessible to the vast number of people whose primary and major secondary language is French. Ditto, Chinese, Russian and Spanish. Indeed, if that is done at the start of the utilisation of P6, it would ensure that P6 is used across the globe, and probably be the teaching language of choice for computer science in most non-English countries. The difficulty will be - unfortunately - that in some languages the logic will not map exactly because some human languages have different logical constructs. Hence there is the likelihood that some of the programming in other languages might still be awkward. However, I think that will be a minor consideration for student programmers who are not forced into learning a pigeon form of English in order to code their programs.
Switch/Given and English, Was perl 6 grammar
snip I don't know why, this given... when sounds so 'English' without really being that English. The construct given ... when sounds better in English than switch ... case ... because: a) Switch is more commonly used in English as a noun, eg., Use the switch to turn on the light. But because English can use nouns for verbs and adjectives as well, eg., 'Switch on the light' or 'he is a switched-on type of guy', it seems ok to use it in for control purposes. Except ... the verb is really 'switch on' not 'switch'. Also we have 'switch over', 'switch from', 'switch between' etc. where as 'switch' as a verb as in 'she just switched boyfriends' means exchanging one for another, not choosing between alternative cases. So really 'switch' as a verb is really more like 'toggle'. So when an English person (or at least one that cares about the use of language) sees 'switch' in a programming language, there is the feeling that something is missing, or not quite right. And there is absolutely no linguistic link between 'switch' and 'case'. If I am uncomfortable with 'switch', 'case' really sucks. In fact, whenever I work in language other than perl, and 'switch' is the preferred construct, I always have to check the syntax to work out what goes where. b) 'Given' is more commonly used in English as a verb form. 'He was given an award'. Also, it is in the correct form for use at the beginning of a sentence, eg., 'Given three choices, he chose the most profitable'. So we have something that looks and feels like it is a part of normal English speech. The 'when' part is also a natural tag in English indicating one of several alternatives. 'Given' can be used as noun (the power of English! as a language) as in 'we have a number of givens, but the issue is still unresolved'. This is much rarer than the use of 'given' in verb uses. c) You might ask, why bother? Just choose words, and since switch is the most common one, just use it. Well, computers dont care whether you use words or symbols, so long as semantics can be uniquely extracted from syntax, that is, the computer knows uniquely what you are trying to say to it. But the reality is that humans dont work that way. From the time of FORTRAN and COBOL, the aim has been to choose words over symbols so that they have semantic meaning for the programmer. It makes it easier for programmers to write descriptions of algorithms and operations, and to understand the logic of the descriptions they are writing. This reduces development and debugging time. Perl has been so successful, and my programming language of choice, because where words have been chosen, they have very similar semantics to normal English. That helps me in my programming. My own guess is that once Perl6 starts being used (When oh when oh when), other languages or dialects will switch 'switch' for 'given', or at the least, the 'given ... when' will be an alias for 'switch ... case'.
