Re: [perl6/specs] 761178: remove some some duplicate words words
On Tue, Sep 7, 2010 at 11:29 AM, Moritz Lenz wrote: > Brandon S Allbery KF8NH wrote: > > On 9/7/10 08:17 , nore...@github.com wrote: > >> Commit: 7611788411e5aff5f3ae150e2da9929ee546d6d8 > >> > http://github.com/perl6/specs/commit/7611788411e5aff5f3ae150e2da9929ee546d6d8 > > > > It was nicer when these contained the actual diffs like they used to, > > instead of forcing me to go poke at the tree. > > Indeed. Any contributions to restoring that behavior are very welcome. > 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). It links to the actual change and even highlights the changes. 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. -Jason
Re: Natural Language and Perl 6
On Sun, Aug 1, 2010 at 5:46 AM, Timothy S. Nelson wrote: >Hi. I'm wondering if any thought has been given to natural language > processing with Perl 6 grammars. > No specific tool is best suited for natural language processing. There was apparently a time in which everyone thought that a formal grammar could clearly define any natural language, but I don't think anyone succeeded at creating a complete formal grammar for any language other than something like Esperanto. Modern NLP seems to be focused on (empirical based) stochastic models or other statistical models. Most languages can be used to build and represent such systems. That being said, there are sub-fields where it might help, such as stemming, POS tagging, or text generation. Perl 6 grammars seem best suited to reduce the workload to build and manipulate parse trees or lattice models. Depending on what task is at hand, this may be of no use. I am finishing a masters in NLP and after all this work, p6 grammars wouldn't have helped much. -Jason "s1n" Switzer
Re: r31043 -[S32/Containers] Buf does Stringy, too
On Wed, Jun 2, 2010 at 5:10 AM, wrote:
> Author: masak
> Date: 2010-06-02 12:10:22 +0200 (Wed, 02 Jun 2010)
> New Revision: 31043
>
> Modified:
> docs/Perl6/Spec/S32-setting-library/Containers.pod
> Log:
> [S32/Containers] Buf does Stringy, too
>
> -class Buf does Positional {...}
> +class Buf does Positional does Stringy {...}
>
I never really thought about this, but now that I see it here, it made me
realize that how 'does' works seems verbose. I think we should be able to
specify a list instead of a bunch of 'does' statements. For example, the
above example should be written as
class Buf does Positional, Stringy { ... }
The repetitive 'does' statements is about as annoying as how you have to
specify public/private inheritance scoping for each class in C++. Even Java
gets this right:
http://en.wikipedia.org/wiki/Interface_(Java)#Defining_an_interface
Just an idea.
-Jason "s1n" Switzer
Re: Ideas for a "Object-Belongs-to-Thread" threading model (nntp: message 5 of 20)
On Thu, May 13, 2010 at 3:59 AM, wrote: > This should be a reply to Daniel Ruoso's post above, but I cannot persuade > my nntp reader > to reply to a post made before I subscribed here. Sorry > > And at the core of that, is the need for preemptive (kernel) threading and > shared memory. > > These can (and should!) be hidden from the application programmer, through > the use of language and/or library > level abstractions, of which there are many promising [sic] candidates. > > But fundamentally, they all require that: > >1) Preemptive scheduling be utilised. >2) The core interpreter be fully reentrant. >3) The core runtime libraries be fully reentrant. >4) That the language distinguishes between, and handles > appropriately, >- process-global entites: IO handles; environment; pwd etc. >- runtime stack-based(*) (lexical) entities: locals (my vars > in perl's terms). > I agree with this more than anything Daniel proposed. I prefer Perl 6 providing a thin interface to a kernel thread (i.e. NPTL), a means of creating shared memory objects between processes and threads, maintain reentrancy as per Buk's summary, and leave the rest for non-core modules. This allows for different threading, event, and shared memory models to emerge. You could then have different models, such as one that emulates Java's abandoned green thread model, something similar to POE, or something that emulates Erlangs process management. If you keep Buk's bullet points and give me a minimalistic interface to threads/shared memory, then it would allow me to create whatever wacky threading/shared memory model I can imagine. I think that's better than doing something that sounds dangerously similar to Java's RMI. -Jason "s1n" Switzer
Re: expression of seconds (was Re: A new era for Temporal)
On Fri, Apr 9, 2010 at 3:06 PM, Jonathan Worthington wrote: > Though even clearer and same number of characters as whole_seconds is: > > $dt.seconds.round This makes more sense to me than the first example you listed because when dealing with time measurement, I rarely think of seconds that are broken down to sub-measurements. Rather, I often think of seconds as an aggregation of milliseconds, so rounding the fraction (a second is internally a fraction of milliseconds) Just Makes Sense. The idea continues downwards to the smallest represented unit of time and upwards to the largest represented unit. -Jason "s1n" Switzer
Re: You never have privacy from your children in Perl 6
On Fri, Mar 26, 2010 at 7:16 AM, Carl Mäsak wrote: > You're using it wrong. You need to put 'trusts B;' in A in order for B to > > see A's privates. I hope it is obvious why this is the case. -- Darren > > Duncan > > Aye, my mistake. Apparently the syntax I used to try to get at the > private attribute would instead have called a private method. So much > for rooting things in the concreteness of an implementation. ;) I'm assuming Moritz is right in that Rakudo is currently leaky with private members (such as $!b in Masak's example), and I agree that truly private members has great value. It was unclear to me from the discussion so far whether this is the case for Perl 6. Also, this discussion of "trusts" piqued my interest; this sounds like a bad idea. Those of you who have worked extensively with C++ should bemoan "trusts" as much as friend classes. They break encapsulation for special cases, almost encouraging truly hideous object models that ultimately become purely public (painful on a large scale). I can't stress enough that if these are of similar nature, "trusts" should be removed. I'm all ears though if someone knows of a reason why they're more useful than onerous. -Jason "s1n" Switzer
Re: Gripes about Pod6 (S26)
On Fri, Feb 12, 2010 at 10:12 PM, Timothy S. Nelson wrote: > There's a school of thought, common among printing/publishing types, that >> insists that underline was intended solely to replace italics when they >> couldn't be represented (i.e. no fonts, as with ASCII terminals and >> printers). Thus Markdown's use of _italic_. (See also nroff.) >> > >I'm aware of that idea, and don't use underlining myself for that > reason. But since /italic/ looks like italic, and _underline_ looks like > underline, why are we using the thing that looks like underline for italics? > I mean, sure, I'm happy to get rid of _underline_ if that's what people > want, but using _ for italic is just ... well, I don't see any sense in it. If I recall correctly, this was a limitation of typewriters. Typewriters were incapable of displaying italics so underlining was taught as a replacement, though italics are/were considered the professional format. I somehow doubt that Markdown chose the _ for italics for that reason, though I will say that wayland's suggestion just makes more sense. -Jason "s1n" Switzer
Re: Interactive Perl 6 shell
On Mon, Dec 28, 2009 at 9:59 PM, Jason wrote: > > > *Connected by MOTOBLUR™ on T-Mobile > * > My phone accidentally sent an empty reply to this. What I was supposed to reply with was information regarding the built-in Rakudo REPL. You can see it in action here: http://perl6advent.wordpress.com/2009/12/01/day-1-getting-rakudo/ Sorry about that empty reply. -Jason Switzer
S19 questions
I was reading over S19 and had a few questions.
1) The colon delimiter (":name") is specified but no options are declared to
use it specifically. It's not clear why we would need this delimiter on top
of the other more popular delimiters. Are the long form (double dash), meta
syntax form (double plus), and short form (single dash) delimiters
insufficient?
2) The format for negative boolean options ("--/name" and "-/n" but not
"++/NAME") seems fairly non-standard in Unix AFAIK. This strikes me as a bit
awkward and I have been pondering if there is anything better. Maybe all
boolean options should default to false, making this format unnecessary?
3) Why have --verbose-config and not just --verbose?
4) The default is to always enable warnings (similar to the deprecated -w).
I would imagine warnings should be enabled, not disabled, similar to perl5,
GCC, python, and lots of other compilers/interpreters.
-Jason "s1n" Switzer
Re: Rukudo-Star => Rakudo-lite?
Since I don't know anything about nuclear power plants, I think the BikeShed should be painted blue and called "Rakudo Whatever" or just "Rakudo". -Jason "s1n" Switzer
[Invitation] June Dallas.p6m Meeting @ Tue Jun 9 7pm – 10pm (perl6-language@perl.org)
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20090610T00Z DTEND:20090610T03Z DTSTAMP:20090605T035152Z ORGANIZER;CN=jason switzer:mailto:jswit...@gmail.com UID:g3rsts66avsaacp817n7ri1...@google.com ATTENDEE;CUTYPE=GAIA_GROUP;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Dallas.p6m;X-NUM-GUESTS=0:mailto:dallas...@googlegroups.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=perl6-langu...@perl.org;X-NUM-GUESTS=0:mailto:perl6-langu...@perl.o rg ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=jason switzer;X-NUM-GUESTS=0:mailto:jswit...@gmail.com CLASS:PRIVATE CREATED:20090605T035151Z DESCRIPTION:Hello All!We are planning on having another Dallas.p6m meeting soon. We are meeting next week (Tuesday\, June 9th 7:00PM) at a coffee shop with free wifi. The address is \;985 W Bethany Dr Allen\, TX 75013 (Pete's Coffee inside the Market Street).\n\nThis is a pre-YAPC|10 meeting\, so the agenda will b e focused around recent Perl 6 advancements and YAPC. Since the group is ju st beginning\, all agenda plans are tentative and are open to changes. We'r e also looking for speakers and presentations\, locals only (no travel fund ing yet).Also\, since this will be our third meeting\, I have start ed a Google Group (possibly temporary) to help filter any future group traf fic from pestering the Perl 6 mailing list. The direct invitees from last m onth's meeting have been automatically added. The group is open to anyone w ho wants to join.Everyone is invited to come and have a good time. See you there!-Jason "s1n" Switzer\n\nView your event at http://www.google.com/calendar/event?action=VIEW&eid=ZzNyc3Rz NjZhdnNhYWNwODE3bjdyaTFuMmcgcGVybDYtbGFuZ3VhZ2VAcGVybC5vcmc&tok=MTgjanN3aXR 6ZXJAZ21haWwuY29tNmRiNDU1ODk3YTMyZmI2ZjNlYjY4ZTQwNGQ1YmFiOTExMDgzNzRjYQ&ctz =America%2FChicago&hl=en. LAST-MODIFIED:20090605T035151Z LOCATION:985 W Bethany Dr Allen\, TX 75013 (Pete's Coffee inside the Market Street.) SEQUENCE:0 STATUS:CONFIRMED SUMMARY:June Dallas.p6m Meeting TRANSP:OPAQUE END:VEVENT END:VCALENDAR invite.ics Description: application/ics
June Dallas.p6m Meeting
BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VEVENT DTSTART:20090610T00Z DTEND:20090610T03Z DTSTAMP:20090605T035153Z ORGANIZER;CN=jason switzer:mailto:jswit...@gmail.com UID:g3rsts66avsaacp817n7ri1...@google.com ATTENDEE;CUTYPE=GAIA_GROUP;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;CN=Dallas.p6m;X-NUM-GUESTS=0:mailto:dallas...@googlegroups.com ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP= TRUE;cn=perl6-langu...@perl.org;X-NUM-GUESTS=0:mailto:perl6-langu...@perl.o rg ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE ;CN=jason switzer;X-NUM-GUESTS=0:mailto:jswit...@gmail.com CLASS:PRIVATE CREATED:20090605T035151Z DESCRIPTION:Hello All!We are planning on having another Dallas.p6m meeting soon. We are meeting next week (Tuesday\, June 9th 7:00PM) at a coffee shop with free wifi. The address is \;985 W Bethany Dr Allen\, TX 75013 (Pete's Coffee inside the Market Street).\n\nThis is a pre-YAPC|10 meeting\, so the agenda will b e focused around recent Perl 6 advancements and YAPC. Since the group is ju st beginning\, all agenda plans are tentative and are open to changes. We'r e also looking for speakers and presentations\, locals only (no travel fund ing yet).Also\, since this will be our third meeting\, I have start ed a Google Group (possibly temporary) to help filter any future group traf fic from pestering the Perl 6 mailing list. The direct invitees from last m onth's meeting have been automatically added. The group is open to anyone w ho wants to join.Everyone is invited to come and have a good time. See you there!-Jason "s1n" Switzer\n\nView your event at http://www.google.com/calendar/event?action=VIEW&ueid=g3rsts6 6avsaacp817n7ri1n2g. LAST-MODIFIED:20090605T035151Z LOCATION:985 W Bethany Dr Allen\, TX 75013 (Pete's Coffee inside the Market Street.) SEQUENCE:0 STATUS:CONFIRMED SUMMARY:June Dallas.p6m Meeting TRANSP:OPAQUE END:VEVENT END:VCALENDAR invite20090609T19.ics Description: application/ics
Re: Module naming conventions
On Mon, Jun 1, 2009 at 7:50 PM, Jon Lang wrote: > On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera > wrote: > > I think we might need to come up with some sort of standard naming > > convention to distinguish dependencies. Something that the *user* can > > recognize quickly when he browses CPAN. > > Why do we need the dependencies to be part of the name? Perl 6 > provides a rugged versioning system for its modules; we should use it. I agree entirely with Jon. This sounds like a fruitless idea and outside the scope of the language. The only idea that I would give any consideration to would be to extend the versioning metadata to allow for the user to define new metadata. That sounds too similar to the goals of XML, but it would at least allow the community to define what metadata is important. Some things are best left unsaid. -Jason "s1n" Switzer
use v5 Support
I want to pose the same question for clarification that I asked #perl6: S01 says that perl5 code will be supported via "use v5". Can someone confirm that embedded perl5 code is still required of any valid implementation? If so, how will XS code be supported? Will the namespace between v5 code and v6 be shared? Will this be accomplished by linking libperl or libperl++ (if completed)? From what I've heard, there are issues with using libperl. This seems like a heavy burden for each implementation to bear. I want to propose another idea (that seems better to me at least). This sounds like a good place where a user module could create a perl5 grammar (a version of STD.pm). I'm not too familiar with how the perl6 STD.pm works, but I've heard there were efforts to attach actions to its YAML output, similar to how Parse::RecDescent does in perl5 to yacc-like grammars. That may be a bit naive, but someone pointed this section out to me and it raised a ton of questions. -Jason "s1n" Switzer
Re: Logo considerations
On Tue, Mar 24, 2009 at 3:10 PM, James Fuller wrote: > Is there any sponsorship money to spend on a very good graphic > designer to create something based on a small list of requirements as > to what meaning it should convey ? > I would agree; have a professional do it and we'll probably get better results. > Of course the logo should represent the community fundamentally, but I > find all of the suggestions little to do with addressing needs of a > logo versus needs of what I would call more of a 'club' badge. Having said that here's my idea: Basically, the perl community has largely adopted TIMTOWTDI as a philosophy (as well as DWIM, but that's harder to model). For that, a cluster of arrows in different directions seems fitting: http://3.bp.blogspot.com/_yy_uiqKCf0Q/RcEfrHZ_0hI/AB8/Mk1xayjGaSQ/s1600-h/arrows3.jpg http://www.sxc.hu/photo/1060296 http://www.sxc.hu/photo/659267 I personally like the idea of the last one (retains geek cred). [warning: light-hearted humor ahead] There's also the notion that perl6's scope has creeped to accommodate a large enough set of ideas. Seems like an appropriate logo: http://images.google.com/images?gbv=2&hl=en&q=kitchen+sink -Jason "s1n" Switzer
Re: r25490 - docs/Perl6/Spec
On Sun, Feb 22, 2009 at 9:47 PM, wrote: > Added: docs/Perl6/Spec/S28-special-variables.pod > === > +=head2 Named variables (see S02): > +$?OS # operating system compiled for > +$*OS # operating system running under > +$?OSVER# operating system version compiled for > +$*OSVER# operating system version running under How are you possibly going to get this in a remotely portable basis? How could an implementation handle the case of compiling a perl6 script down to native binary? Would the native binary always report the same OS and OSVER no matter where it executes after turned into a binary? > > +$?PACKAGE # current package (as object) > +@?PACKAGE # current packages > +$?PACKAGENAME # name of current package (see S10) $?PACKAGENAME seems kind of redundant when I could similarly do a $?PACKAGE.perl to get a coderef back as well. In fact, all of the variables that are named version of the coderef version should probably be removed in the favor of something like ~$?FOO or ~$*FOO. > > +$*PROGRAM_NAME # name of the program being executed > How does this differ from $*EXECUTABLE_NAME? > +$?PUGS_VERSION # Pugs version (not canonical) > +$*PUGS_HAS_HSPLUGINS # True if Pugs was compiled with support for > hsplugins > + # (not canonical) How do these apply to anything other than a single specific implementation? What motivation would Rakudo or elf have for defining these? > +&?ROUTINE # current sub or method (itself, see S06) > +@?ROUTINE # current subs or methods (themselves) > I'm sure this is a typo for $?ROUTINE. Besides, I think $?SUB makes more sense. > + > + $*OSNAME ...or some such > + $^O $OSNAME > + Doesn't correlate with the list above. > + > + $* and $# have been deprecated half of forever and are gone. $[ > + is a fossil that I suppose could turn into an evil pragma, if we > + try to translate it at all. (Frees up * twigil for $*FOO syntax.) I'm not even sure this makes sense to me. Is this saying that $* and $# are largely not in use anymore (in perl6)? -Jason "s1n" Switzer
Re: RFD: Built-in testing
On Fri, Jan 23, 2009 at 6:39 PM, Dave Whipp wrote:
> A spec-test is (or should be) different from an ad-hoc test. I want to be
> able to say "test S09.237 passes on pugs but not on Rakudo" (perhaps with a
> nicer name). Unique identifiers allow comparisons of specific tests across
> multiple implementations, and over time. It is possible to derive IDs using
> line numbers (perhaps block-relative), but that's only a good idea if the
> test suite is reasonably stable (and it requires tool support).
>
That sounds useful on the surface but often turns out to be more difficult
to do than you might think. There are many cases where tests are performed
from within loops. Something like S09.237 may or may not be in a loop, may
be difficult to identify in files with many tests. This sort of test name
could be the test message output by Test.pm's verbose output, but it then
makes the verbose output virtually useless in that Test.pm could just keep
records of the test numbers instead. There can also be multiple tests per
single line of code, especially if provided as an adverb, such as :ok
Test labels seems like an aspect that is highly susceptible to bit-rot due
to the ever evolving nature. Given the multitude of things that can go wrong
trying to keep records, it might not be a good idea to focus on this.
Rather, it might be a good idea to have the language provide a base test and
a means to extend the test. This would allow for the tests previously
written to transparently change the back-end testing mechanism.
Here's a very crude example. Lets say that ok() is defined by the Core (and
thus the language):
multi sub ok(Bool $test, Str $msg) { if $test { say "ok $msg" } else { say
"not ok $msg" } }
Then let's say I don't want the default (psuedo)-tap test output, I could
redefine what ok() does:
multi sub ok(Bool $test) { say "A test has failed at some point somewhere"
if $test }
ok(?($x == 4), "no good has come of this"); #calls Core's ok()
ok(?($x == 2)); #calls my crappy ok()
That's just an example to show that the language could provide a basic
version that is extensible with various implementations and various
compilers such that I don't have to write constantly unique test names (or
poorly identified names) and still only have to write a test once.
-Jason "s1n" Switzer
Re: RFD: Built-in testing
On Thu, Jan 22, 2009 at 4:51 PM, jerry gay wrote:
> $x == $y
>:ok({ .true ?? 'message' !! 'failure message' })
>:diag( 'tap comment', :some_tap_property)
I just want to stress again that I would like to see no focus on just tap
emitters. While I realize this is just an example, adverbs that apply to a
specific emitter would not be my preference. Extensible emitters would allow
integrators the opportunity to mix perl6 tests in with perl5 tests and xUnit
tests (for easily integrated test reports).
-Jason "s1n" Switzer
Re: RFD: Built-in testing
On Tue, Jan 20, 2009 at 1:08 PM, Moritz Lenz wrote:
> So Larry and Patrick developed the idea of creating an
> adverb on the test operator instead:
>
>$x == 1e5 :ok('the :ok makes this is a test');
>
> This is an adverb on the infix:<==> operator, and might
> desugar to something like this:
>
> multi sub infix:<==>($left, $right, :$ok) {
>$*TEST_BACKEND.proclaim($left == $right, $ok)
>or $*TEST_BACKEND.diag(
>"Got: «$left.perl()»; Expected: «$right.perl»");
> }
>
> (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).
I like this idea and with it built into the language itself, there will be
much less of an excuse to skip testing. I like the adverb form, which seems
more perl6 than C. Naming it something like :test is a better idea than :ok
as that seems a bit more direct.
There isn't much in the spec concerning namespaces, other than the default *
namespace. Is there any reason why the testing framework can't go in it's
own namespace?
> * We nearly double the number of built-in operators
> by adding an :ok multi
> * We force implementors to handle operator adverbs
> and named arguments very early in their progress
> (don't know how easy or hard that is)
> * Testing of operators becomes somewhat clumsy. If you
> * want to test infix:<==>, you won't write
> '2 == 2 :ok("== works")', because you test a
> different multi there. Instead you'd have to write
> something like '?(2 == 2) :ok("== works")', where
> :ok is an adverb on prefix:.
>
These are mostly disadvantages to implementors, not users of the testing
framework. I'd rather the implementations struggle to implement a built-in
testing functionality than users of the language struggle to use the
built-in testing.
> I'll send another mail on the subject of pluggable
> testing backends in order to allow different emitters
> (TAP output, storage into databases, whatever)
This is a requirement for me. Having only TAP emitters may not integrate
well. It would be nice if the spec, if added, would allow flexibility in
this realm. I would actually like to see a flexible system that allowed me
to define a new emitter, say for the cases where you want to integrate perl6
testing into an existing testing framework (think automated builds and
tests).
-Jason "s1n" Switzer
Re: design of the Prelude (was Re: Rakudo leaving the Parrot nest)
On Thu, Jan 15, 2009 at 8:59 PM, Jon Lang wrote: > OK, then. If I'm understanding this correctly, the problem being > raised has to do with deciding which language features to treat as > primitives and which ones to bootstrap from those primitives. The > difficulty is that different compilers provide different sets of > primitives; and you're looking for a way to avoid having to write a > whole new Prelude for each compiler. Correct? > > Note my use of the term "language features" in the above. Presumably, > you're going to have to decide on some primitive functions as well as > some primitive datatypes, etc. For instance: before you can use > meta-operators in the Prelude, you're going to have to define them in > terms of some choice of primitive functions - and that choice is > likely to be compiler-specific. So how is that any easier to address > than the matter of defining datatypes? Or is it? Did I miss something here? I've never heard Prelude. I'm not really convinced that each implementation should have a large set of shared code; that seems contrary of the idea of having independent implementations. Having to support a common set of implemented classes like this may end up being more of a burden than a benefit. You may find each implementation replacing parts of the Prelude to serve their needs. It also seems like that Prelude.pm is dated and also very pugs specific, which is ironic. What are all the references to Pugs::Internals and pugs_internals_m:perl5? Is rx:Perl5 and rd:P5 valid perl6? I'm skeptical of the this idea unless someone can convince me otherwise. -Jason "s1n" Switzer
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 6:26 PM, Ovid wrote: > - Original Message > > > From: jason switzer > > > If we wanted language dependent version, use :leading, :trailing, and > :both. > > That will require each implementation properly handle the language > > variations. > > I think :start and :end are my favorites. Huffman++ (maybe :begin and :end > for consistency?). My best advise is to keep it consistant. .chomp makes references to chomping from the end, not the trailing. .substr makes reference to start. I think that's better to just find terminology that has already been agreed upon and keep abusing it.
Re: Not a bug?
On Mon, Jan 12, 2009 at 3:54 PM, Larry Wall wrote:
> On Mon, Jan 12, 2009 at 01:19:12PM -0800, Jon Lang wrote:
> : As well, isn't there a way to escape a character that would otherwise
> : be interpolated? If the intent were as you suppose, the original
> : could be rewritten as:
> :
> : $ perl6 -e 'my $foo = "foo";say "\{" ~ $foo ~ "}"'
>
> Sure, though in any case I'd probably prefer:
>
>$ perl6 -e 'my $foo = "foo"; say Qs/{$foo}/'
>
> : (Or would you need to escape the closing curly brace as well as the
> : opening one?)
>
> Not unless something outside of it all was attempting to count braces.
> But the P6 parser has sworn off all such activities for P6-derived
> code. Parsing something first as a string and then again as some
> other language is generally looked upon as a Bad Plan these days.
>
> Which is, of course, why "{" is a problem now. Perhaps use of nested
> double quotes deserves a warning.
>
masak++ was right, if you use single quotes it works properly. Here's how
you do it from a bash prompt:
$ ./perl6 -e 'my $foo = '\''foo'\''; say '\''{'\'' ~ $foo ~ '\''}'\'' '
{foo}
Notice the overly redundant single-quotes; in fact, all of those quotes are
single quotes.
-Jason "s1n" Switzer
Re: [PATCH] Add .trim method
On Mon, Jan 12, 2009 at 9:07 AM, jesse wrote: > > 'left' and 'right' are probably not the right names for functions which > trim leading and/or trailing space, since their meanings get somewhat > ambiguous if a language renders right-to-left instead of left-to-right > or vice-versa > I'm in favor of using the proposed syntax, but I will agree with lwall that it seems like overkill to have the specialized trims. .trim should be non-destructive and .=trim should be destructive (these seems intuitive). Some languages run in the direction of left-to-right, some in the direction right-to-left (some even top-to-bottom). No matter what language you speak or which direction your native language reads, left is the same for everyone as well as right. If we wanted to simplify matters, use :left, :right and :both. Those have the same meaning everywhere. If we wanted language dependent version, use :leading, :trailing, and :both. That will require each implementation properly handle the language variations. By the way, good work on this. Everyone loves useful string functions. -Jason "s1n" Switzer
Re: r24737 - docs/Perl6/Spec
On Fri, Jan 2, 2009 at 8:12 PM, Geoffrey Broadwell wrote: > On Fri, 2009-01-02 at 12:27 -0800, jerry gay wrote: > > oh, yes, whoops! i responded to someone else in #pugs earlier, and > > forgot to address the item here. C replaces p5's > > C (that's the latest idea from damian, although it seems not > > to be published yet). > > Ah, I get it! What about perldoc's special modes? Will these go in > ++DOC ... ++/DOC sections? Jerry mentioned in IRC that he intends on documenting the metasyntax options more. I'm guessing this is sort of a special meta argument given perldoc's modes, so it should probably be documented there. I would like to raise the question of whether implementations must be required to fully parse/present perldoc or just recognize it's presence. This would allow for POD "fluffers" like pod2html and for streamlined perl6 implementations to skip things like --doc. -Jason "s1n" Switzer
Re: Working with files wish list
On Mon, Dec 15, 2008 at 6:59 PM, Leon Timmermans wrote:
> On Mon, Dec 15, 2008 at 6:42 PM, jason switzer wrote:
> > It's lazy and kinda cheating, but for small simple tasks, it gets the job
> > done. I'm not up to speed with the IO spec, but a sort of auto-slurp
> > functionality would be nice. Something to the effect:
> >
> > @data = :slurp("mydatafile.txt");
>
> A slurp() function has been specced to slurp a file into a string, as
> well as a lines() function that does the same into an array of lines.
>
Okay, that's good to know.
> You didn't get the point of my Roles idea. It should not be added to a
> role File, but to the Role Nameable, which would be composed into
> whatever implements file filehandles, but for example also into Unix
> sockets. IMNSHO interfaces and implementation should be kept separate
> to maintain a proper abstraction level.
>
I hadn't seen a Nameable role mentioned yet, so I wasn't able to understand
any such concept. That is a good idea, but the idea is so general that
anything can be nameable and thus the specificity of the role could quickly
become lost. I was suggesting specific naming functionalities be added to
the File role. If you want to abstract that, that's fine, but beware that
something like Nameable can be too broad of a role (maybe just IONameable?).
> You can already easily mix it in using 'does':
>
> $fstab = open('/etc/fstab', :r);
> $fstab does WhitespaceTrim;
>
> I don't think it's really necessary to include that into open(),
> though it might be useful syntactic sugar.
I haven't spent the time to understand mix-ins yet, but this does look like
a feasible (clean) idea. However, how do you specify one/more filters? For
example, say you want to :rw a file. How can you provide an input filter and
an output filter (or multiples of either)? Can you layer filters if done
with mix-ins? If so, how do you specify direction?
-Jason "s1n" Switzer
Re: Working with files wish list
On Mon, Dec 15, 2008 at 10:43 AM, Richard Hainsworth
wrote:
> 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(:name);
>
> my File $output .=new(:name, :mode);
>
You've essentially replaced the klunky mode parameters in perl5 (">file")
with a cleaner role constructor. I would argue that an autodie built-in
feature would be nice with perl but it may not be a good idea to always
force a die. Maybe it could be a feature/macro that could be turned on (like
'use autodie;').
> and then:
>
> while $file.read {…};
>
> or:
>
> say "Hello world" :to<$output>;
I usually do something more like:
@ARGV = ("file.txt");
@data = <>;
It's lazy and kinda cheating, but for small simple tasks, it gets the job
done. I'm not up to speed with the IO spec, but a sort of auto-slurp
functionality would be nice. Something to the effect:
@data = :slurp("mydatafile.txt");
That's just a crude example and possibly not even valid perl6, but it would
be nice to have a quick read-only file slurping functionality. This is
usually the first thing I hack into larger scripts so that I can forget
about doing IO (means to an end).
In fact, File::Slurp does this right now in perl5.
> 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).
It would actually be nicer if I the filename defaulted to my platform and I
there were naming convention converters provided. I don't know how that
should look and it actually sounds like something that should probably be
provided by modules.
Some of what File::Spec provides now would be nice built in, but how much is
up for debate. I think File::Path::canonpath and File::Path::path would be
nice attributes to add to the File role.
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/ };
I would imagine a filter role would be useful. If they're roles, it allows
people to build layers of functionality on them to do various different
kinds of filters, turn them on and off, etc. With filters as roles, I would
love to imagine something like this:
my File $fstab = new(:name, :filter)
Yet another crude example, but imagine once the whitespace cleaner above
trimmed things down, and output filter could then realign them. I see more
utility if the filter were a role than some $.infilter scalar that can be
clobbered by multi-threaded applications.
> Perhaps, too a module for a specific environment, eg., Windows, would
> provide the syntatic sugar that makes specifying a location look like
> specifying a directory natively, eg.
> use IO::Windows;
> my Location $x .= new(:OSpath);
> whilst for linux it would be
> use IO::Linux;
> my Location $x .=new(:OSpath);
This looks like a good start to the w
Re: Split with negative limits, and other weirdnesses
It makes sense to me to go with option 1; you get what you ask for. It also
makes sense to make to not use magical implied numbers, such as negatives,
to accomplish things that either ranges or whatever star can accomplish.
Just my 2 cents.
-Jason "s1n" Switzer
On Tue, Sep 23, 2008 at 4:27 AM, Moritz Lenz <[EMAIL PROTECTED]>wrote:
> Today a patch to rakudo brought up the question what split() should do
> if the $limit argument is either zero or negative.
>
> In Perl 5 a negative limit means "unlimited", which we don't have to do
> because we have the Whatever star. A limit of 0 is basically ignored.
>
> Here are a few solution I could think of
> 1) A limit of 0 returns the empty list (you want zero items, you get them)
> 2) A limit of 0 fail()s
> 3) non-positive $limit arguments are rejected by the signature (Int
> where { $_ > 0 })
>
