Re: [perl6/specs] 761178: remove some some duplicate words words
On Tue, Sep 7, 2010 at 11:29 AM, Moritz Lenz mor...@faui2k3.org 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 wayl...@wayland.id.auwrote: 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, pugs-comm...@feather.perl6.nl 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, nigelsande...@btconnect.com 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 jonat...@jnthn.netwrote: 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 cma...@gmail.com 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 wayl...@wayland.id.auwrote: 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 jswit...@gmail.com 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!divbr/divdivWe are planning on having another Dallas.p6m meeting soon. span style=border-collapse: collapse\; color: r gb(51\, 51\, 51)\;We are meeting next week (Tuesday\, June 9th 7:00PM) at a coffee shop with free wifi. The address isnbsp\;span style=font-famil y: Arial\;985 W Bethany Dr Allen\, TX 75013 (span style=font-family: ar ial\;Pete's Coffee inside the Market Street).span style=font-family: Ar ial\;br/span/span/span/span/div\nspan style=border-collapse : collapse\; color: rgb(51\, 51\, 51)\;divbr/div\ndivspan style= font-family: Arial\;This 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).brbrAlso\, 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.brbr/spanEveryone is invited to come and have a good time. See you there!brbr-Jason s1n Switzerbr/div/span\n\nView your event at http://www.google.com/calendar/event?action=VIEWeid=ZzNyc3Rz NjZhdnNhYWNwODE3bjdyaTFuMmcgcGVybDYtbGFuZ3VhZ2VAcGVybC5vcmctok=MTgjanN3aXR 6ZXJAZ21haWwuY29tNmRiNDU1ODk3YTMyZmI2ZjNlYjY4ZTQwNGQ1YmFiOTExMDgzNzRjYQctz =America%2FChicagohl=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!divbr/divdivWe are planning on having another Dallas.p6m meeting soon. span style=border-collapse: collapse\; color: r gb(51\, 51\, 51)\;We are meeting next week (Tuesday\, June 9th 7:00PM) at a coffee shop with free wifi. The address isnbsp\;span style=font-famil y: Arial\;985 W Bethany Dr Allen\, TX 75013 (span style=font-family: ar ial\;Pete's Coffee inside the Market Street).span style=font-family: Ar ial\;br/span/span/span/span/div\nspan style=border-collapse : collapse\; color: rgb(51\, 51\, 51)\;divbr/div\ndivspan style= font-family: Arial\;This 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).brbrAlso\, 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.brbr/spanEveryone is invited to come and have a good time. See you there!brbr-Jason s1n Switzerbr/div/span\n\nView your event at http://www.google.com/calendar/event?action=VIEWueid=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 datawea...@gmail.com wrote: On Mon, Jun 1, 2009 at 5:44 PM, Daniel Carrera daniel.carr...@theingots.org 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 james.fuller.2...@gmail.comwrote: 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=2hl=enq=kitchen+sink -Jason s1n Switzer
Re: r25490 - docs/Perl6/Spec
On Sun, Feb 22, 2009 at 9:47 PM, pugs-comm...@feather.perl6.nl 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 Thu, Jan 22, 2009 at 4:51 PM, jerry gay jerry@gmail.com wrote:
$x == $y
:ok({ .true ?? 'message' !! 'failure message' })
:diag( 'tap comment', :some_tap_propertysome values)
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 mor...@faui2k3.org 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 datawea...@gmail.com 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 9:07 AM, jesse je...@fsck.com 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: Not a bug?
On Mon, Jan 12, 2009 at 3:54 PM, Larry Wall la...@wall.org 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 6:26 PM, Ovid publiustemp-perl6langua...@yahoo.comwrote: - Original Message From: jason switzer jswit...@gmail.com 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: r24737 - docs/Perl6/Spec
On Fri, Jan 2, 2009 at 8:12 PM, Geoffrey Broadwell ge...@broadwell.orgwrote: 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. Cperl6 --doc replaces p5's Cperldoc (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 10:43 AM, Richard Hainsworth
rich...@rusrating.ruwrote:
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);
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/etc/fstab, :filternew WhitespaceTrim)
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(:OSpathC:\\Documents\perldata\);
whilst for linux it would be
use IO::Linux;
my Location $x .=new(:OSpath/home/perldata/);
This
Re: Working with files wish list
On Mon, Dec 15, 2008 at 6:59 PM, Leon Timmermans faw...@gmail.com wrote:
On Mon, Dec 15, 2008 at 6:42 PM, jason switzer jswit...@gmail.com 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: 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 })
