[perl6/specs] eccde7: Reword requirem,ents for idea submitions

v6d.pod Log Message: --- Reword requirem,ents for idea submitions

[perl6/specs] 6d75e2: Remove the idea of negative codepoints

: M S15-unicode.pod Log Message: --- Remove the idea of negative codepoints

[perl6/specs] 6b22f9: Don't give people the wrong idea :-)

: M S03-operators.pod Log Message: --- Don't give people the wrong idea :-) File tests are primarily for paths, *not* for handles

Re: sql idea

Darren (>): > (I apologize if > this isn't correct Perl 6, and I'm not sure how to specify a hash slice that > returns pairs rather than just values): Ask, and it shall be given you (by S02): %hash = (:a, :b); %hash; # returns 'A', 'B', Nil %hash :p;# returns a => 'A', b =>

Re: sql idea

Oha wrote: Hi, I was thinking how to abuse the p6 grammar to simplify the interface to SQL DBs. - First i wanted to have a SELECT which works like a map. - Then i wanted to use a pointy block to bind fields to variables. - And i wanted also to make it lazy. Ah, you have touched on a matter

sql idea

Hi, I was thinking how to abuse the p6 grammar to simplify the interface to SQL DBs. - First i wanted to have a SELECT which works like a map. - Then i wanted to use a pointy block to bind fields to variables. - And i wanted also to make it lazy. I come up to the following code: my $d

Re: Idea: Literate programing

On Tue, 26 May 2009, Daniel Carrera wrote: Carl Mäsak wrote: In this way, a relatively simple change makes Perl 6 Pod able to do literate programing for anyone who is interested. What do you think? That it sounds like a good idea for a sublanguage-extending module. I'm not familiar

Re: Idea: Literate programing

I think the equivalent of tangle/weave would take docs designed for literate reading and produce the runable file. Perl doesn't have to execute it directly. But that can be automated using a source filter. Daniel Carrera daniel.carrera-at-theingots.org |Perl 6| wrote: Hello, I really like P

Re: Idea: Literate programing

On Mon, May 25, 2009 at 2:13 PM, Daniel Carrera wrote: > In this way, a relatively simple change makes Perl 6 Pod able to do literate > programing for anyone who is interested. > > What do you think? The main literate programming feature that's missing from POD is the ability to scramble the orde

Re: Idea: Literate programing

Carl Mäsak wrote: In this way, a relatively simple change makes Perl 6 Pod able to do literate programing for anyone who is interested. What do you think? That it sounds like a good idea for a sublanguage-extending module. I'm not familiar with those. Are they hard to make? I guess th

Re: Idea: Literate programing

Daniel (>): > [...] > > In this way, a relatively simple change makes Perl 6 Pod able to do literate > programing for anyone who is interested. > > What do you think? That it sounds like a good idea for a sublanguage-extending module. // Carl

Idea: Literate programing

Hello, I really like POD and I like the changes in the upcoming Perl 6 Pod. Have you ever heard of literate programing? (see Wikipedia). I think it would be neat if Pod could do literate programing. It is already very close. For reference, please see this article: For reference, please see

Btw, I think these logo discussions have just proved the bikeshedding idea :)

- | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK C

Re: 6PAN idea

... > (Debian)", I agree that doing the best for Debian is a bad idea, but I don't think that's the intended in S22 or in the notes I wrote. But some concepts indeed come from the experience Debian has in managing such a diverse universe. > Do realize that getting things instal

Re: 6PAN idea

ons frustrated by those choices. Would you change your own structure when the distribution builder changes its ideas? Like SuSE already did three times? The only healthy path is to organize your own data (especially the meta-data) as cleanly as possible, prepared for your own future extension pl

Re: 6PAN idea

On Wed, 17 Dec 2008, Daniel Ruoso wrote: It also allows one source package to generate different binary packages (for instance, having scripts, libs and docs splitted), and makes it easier to do an uninstall, because a "binary"/"installable" package would have a fixed list of files. I agree o

Re: 6PAN idea

package to generate different binary packages > (for instance, having scripts, libs and docs splitted), and makes it > easier to do an uninstall, because a "binary"/"installable" package > would have a fixed list of files. > > One thing that is mostly aligned, is

Re: 6PAN idea

llable" package repository for that specific OS/version. It also allows one source package to generate different binary packages (for instance, having scripts, libs and docs splitted), and makes it easier to do an uninstall, because a "binary"/"installable" package would have a

Re: 6PAN idea

On Wed, 17 Dec 2008, Daniel Ruoso wrote: Em Qua, 2008-12-17 às 15:00 +1100, Timothy S. Nelson escreveu: My basic assumption is that there's going to be some kind of packaging system written around 6PAN. Please take a look in some notes I've written some time ago: http://www.perlfounda

Re: 6PAN idea

Em Qua, 2008-12-17 às 15:00 +1100, Timothy S. Nelson escreveu: > My basic assumption is that there's going to be some kind of packaging > system written around 6PAN. Please take a look in some notes I've written some time ago: http://www.perlfoundation.org/perl6/index.cgi?DistributionFormat

Re: 6PAN idea

model isn't CPAN-specific, but relying on such a setup would save work for everyone. Thoughts? You might want to look at "alien" first, to get an idea of what can be done --- and what can't. Good idea. Just to clarify some things: - The packa

Re: 6PAN idea

such a setup would save work for everyone. Thoughts? You might want to look at "alien" first, to get an idea of what can be done --- and what can't. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too

6PAN idea

Hi all. I've been working on some stuff that's vaguely, tangentially CPAN-related. My basic assumption is that there's going to be some kind of packaging system written around 6PAN. One thing I've been working on recently is a (Perl 5) object that models package metadata. In theory, it

Re: Project idea: Perl 6 syntax hilighting with STD.pm

John M. Dlugosz wrote: > Does that mean there is a tool I can use to apply STD.pm to syntax-check > my examples or ask questions of it? Can you point to that? in the pugs repository: $ cd src/perl6 $ make $ ./tryfile $filename That assumes a perl 5.10 in /usr/local/bin/perl HTH, Moritz -- Mo

Re: Project idea: Perl 6 syntax hilighting with STD.pm

Does that mean there is a tool I can use to apply STD.pm to syntax-check my examples or ask questions of it? Can you point to that? --John Moritz Lenz wrote: Since now STD.pm parses most Perl 6 code now, and spits out a parse tree in YAML, a brave soul might want to write a syntax hilighter

RE: Idea: infer types of constants

>-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of Mark J. Reed >Sent: Monday, April 14, 2008 2:05 PM >To: Jonathan Worthington >Cc: David Green; Perl6 >Subject: Re: Idea: infer types of constants > >On Mon, Apr 14

Re: Idea: infer types of constants

TSa wrote: Jonathan Worthington wrote: Miller, Hugh wrote: Was that private communication or on another mailing list? It was also sent to perl6-language, through I was on the To or Cc line too, so I guess that's how I got it but the list, somehow, didn't. Not sure why the original message I r

Re: Idea: infer types of constants

Miller, Hugh wrote: What about the type support (system) one sees in ML ? (e.g., the way it assigns automatically types can be assigned, does not require specific types when they are not needed, flags incompatibilities, etc.) Do those things not fit well with Perl's approaches and aims ? They

Re: Idea: infer types of constants

HaloO, Jonathan Worthington wrote: Miller, Hugh wrote: Was that private communication or on another mailing list? What is the type of $b? Well, we can't actually infer that because foo might be: sub foo() { $OUTER::a = "oh hi, i iz not int!" } That should be $CALLER::a because $OUTER

Re: Idea: infer types of constants

HaloO, John M. Dlugosz wrote: Then the declaration my ::T $x = whatever; should use the exact same generic mechanism! At worst, it needs I would expect that this works by binding ::T to the type of whatever. my Any ::T $x = whatever; Any here is optional. and it will introduce th

Re: Idea: infer types of constants

Mark J. Reed markjreed-at-mail.com |Perl 6| wrote: On Mon, Apr 14, 2008 at 2:32 PM, Jonathan Worthington my Dog $fifi .= new(); # works in Rakudo too ;-) And even in Pugs! :) Doesn't help with literals, though, e.g. my Float $approx_pi = 3.14; So the idea of marking th

Re: Idea: infir types of constants

To me the foo looks like a template sub and I wonder how it is instanciated with different types. Since type parameters are provided with [] it should be foo[Int], foo[Str] and the like. I wonder further if that could also be written foo of Str like with Array of Int etc. my foo of Int &intfo

Re: Idea: infer types of constants

On Mon, Apr 14, 2008 at 2:32 PM, Jonathan Worthington > my Dog $fifi .= new(); # works in Rakudo too ;-) And even in Pugs! :) Doesn't help with literals, though, e.g. my Float $approx_pi = 3.14; -- Mark J. Reed <[EMAIL PROTECTED]>

Re: Idea: infer types of constants

Mark J. Reed wrote: I don't care for the use of * there, but it would be nice to have some way to declare the variable to have the type implied by its initializer, where the complier can tell what that is, so you could remove the redundancy in this: my Dog $fido = new Dog(); while still allowin

Re: Idea: infer types of constants

I don't care for the use of * there, but it would be nice to have some way to declare the variable to have the type implied by its initializer, where the complier can tell what that is, so you could remove the redundancy in this: my Dog $fido = new Dog(); while still allowing the var declared via

Re: Idea: infer types of constants

On 2008-Apr-13, at 4:07 am, John M. Dlugosz wrote: I'm thinking that 'constant' is more special than other variables, and that the formal description of strong typing and static types should say that the compiler =will= implicitly get the type for $pi rather than making it Any. Except if c

Re: Idea: infir types of constants

HaloO, Brandon S. Allbery KF8NH wrote: our ::T sub foo (T $a, T $b) without needing to introduce a new twigil syntax for type variables. My reading as well. But I would write it sub foo (::T $a, T $b --> T) for better indicating that ::T is taken from the parameters. (Although I would won

Re: Idea: infir types of constants

On Apr 13, 2008, at 2:02 , John M. Dlugosz wrote: In Perl 6, I think you would have to arrange to write the return type later rather than sooner to do this: sub foo (::T $a, T $b) is of T and writing it the other way around would violate the one-pass parsing. Just from looking at thi

Re: Idea: infir types of constants

I'm thinking that if strong typing is enabled, mixing untyped and typed things will cause warnings or errors that need not be there. I'm thinking that 'constant' is more special than other variables, and that the formal description of strong typing and static types should say that the compiler

Re: Idea: infir types of constants

John M. Dlugosz wrote: > Just surfing, I noticed something about the "D" programming language: > > " > The types of constants need not be specified explicitly as the compiler > infers their types from > the right-hand sides of assignments. > > const

Idea: infir types of constants

right, or leaving it off and not having compile-time checking and optimization for subsequent use of $x ? Here's an idea: a pseudo-type of the form ::?RHSTYPE. I could even capture it for subsequent use, like with generic type parameters: my ::?RHSTYPE ::ProdType $x = $a ⊗ $b; my ProdType $y = $x; --John

Re: pluralization idea that keeps bugging me

On Sun, Feb 10, 2008 at 12:56:14PM +0300, Richard Hainsworth wrote: > 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 infi

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

Re: pluralization idea that keeps bugging me

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

Re: pluralization idea that keeps bugging me

Hi, Warnocked! Indeed :) 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

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

Re: pluralization idea that keeps bugging me

e easily use his own language (which is what the majority of perl programs do, since most of them are written for private use). As I suggested in a previous mail, we can do it by making say/print a bit smarter. Instead of interpolating before they are called, we let them interpolat

Re: pluralization idea that keeps bugging me

quot;;# 3 boves erant > > Although calling it "\s" loses its impact in other languages But > I think the underlying idea to seize on is a way to grab interpolated > values so that there's a nice way to do tricks like that. Preferably > in a way that

Re: pluralization idea that keeps bugging me

e::Lingua::EN; say "There was\s {3} ox\s";# There were 3 oxen use Locale::Lingua::Romana::Perligata; say "{3} bos\s erat\s";# 3 boves erant Although calling it "\s" loses its impact in other languages But I think the underlying idea to se

Re: pluralization idea that keeps bugging me

On 26 Jan., 17:58, [EMAIL PROTECTED] (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 o

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

Re: pluralization idea that keeps bugging me

of last YAPC::EU, I called for localization of error messages in Perl 5.12, but Perl6 improvements are welcomed as well. My idea: Recently, I released Log::Report, which is a new translation framework. It combines exception-handling with report dispatch and translations. What's new: some modu

Re: pluralization idea that keeps bugging me

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 thin

Re: pluralization idea that keeps bugging me

On Sat, Jan 26, 2008 at 18:43:50 -0800, Jonathan Lang wrote: > Right. One last question: is this (i.e., extending a string's > grammar) a "keep simple things simple" thing, or a "keep difficult > things doable" thing? I'm going to guess somewhere in between. It should be about the same level of

Re: pluralization idea that keeps bugging me

Yuval Kogman wrote: > You can subclass the grammar and change everything. > > Theoretically that's a "yes" =) Right. One last question: is this (i.e., extending a string's grammar) a "keep simple things simple" thing, or a "keep difficult things doable" thing? -- Jonathan "Dataweaver" Lang

Re: pluralization idea that keeps bugging me

On Sat, Jan 26, 2008 at 18:12:17 -0800, Jonathan Lang wrote: > This _does_ appear to be something more suitable for a Locale:: > module. I just wonder if there are enough hooks in the core to allow > for an appropriately brief syntax to be introduced in a module: can > one roll one's own string "

Re: pluralization idea that keeps bugging me

On Sat, Jan 26, 2008 at 08:58:43AM -0800, 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. > > Any other cute ide

Re: pluralization idea that keeps bugging me

Gianni Ceccarelli wrote: > Please don't put this in the language. The problem is harder than it > seems (there are European languages that pluralize differently on $X % > 10, IIRC; 0 is singular or plural depending on the language, etc etc). -snip- > I know Perl is not "minimal", but sometimes I

Re: pluralization idea that keeps bugging me

On Sat, Jan 26, 2008 at 02:36:32PM -0800, chromatic wrote: > > Nearly pain-free l10n and i18n *is* kind of a killer feature though. +1 > -- c > --

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

Re: pluralization idea that keeps bugging me

On 2008-01-26 Larry Wall <[EMAIL PROTECTED]> wrote: > Last night I got a message entitled: "yum: 1 Updates Available". > [snip a lot] > 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 diction

Re: pluralization idea that keeps bugging me

On Sat, Jan 26, 2008 at 08:58:43AM -0800, Larry Wall 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' }." > > My first thought

Re: pluralization idea that keeps bugging me

At 8:58 AM -0800 1/26/08, Larry Wall wrote: 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." I don't think that a feature like this should be in the core language; it is too complicated as well as an open-

Re: pluralization idea that keeps bugging me

On Saturday 26 January 2008 08:58:43 Larry Wall wrote: > 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" That makes me wish for a subju

Re: pluralization idea that keeps bugging me

To me this sounds like use Lingua::EN::Pluralize::DSL; which would overload your grammar locally to parse strings this way. However, due to i18n reasons this should not be in the core. It might make sense to ship a slightly modernized Locale::MakeText with Perl 6 so that it can be used

Re: pluralization idea that keeps bugging me

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

Re: pluralization idea that keeps bugging me

"Jonathan Lang" schreef: > I'm not fond of the 'ox\soxen' idea; but I could get behind something > like '\s' or 'ox\s'. "$n ox\s< en>" "$n\s cat\s< s > fight\s< s s>" ;) -- Affijn, Ruud "Gewoon is een tijger."

Re: pluralization idea that keeps bugging me

ideas? If you have '\s', you'll also want '\S': "$n cat\s fight\S" # 1 cat fights; 2 cats fight I'm not fond of the 'ox\soxen' idea; but I could get behind something like '\s' or 'ox\s'. '\s' would mean 'a

Re: pluralization idea that keeps bugging me

Larry Wall wrote: > Any other cute ideas? If you have '\s', you'll also want '\S': "$n cat\s fight\S" # 1 cat fights; 2 cats fight I'm not fond of the 'ox\soxen' idea; but I could get behind something like '\s' or 'ox\s'.

Re: pluralization idea that keeps bugging me

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 id

pluralization idea that keeps bugging me

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 pl

Re: Another dotty idea

comment > #« This is a comment » This is a much better idea, disconnected from the question of putting spaces in method calls. It's particularly nice if you say the magic words "multi-line comment." (Please, spare me the hand-wringing about pod.) I'll even pay you

Re: Another dotty idea

On Tue, Apr 11, 2006 at 01:21:32PM +1200, Sam Vilain wrote: : Larry Wall wrote: : : >: But this fragment dies: : >: : >: #sub foo : >: #{ : >: # bar { } unless baz : >: #} : >I don't see how that's different at all from the first example. : > : > : : “#sub foo” is parsed as a comment toke

Re: Another dotty idea

Damian Conway wrote: Larry wrote: > I really prefer the form where .#() looks like a no-op method > call, and can provide the visual dot for a postfix extender. It > also is somewhat less likely to happen by accident the #., I > think. And I think the front-end shape of .# is more > recognizab

Re: Another dotty idea

Larry Wall wrote: >: But this fragment dies: >: >: #sub foo >: #{ >: # bar { } unless baz >: #} >I don't see how that's different at all from the first example. > > “#sub foo” is parsed as a comment token “#{ # bar { }” is the next comment token then we get “unless baz” Unless you are b

Re: Another dotty idea

On 4/10/06 9:11 PM, Larry Wall wrote: > I think commenting out code with # is sufficiently antisocial that > you should probably do it with . What's antisocial about it? What's the alternative for quickly commenting out a few lines? Braced #[ ... ]# pairs are not as easy to "mindlessly"

Re: Another dotty idea

On Mon, Apr 10, 2006 at 08:46:02PM -0400, John Siracusa wrote: : Do you care that it's harder to visually pick out the commented-out portions : of a file at a glance using that syntax? I really don't want to give up : s/^/#/ commenting. Double ##s seem like overkill to me. Then I have to use : t

Re: Another dotty idea

>: #} : > : >Well, actually, that still works. : > : > : : Oh, true :-) : : But this fragment dies: : : #sub foo : #{ : # bar { } unless baz : #} : : : Unless you consider the idea of balancing the {}'s inside the comment, : which I think would be just plain nasty. I

Re: Another dotty idea

ut this fragment dies: #sub foo #{ # bar { } unless baz #} Unless you consider the idea of balancing the {}'s inside the comment, which I think would be just plain nasty. The #* .. *# form actually has a natural follow-on I didn't think of before: #[ This i

Re: Another dotty idea

On 4/10/06 8:38 PM, Larry Wall wrote: > Even better is: > > =begin UNUSED > sub foo > { > if foo { } > } > =end UNUSED > > And I don't really care if that's not what people are used to. > The whole point of Perl 6 is to change How Things Work. Do you care that it's hard

Re: Another dotty idea

On Tue, Apr 11, 2006 at 12:26:13PM +1200, Sam Vilain wrote: : This does mean that if you comment out blocks with s/^/#/, you mess up on: : : #sub foo : #{ : # if foo { } : #} Well, actually, that still works. To be certain though, you could always use s/^/##/ or s/^/# /. Even better is: =

Re: Another dotty idea

Damian Conway wrote: >I'm not enamoured of the .# I must confess. Nor of the #. either. I wonder >whether we need the dot at all. Or, indeed, the full power of arbitrary >delimiters after the octothorpe. > > Agreed. >What if we restricted the delimiters to the five types of balanced brackets

Re: Another dotty idea

At 08:38 -0400 8/4/06, John Siracusa wrote: On 4/8/06 6:29 AM, Damian Conway wrote: I'm not enamoured of the .# I must confess. Nor of the #. either. Thank goodness...I was beginning to think it was only me! For the record, I agree with both of you, and that your proposed alternatives are

Re: Another dotty idea

On 4/8/06 6:29 AM, Damian Conway wrote: > I'm not enamoured of the .# I must confess. Nor of the #. either. Thank goodness...I was beginning to think it was only me! > Though, frankly, every one of the alternatives proposed so far is so ugly that > I seriously doubt that anyone will actually want

Re: Another dotty idea

Larry wrote: I really prefer the form where .#() looks like a no-op method call, and can provide the visual dot for a postfix extender. It also is somewhat less likely to happen by accident the #., I think. And I think the front-end shape of .# is more recognizable as different from #, while #

Re: Another dotty idea

Larry Wall wrote: > It's only a problem when some tries to write > > .=#( ... :-) [tries to grok the meaning of "$foo.=#(Hello, World!)"] [fails] > : All true. But it avoids the headache of figuring out whether "..#" is > : supposed to parse as a double-dot followed by a line-gobbling commen

Re: Another dotty idea

On Fri, Apr 07, 2006 at 08:11:04PM -0700, Jonathan Lang wrote: : Larry Wall wrote: : > I really prefer the form where .#() looks like a no-op method call, : > and can provide the visual dot for a postfix extender. : : Although inline and multiline comments are very likely to be used in : situation

Re: Another dotty idea

Larry Wall wrote: > I really prefer the form where .#() looks like a no-op method call, > and can provide the visual dot for a postfix extender. Although inline and multiline comments are very likely to be used in situations where method calls simply aren't appropriate: .#(+---+ | Hello! |

Re: Another dotty idea

On Fri, Apr 07, 2006 at 06:31:44PM -0700, Jonathan Lang wrote: : Delimiter-terminated quotes. Really nice idea. : : I'd put the dot inside the comment: "#.x", with x being an optional : quote delimiter (excluding dots). If a delimiter is included, the : comment is terminated

Re: Another dotty idea

On Fri, Apr 07, 2006 at 07:00:29PM -0700, Jonathan Lang wrote: > Patrick R. Michaud wrote: > > Jonathan wrote: > > > If a delimiter is included, the > > > comment is terminated by the matching quote delimiter; if absent, the > > > comment is terminated by the next dot. > > > > But if one is going t

Re: Another dotty idea

> "LW" == Larry Wall <[EMAIL PROTECTED]> writes: LW> Okay, after attempting and failing to take a nap, I think I know LW> what's bugging me about "long dot". It seems just a little too LW> specific. does this mean you are at the dawning of your dot.age? i couldn't resist! :) uri -

Re: Another dotty idea

Patrick R. Michaud wrote: > But if one is going to go this route (and I'm not sure that we should), > then when the delimiter is absent have the comment terminate at > the first non-whitespace character. ...which makes "#.\s" good only for inserting whitespace where it normally wouldn't belong. O

Re: Another dotty idea

On Fri, Apr 07, 2006 at 06:31:44PM -0700, Jonathan Lang wrote: > Delimiter-terminated quotes. Really nice idea. > > I'd put the dot inside the comment: "#.x", with x being an optional > quote delimiter (excluding dots). If a delimiter is included, the > comment

Re: Another dotty idea

Delimiter-terminated quotes. Really nice idea. I'd put the dot inside the comment: "#.x", with x being an optional quote delimiter (excluding dots). If a delimiter is included, the comment is terminated by the matching quote delimiter; if absent, the comment is terminated by the

Another dotty idea

the dots real. Unfortunately that limits its use as a general embedded comment. So maybe the trailing delimiter is wrong. Here's anther idea: let people pick a delimiter: $x.#( comment ).() $x.#[ comment ].() That would give us .#[...] as the general embedded comment form, and

Re: An idea for doing pack.

On Thu, 28 Jul 2005 15:46:14 +0300, Yuval Kogman <[EMAIL PROTECTED]> wrote: [...] > I like your Pack object - that is the parsed template, but I'd also > like to be able to generate these templates with a programmatic > interface that isn't string concatenation... > > Is it just a simple data st

Re: An idea for doing pack.

I have a fundamental disagreement with what pack used to be - it's too stringish... =) the printf and unpack syntaxes always bothered me because they are akin to 'eval'ing, more than they are to quasi quoting. I like your Pack object - that is the parsed template, but I'd also like to be able to

An idea for doing pack.

Last night I had an idea about a possable pack API. Most likely when Pugs gets signifigently powerfull I will attempt to implement it. However I would like everyones input, below is a draft of its POD. =head1 NAME Pack - (un)pack structures as defined by a Template =head1 SYNOPSIS my Pack

Object Creation (was: Submethods (+ suggestion/proposal/idea))

y, and the default Object::new just happens to call .bless. : =begin RANT/SUGGESTION : : While I like the idea of infastructural methods, I think maybe we : should place more restrictions on them. Ideally the object model itself : would create a set of these "interfaces". One for creation :

Re: Submethods (+ suggestion/proposal/idea)

RANT/SUGGESTION : : While I like the idea of infastructural methods, I think maybe we : should place more restrictions on them. Ideally the object model itself : would create a set of these "interfaces". One for creation : (BUILD/BUILDALL) and for destruction (DESTROY/DESTROYALL), and m

  1   2   >