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 with t

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 that it i

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

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 the use of

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

Re: Idea for making @, %, $ optional

Millsa Erlas wrote: I have thought of an interesting idea that may allow Perl 6 to make the $, @, and % optional on many uses of variables. This involves simply extending the function namespace to include all kinds of structures, and thus the function namespace does not require symbols, they ar

Re: Idea for making @, %, $ optional

Austin Hastings wrote: --- James Mastros <[EMAIL PROTECTED]> wrote: Millsa Erlas wrote: I have thought of an interesting idea that may allow Perl 6 to make the $, @, and % optional on many uses of variables. This involves simply extending the function namespace to include all kinds

Re: Idea for making @, %, $ optional

On 6/3/05, Millsa Erlas <[EMAIL PROTECTED]> wrote: > Does this allow the grammer rules of the language to be changed so that > this could be implemented? How does this work? Yes. In fact, one of the big goals of perl 6 is to allow people to mutate the grammar of the language. If you just want sc

Re: Idea for making @, %, $ optional

--- James Mastros <[EMAIL PROTECTED]> wrote: > Millsa Erlas wrote: > > I have thought of an interesting idea that may allow Perl 6 to make > the > > $, @, and % optional on many uses of variables. This involves > simply > > extending the function namespace to include all kinds of > structures, a

Re: Idea for making @, %, $ optional

James Mastros wrote: Millsa Erlas wrote: I have thought of an interesting idea that may allow Perl 6 to make the $, @, and % optional on many uses of variables. This involves simply extending the function namespace to include all kinds of structures, and thus the function namespace does not req

Re: Idea for making @, %, $ optional

Millsa Erlas wrote: > I have thought of an interesting idea that may allow Perl 6 to make the > $, @, and % optional on many uses of variables. This involves simply > extending the function namespace to include all kinds of structures, and > thus the function namespace does not require symbols, the

Re: Idea

At 11:16 PM -0600 5/23/02, Luke Palmer wrote: > > >The rest of this message assumes that the answer to A is "run time error". >> >> I'm not sure that's correct. Might just be a runtime warning, > >I would assume not. How can we optimize if we just make it a warning? It may be a warning in the s

Re: Idea

On 22 May 2002 at 13:10, Luke Palmer wrote: > Since this is a Perl 6 list, here's how you would do it in Perl 6 (unless > there's a better way): > > sub myint($x) { my $i = int $x; $i == $x ? $x : $i } Shouldn't that be sub myint($x) { my $i = int $x; $i == $x ?? $x :: $i } as ?: operator is

Re: Idea

Luke Palmer <[EMAIL PROTECTED]> writes: >> >The rest of this message assumes that the answer to A is "run time error". >> >> I'm not sure that's correct. Might just be a runtime warning, > > I would assume not. How can we optimize if we just make it a > warning? By only optimizing in the prese

Re: Idea

> >The rest of this message assumes that the answer to A is "run time error". > > I'm not sure that's correct. Might just be a runtime warning, I would assume not. How can we optimize if we just make it a warning?

Re: Idea

At 8:11 PM -0400 5/23/02, Miko O'Sullivan wrote: >From: "Chris Angell" <[EMAIL PROTECTED]> >> I have an idea for the int() function. I think it would be cool if it >> returned false/undefined when the argument passed to it is a >> whole number. > >This is related to something I've been ponderi

Re: Idea

From: "Chris Angell" <[EMAIL PROTECTED]> > I have an idea for the int() function. I think it would be cool if it > returned false/undefined when the argument passed to it is a > whole number. This is related to something I've been pondering about variables and typing. Question A: In Perl6, how

RE: Idea

Luke Palmer: # sub myint($x) { my $i = int $x; $i == $x ? $x : $i } sub myint($x) { int $x // $x } #assuming it returned undef --Brent Dax <[EMAIL PROTECTED]> @roles=map {"Parrot $_"} qw(embedding regexen Configure) blink: Text blinks (alternates between visible and invisible). Conforming use

Re: Idea

On Wed, 22 May 2002, Chris Angell wrote: > Everyone, > > Please correct me if I am emailing the wrong address/list. Thanks. Well, in general, you are mailing the wrong list; however, we do know a lot of perl 5, so you'll get your question answered :) (This is the Perl 6 list, used for discu

Re: Idea

On 5/22/02 11:18 AM, "Michael G Schwern" <[EMAIL PROTECTED]> claimed: > It would be nice to have a way to check if something is an integer better > than the regexes in perlfaq4 I completely agree with this sentiment. In the meantime, if you don't want to worry about the regexes, check out my D

Re: Idea

On Wed, May 22, 2002 at 10:14:17AM -0700, Chris Angell wrote: > I have an idea for the int() function. I think it would be cool if it > returned false/undefined when the argument passed to it is a whole number. > For example: > > int(1) or print "argument passed to int() is something other than

Re: IDEA: lexically scoped subs anyone

On Sat, Sep 30, 2000 at 03:48:07PM +0300, Ariel Scolnicov wrote: > This is done in Lisp, and other functional languages. Lisp lets you > declare mutually recursive objects using the (letrec ...) form. In > Scheme, say: > > (letrec ((even? (lambda (x) (if (= x 0) t (odd? (- x 1) >

Re: IDEA: lexically scoped subs anyone

Simon Cozens <[EMAIL PROTECTED]> writes: > On Fri, Sep 29, 2000 at 04:13:46PM +0100, Piers Cawley wrote: > > Did anyone suggest the following yet? > > package Foo; > > my sub _helper_function { ... } > > Todo: > lexically scoped functions: my sub foo { ... } > the basic conce

Re: IDEA: lexically scoped subs anyone

Dave Storrs wrote: > > On 29 Sep 2000, Piers Cawley wrote:[EMAIL PROTECTED] > > > Is it possible? Advisable? > > I haven't seen it yet, but that doesn't mean it's not in there > somewhere...there's a bunch of RFCs I haven't had time to read. If it > isn't there, it should be. I think

Re: IDEA: lexically scoped subs anyone

On 29 Sep 2000, Piers Cawley wrote: > Is it possible? Advisable? I haven't seen it yet, but that doesn't mean it's not in there somewhere...there's a bunch of RFCs I haven't had time to read. If it isn't there, it should be. I think this is definitely a cool idea.

Re: IDEA: lexically scoped subs anyone

On Fri, Sep 29, 2000 at 04:13:46PM +0100, Piers Cawley wrote: > Did anyone suggest the following yet? > package Foo; > my sub _helper_function { ... } Todo: lexically scoped functions: my sub foo { ... } the basic concept is easy and sound, the difficulties begin with

Re: IDEA: my() extensions and attribute declarations

On Wed, 20 Sep 2000, Nathan Wiger wrote: > Camel-3 shows some interesting hints of what's been proposed for my > declarations: > >my type $var :attribute = $value; > > And we all know that you can use my to declare a group of variables: > >my($x, $y, $z); > > Here's the issues: > >

Re: IDEA: my() extensions and attribute declarations

Piers Cawley wrote: > > By declaring a variable as being one of many types you throw away any > possible compile time optimizations that may be possible (unless you > add the restriction that said types have a common interface...) > > Note that a possible syntax for doing what you want could be:

Re: IDEA: my() extensions and attribute declarations

Nathan Wiger <[EMAIL PROTECTED]> writes: > It seems potentially useful to be able to say: > >my Dog, Cat $fluffy; > > As a way to say "$fluffy can be either a Dog or a Cat". Since variables > are prefixed, anything comma-separated up to the variable is an > alternate class for that variable:

Re: IDEA: my() extensions and attribute declarations

On Wed, 20 Sep 2000, Nathan Wiger wrote: >my int ($x, $y), char $z; # mix classes >my int ($x, $y) :64bit, char $z :long; # and attrs my (int ($x, $y), char $z); my (int ($x, $y) :64bit, char $z :long); -- Bryan C. Warnock ([EMAIL PROTECTED])

Re: Idea: minor %hash changes

In message <[EMAIL PROTECTED]> Nathan Torkington <[EMAIL PROTECTED]> wrote: > Tom Hughes writes: > > I must admit it had never occurred to me that somebody might > > deliberately use keys or values to achieve that, but I guess > > somebody might be relying on it without realising it. >

Re: Idea: minor %hash changes

In message <[EMAIL PROTECTED]> Jerrad Pierce <[EMAIL PROTECTED]> wrote: > >As far as I can tell reset %x currently tries to reset any > >variables which start with either % or x even though no variable > >can start with %... > > ~/perl > ${"%percent"} = "Quoth the raven"; > print ${"%pe

Re: Idea: minor %hash changes

>As far as I can tell reset %x currently tries to reset any >variables which start with either % or x even though no variable >can start with %... ~/perl ${"%percent"} = "Quoth the raven"; print ${"%percent"}, "\n"; reset("%"); print ${"%percent"}, "\n"; Quoth the raven Sure looks like it starts

Re: Idea: minor %hash changes

Tom Hughes writes: > I must admit it had never occurred to me that somebody might > deliberately use keys or values to achieve that, but I guess > somebody might be relying on it without realising it. while (($k,$v) = each %foo) { last if ...; } keys %foo;# reset the iterator w

Re: Idea: minor %hash changes

In message <[EMAIL PROTECTED]> Nathan Torkington <[EMAIL PROTECTED]> wrote: > Resetting an each() should be done in some other way than calling > keys() or values(). Perhaps reset(%hash)? I'm subfond of the current > reset() semantics (symbol table crackheadery + single-match regexp >

Re: Idea: minor %hash changes

>Tom Christiansen writes: >> But %hash->BUCKET_USE() should return what's currently there. >Do you really use this information? Really? I have no objection >to supplying a way to discover it, but this might even be in an >external module rather than built into the language given how rarely >it'

Re: Idea: minor %hash changes

Tom Christiansen writes: > But %hash->BUCKET_USE() should return what's currently there. Do you really use this information? Really? I have no objection to supplying a way to discover it, but this might even be in an external module rather than built into the language given how rarely it's used

Re: Idea: minor %hash changes

>I was against the idea of hash context, but I'd love it if: > foreach ($k,$v) (%hash) { >... > } I'd like for Perl to emit a warning if people try for (%hash) or its aliases. That is, if a foreach loops sole content is a %{...} at compile time, grinch. --tom

Re: Idea: minor %hash changes

>%hash in scalar context should return what scalar(keys(%hash)) >currently does. But %hash->BUCKET_USE() should return what's currently there. And a simple boolean (read: don't care) use shouldn't waste time looking for keys, really, but should be internally optimized to do the current reasonabl