Re: Functions and subroutines?

> On 12 Sep 2018, at 22:56, Joseph Brenner wrote: > With perl6, I find myself stumbling over what to call the built-ins... > "functions", "commands", "keywords”? perhaps “builtins"? Liz

Re: Functions and subroutines?

) is you can't return from them. They will return >> the last thing evaluated within them though. But a return statement inside >> one raises and Expection. (Might be a Failure)... >> >> On Tue, 11 Sep 2018 at 16:24 yary wrote: >> >>> And looking at questions in other threa

Re: Functions and subroutines?

On 09/11/2018 10:35 AM, Larry Wall wrote: On Tue, Sep 11, 2018 at 03:47:46AM -0700, ToddAndMargo wrote: : In Perl, what is the proper terminology? We're not picky, since Perl has never made a hard and fast distinction between routines that return values and routines that don't. You can call

Re: Functions and subroutines?

wrote: > >> And looking at questions in other threads- there are subroutines declared >> with "sub", those get called without an invocant. >> >> sub i-am-a-sub() { say "Hi from subroutine land!" } >> >> i-am-a-sub; # says "Hi from subroutine land!&quo

Re: Functions and subroutines?

On Tue, Sep 11, 2018 at 03:47:46AM -0700, ToddAndMargo wrote: : In Perl, what is the proper terminology? We're not picky, since Perl has never made a hard and fast distinction between routines that return values and routines that don't. You can call them all functions or routines or procedures

Re: Functions and subroutines?

and Expection. (Might be a Failure)... On Tue, 11 Sep 2018 at 16:24 yary wrote: > And looking at questions in other threads- there are subroutines declared > with "sub", those get called without an invocant. > > sub i-am-a-sub() { say "Hi from subroutine land!" }

Re: Functions and subroutines?

And looking at questions in other threads- there are subroutines declared with "sub", those get called without an invocant. sub i-am-a-sub() { say "Hi from subroutine land!" } i-am-a-sub; # says "Hi from subroutine land!" and methods are declared inside a class, a

Re: Functions and subroutines?

I would call them subroutines, since that's the long form of "sub" -y On Tue, Sep 11, 2018 at 3:47 AM, ToddAndMargo wrote: > Hi All, > > I use subs like ducks use water. It is about time > I learned what to properly call them. > > I come from Modula2 and Pascal (

Functions and subroutines?

Hi All, I use subs like ducks use water. It is about time I learned what to properly call them. I come from Modula2 and Pascal (as well as bash), "functions" return a value outside the declared parameters and "(sub)routines" only can modify values through the declarations parameters. Sort of

Re: [perl #127086] Calling subroutines from CORE fails in BEGIN blocks in loaded modules

I have had this happen too. I think it's actually doing anything that writes to stdout during compile time rather than calling CORE but I could be wrong. On Thu, 31 Dec 2015 at 1:26 AM, Rob Hoelz wrote: > # New Ticket Created by Rob Hoelz > # Please include the

[perl #127086] Calling subroutines from CORE fails in BEGIN blocks in loaded modules

# New Ticket Created by Rob Hoelz # Please include the string: [perl #127086] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=127086 > For example, in test.pl: > use TestModule; in TestModule.pm: > BEGIN say 'hi'; If we

[perl #71112] [BUG] @_ is writeable in subroutines without explicit signature in Rakudo; shouldn't be

On Mon Dec 07 21:36:46 2009, masak wrote: > rakudo: sub foo { @_[0] = "bah" }; my $a = "!"; foo($a); say $a > rakudo 7ef386: !␤ > i'd've expected it to blow up > * masak submits rakudobug > TimToady: so in the default signature, @_ isn't writeable? > no, it's different from P5 in that > ok.

Passing arrays to subroutines

In Perl 5 I can do this: my @a = (1, 2); my @b = (3); foo(@a,@b); sub foo { my $n = @_; die Wrong num args: $n if ($n != 3);} In Perl 6 I think this is correct (or nearly so): sub foo(*@args) { die Wrong num args: { @args.elems } if @args.elems != 3;} Questions for Perl 6: foo is now

Re: Passing arrays to subroutines

On 03/19/2015 04:05 PM, Tom Browder wrote: In Perl 5 I can do this: my @a = (1, 2); my @b = (3); foo(@a,@b); sub foo { my $n = @_; die Wrong num args: $n if ($n != 3);} In Perl 6 I think this is correct (or nearly so): sub foo(*@args) { die Wrong num args: { @args.elems } if @args.elems

Re: Passing arrays to subroutines

On Thu, Mar 19, 2015 at 10:15 AM, Moritz Lenz mor...@faui2k3.org wrote: On 03/19/2015 04:05 PM, Tom Browder wrote: In Perl 5 I can do this: ... 1. How can I combine arrays @a and @b into one array? generally with the comma operator: my @combined = @a, @b; It looks like I can also do

[perl #114428] [BUG] Subroutines created using 'sub ::(some_constant)' get the wrong name in Rakudo

Since this works and is in roast for two years I'm closing the ticket. $ perl6-m -e 'constant name = foo; sub ::(name) () { 42 }; say foo()' 42 $ perl6-m -e 'constant name = foo; say (sub ::(name) () { 42 }).name' foo

[perl #114428] [BUG] Subroutines created using 'sub ::(some_constant)' get the wrong name in Rakudo

# New Ticket Created by Carl Mäsak # Please include the string: [perl #114428] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=114428 moritz r: constant name = 'foo'; sub ::(name) () { 42 }; say foo() p6eval

Re: [perl #112632] our variables or subroutines cannot be called from outside scope

Hi, sorry, I don't have the URL. However, the PDF is included with the Rakudo source. Best regards, Philippe Le 28 avr. 2012 à 13:09, Carl Mäsak via RT a écrit : Thank you for bringing this to our attention. It used to be you could use 'our' like below, but not anymore. Now you

[perl #112632] our variables or subroutines cannot be called from outside scope

# New Ticket Created by Philippe de Rochambeau # Please include the string: [perl #112632] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=112632 Perl6 version: 2012.04.1 { our $truc = 'machin';

[perl #112632] our variables or subroutines cannot be called from outside scope

Thank you for bringing this to our attention. It used to be you could use 'our' like below, but not anymore. Now you must declare a variable in any scope you use it, including 'our' variables. This is a change that happened with the nom refactor. Do you have the URL for the Perl 6 Tutorial? It

[perl #71112] [BUG] @_ is writeable in subroutines without explicit signature in Rakudo; shouldn't be

# New Ticket Created by Carl Mäsak # Please include the string: [perl #71112] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=71112 masak rakudo: sub foo { @_[0] = bah }; my $a = !; foo($a); say $a p6eval rakudo

Re: [perl #69318] [BUG] Subroutines are rw in Rakudo

On Wed, Sep 23, 2009 at 05:10:04AM -0700, Carl Mäsak wrote: masak rakudo: sub foo { say OH HAI }; foo = say; foo Confirmed that this is a bug... it should be fixed when we default PMCs to be readonly instead of requiring a separate readonly flag as we do now. Then the above will result in

[perl #69318] [BUG] Subroutines are rw in Rakudo

# New Ticket Created by Carl Mäsak # Please include the string: [perl #69318] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=69318 masak rakudo: sub foo { say OH HAI }; foo = say; foo p6eval rakudo 0eaf62: OUTPUT«␤»

[perl #69242] Rakudo should check existence of subroutines at CHECK time

# New Ticket Created by Moritz Lenz # Please include the string: [perl #69242] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=69242 18:16 diakopter rakudo: caffeine(eval('sub caffeine($a){say $a}')); 18:16 +p6eval

[perl #60822] [TODO] lexical subroutines

On Tue Jan 20 11:29:48 2009, moritz wrote: Status update: 'my sub name { ... }' is parsed, but it's not lexical: $ ./perl6 -e '{ my sub f { say in f }; f() }; f(); { my sub f { say in second f }; f() }; f()' in f in f in f in f That should die on the second call to f(). And as of git

Meta- and Hyperoperators and Anonymous Subroutines

the fact that one can also easily pass a custom operation. Therefore I think that it would be a nice addition for Perl 6 if the X...X, ... and similar operators could be applied to anonymous subroutines in addition to other operators. If such a syntactic change wasn't possible it would probably

Re: Meta- and Hyperoperators and Anonymous Subroutines

no associativity, I don't see a big advantage in having a reduce-for-functions or map-for-functions operator. Therefore I think that it would be a nice addition for Perl 6 if the X...X, ... and similar operators could be applied to anonymous subroutines in addition to other operators

Re: Meta- and Hyperoperators and Anonymous Subroutines

2009/3/2 Moritz Lenz ml...@physik.uni-wuerzburg.de: Thomas Chust wrote: [...] Therefore I think that it would be a nice addition for Perl 6 if the X...X, ... and similar operators could be applied to anonymous subroutines in addition to other operators. If such a syntactic change wasn't

[perl #60822] [TODO] lexical subroutines

On Tue Nov 25 13:19:15 2008, moritz wrote: Rakudo as of r33193 doesn't implement lexical subroutines; neither 'my sub ...' is implemented nor does 'my $x = sub { ... }' work properly (a test for the latter can be found in t/spec/integration/man-or-boy.t). All of: my $x = sub { ... } my x

[perl #60822] [TODO] lexical subroutines

# New Ticket Created by Moritz Lenz # Please include the string: [perl #60822] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60822 Rakudo as of r33193 doesn't implement lexical subroutines; neither 'my sub

Re: assignable mutators (S06/Lvalue subroutines)

HaloO, David Green wrote: I would expect all of those to work the same way in either case. That is, anywhere the sub is used as an lvalue, it could pass the rvalue as a special arg, not just when using =. I agree. But I want to stress that the big thing is that a lvalue sub---and to a

Re: assignable mutators (S06/Lvalue subroutines)

On 2008-Jun-2, at 3:30 pm, Jon Lang wrote: sub foo($value?) is rw($value) { ... } Or something to that general effect. The parameter in question must be optional and cannot have a default value, so that a test of whether or not the parameter is actually there can be used to determine

RE: assignable mutators (S06/Lvalue subroutines)

If a routine is rw, you may optionally define a single slurpy scalar (e.g., '*$value') in its signature. A good start, but why limit the Lvalue to a scalar? A list l-value seems like a pretty useful thing to me. -Martin

Re: assignable mutators (S06/Lvalue subroutines)

On 2008-Jun-1, at 1:50 pm, Jon Lang wrote: David Green wrote: [...] assignment should work like passing args when used on a function. Then you can easily do whatever you want with it. [...] If a routine is rw, you may optionally define a single slurpy scalar (e.g., '*$value') in its

Re: assignable mutators (S06/Lvalue subroutines)

David Green wrote: Jon Lang wrote: If a routine is rw, you may optionally define a single slurpy scalar (e.g., '*$value') in its signature. This scalar counts as the last positional parameter, much like slurpy arrays and hashes must be declared after all of the positional parameters have

Re: assignable mutators (S06/Lvalue subroutines)

On 2008-May-27, at 9:40 am, Dave Whipp wrote: TSa wrote: method inch { yield $inch = $.mm * 25.4; self.mm = $inch / 25.4; } Would you regard that as elegant? That looks functionally incorrect to my eyes: if the caller resumes at the time of the yield

Re: assignable mutators (S06/Lvalue subroutines)

Jon Lang wrote: This approach could be functionally equivalent to the proxy object approach, but with a potentially more user-friendly interface. That is, sub foo (*$value) { yadda } might be shorthand for something like: sub foo () is rw { return new Proxy: FETCH = method {

Re: assignable mutators (S06/Lvalue subroutines)

David Green wrote: It seems overly complex to me, but perhaps I'm missing good reasons for such an approach. I see lvalue subs mainly as syntactic sugar: foo(42); # arg using normal syntax foo == 42; # arg using feed syntax foo = 42; # arg using assignment

Re: assignable mutators (S06/Lvalue subroutines)

HaloO, Dave Whipp wrote: The sequence I was thing of is: my $obj = Length.new; $obj.mm = 42; say $obj.inch; # your Length.inch method yields $obj.mm = 63; say $obj.inch; # Length.inch to resumes, overwriting $obj.mm back to 42 It seems to me that the assignment within your inch method will

Re: assignable mutators (S06/Lvalue subroutines)

TSa wrote: TSa wrote: class Length { has Num $.mm is rw = 0; method inch { yield $inch = $.mm * 25.4; self.mm = $inch / 25.4; } } Would you regard that as elegant? That looks functionally incorrect to my eyes: if the caller resumes

assignable mutators (S06/Lvalue subroutines)

S06/Lvalue subroutines: Lvalue subroutines return a proxy object that can be assigned to. (...) S13/Methods: Setter methods that expect the new value as an argument do not fall into the well-behaved category, however. When I take these two together, in a way which may be out of context

Re: assignable mutators (S06/Lvalue subroutines)

Brandon Allbery allbery-at-kf8nh.com |Perl 6| wrote: S06/Lvalue subroutines: Lvalue subroutines return a proxy object that can be assigned to. (...) S13/Methods: Setter methods that expect the new value as an argument do not fall into the well-behaved category, however. When I take

[perl #43192] [TODO] Parrot::Configure::Step: Test remaining untested subroutines

Patch applied to trunk in r20879.

Re: [perl #43192] [TODO] Parrot::Configure::Step: Test remaining untested subroutines

On Aug 25, 2007, at 10:47 PM, James Keenan via RT wrote: On Sun Aug 19 08:55:30 2007, coke wrote: This was part of the gmake extensions that we (can) support during makefile-generation time; added because there was there no cross- platform syntax that I knew of that we could use in all of the

Re: [perl #43192] [TODO] Parrot::Configure::Step: Test remaining untested subroutines

Will Coleda wrote: That said, I don't see '$(basename ...)' used anywhere in the code base. The other three (addprefix, wildcard, and notdir), are all used by Tcl (and only by Tcl) I don't see where 'addprefix' or 'notdir' is used outside of where they're defined in

Re: [perl #43192] [TODO] Parrot::Configure::Step: Test remaining untested subroutines

$ ack addprefix | wc -l 2 $ ack -a addprefix | wc -l 3 ack, by default, searches a subset of files. On Aug 20, 2007, at 9:24 PM, James E Keenan wrote: Will Coleda wrote: That said, I don't see '$(basename ...)' used anywhere in the code base. The other three (addprefix, wildcard, and

[perl #43192] [TODO] Parrot::Configure::Step: Test remaining untested subroutines

I have been writing tests for previously untested statements in Parrot::Configure::Step. In genfile(), there is the following block: # documented as removing any .-based suffix if ( $line =~ s{\$ \( basename \s+ ([^)]+) \)}{ join (' ',

Re: [perl #43192] [TODO] Parrot::Configure::Step: Test remaining untested subroutines

This was part of the gmake extensions that we (can) support during makefile-generation time; added because there was there no cross- platform syntax that I knew of that we could use in all of the various makes we have to support. See perldoc lib/Parrot/Configure/Step.pm look for

Fwd: [TODO] Parrot::Configure::Step: Test remaining untested subroutines

tests. Whoever works on this should see whether this subroutine is called anywhere in the lib/ or config/ hierarchies. 2. Branches and conditions in various subroutines: file_checksum (); genfile(); run_command(); cc_build(); cc_run(); cc_run_capture (); check_progs(); slurp(). As with item

[perl #43192] [TODO] Parrot::Configure::Step: Test remaining untested subroutines

in various subroutines: file_checksum(); genfile(); run_command(); cc_build(); cc_run(); cc_run_capture(); check_progs(); slurp(). As with item (1), each subroutine should be checked for current instances of usage during configuration. 3. There has been talk in other RT threads cc_build

Re: 3 subroutines with same name

chromatic wrote: On Tuesday 21 November 2006 18:36, James E Keenan wrote: 3 identically named subroutines: 2 in modules and 1 in a script. And all 3 will be in modules as I'm planning to refactor much of pmc2c.pl into a module called Parrot::Pmc2c::Utils. (For drafts of these revisions

3 subroutines with same name

Note the results: [parrot] 502 $ ack 'sub gen_c' lib/Parrot/Pmc2c.pm 1221:sub gen_c { lib/Parrot/Pmc2c/Library.pm 134:sub gen_c { tools/build/pmc2c.pl 821:sub gen_c { 3 identically named subroutines: 2 in modules and 1 in a script. And all 3 will be in modules as I'm planning to refactor

Re: 3 subroutines with same name

On Tuesday 21 November 2006 18:36, James E Keenan wrote: 3 identically named subroutines: 2 in modules and 1 in a script. And all 3 will be in modules as I'm planning to refactor much of pmc2c.pl into a module called Parrot::Pmc2c::Utils. (For drafts of these revisions, see http

Re: [perl #40564] [TODO] fix perlcritic Subroutines::RequireFinalReturn policy

On Oct 18, 2006, at 4:27 PM, Jerry Gay (via RT) wrote: currently, this policy does not ignore subs which exit or die... it forces the addition of a return statement in these subs. yuck. this policy will be disabled until this is fixed. ~jerry Fixed in Perl::Critic svn r737. This will appear

[perl #40564] [TODO] fix perlcritic Subroutines::RequireFinalReturn policy

# New Ticket Created by Jerry Gay # Please include the string: [perl #40564] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=40564 currently, this policy does not ignore subs which exit or die... it forces the

How do subroutines check types?

Hi, class Foo {...} Foo.new.isa(Foo); # true Foo.isa(Foo); # true (see [1]) Foo.does(Class);# true sub blarb (Foo $foo, $arg) { ...; # Do something with instance $foo } blarb Foo.new(...), ...; # No problem blarb Foo,

Re: How do subroutines check types?

Ingo Blechschmidt wrote: How do I have to annotate the type specification in the declaration of the subroutine to not include the class Foo, but only allow instances of Foo? My understanding is that Foo.does(Foo) is false and sub params are checked with .does(). This automatically excludes

parse problem with subroutines?

that no whitespace is allowed between the function name and the opening paren of the arguments. E6 /Molecules/ states that whitespace is optional. Attached is a test case suitable for pugs (t/subroutines/numcmp.t). david d zuhn [EMAIL PROTECTED]

Re: parse problem with subroutines?

On 5/31/05, david d zuhn [EMAIL PROTECTED] wrote: Running pugs r4158, I find that (some, at least) subroutine calls only work with no whitespace between the sub name and the arguments. $v = numcmp (1,2); # fails with I don't see anywhere in the canon that no whitespace is allowed

Re: parse problem with subroutines?

On 5/31/05, david d zuhn [EMAIL PROTECTED] wrote: this is a pretty fundamental change in perl that ought to be made a bit clearer (it's not in the p5-p6 porting guide, for example). Agreed. I remembered this being discussed by Abigail. Found it here: http://www.perlmonks.org/?node_id=346083

Re: parse problem with subroutines?

$v = numcmp (1,2); # fails with Synopsis 2: Whitespace is not allowed before the parens, but there is a corresponding .() operator, which allows you to insert optional whitespace before the dot. $v = numcmp .(1,2); # should pass The quoted text is in a paragraph describing explicit

Re: parse problem with subroutines?

On 5/31/05, Jonathan Scott Duff [EMAIL PROTECTED] wrote: I didn't really realize that there was a p5-p6 porting guide until I saw this. I'll add something to the guide as above (plus subs). I've already added a bit about method calls, but I'll leave it alone for you to do arrays/hashes. Carl

Re: parse problem with subroutines?

ok, that was quick :) Shall I remove what I'd already added to the bottom of the file? Carl

Re: parse problem with subroutines?

On Tue, May 31, 2005 at 08:05:04AM -0500, david d zuhn wrote: If this is indeed a statement that all function calls, especially the ordinary sort that are used most often, must be of the form a(b) rather than allowing a (b), this is a pretty fundamental change in perl that ought to be made a

Re: BEGIN and lexical variables inside subroutines

On Fri, May 13, 2005 at 04:21:25PM +0200, TSa (Thomas Sandlaß) wrote: : And I hope that it is not possible to accidentially : mess up the internals of the compiler because code : in a BEGIN hits compiler data. Whereas I hope that it *is* possible to intentionally mess up the internals of the

Re: BEGIN and lexical variables inside subroutines

Benjamin Smith wrote: sub foo { my $x; BEGIN { $x = 3 }; say $x } foo; foo; foo; Currently in perl5 and pugs this prints 3\n\n\n. Which to me looks like a mix of runtime and compile time. Actually Dave Mitchell confirmed that this is the case in Perl 5. I have difficulty to regard this as a

BEGIN and lexical variables inside subroutines

sub foo { my $x; BEGIN { $x = 3 }; say $x } foo; foo; foo; Currently in perl5 and pugs this prints 3\n\n\n. Should BEGIN blocks be able to modify values in lexical variables that don't really exist yet? (People can use state after all to get a variable which does exist early enough for them

Re: BEGIN and lexical variables inside subroutines

On Thu, May 12, 2005 at 09:06:48PM +0100, Benjamin Smith wrote: sub foo { my $x; BEGIN { $x = 3 }; say $x } foo; foo; foo; Currently in perl5 and pugs this prints 3\n\n\n. Should BEGIN blocks be able to modify values in lexical variables that don't really exist yet? (People can use

[S06] Types of subroutines/blocks/etc.

Hi, A06 states: Code | | | RoutineBlock |_____|___ | | | || |

[pugs] ?SUB and pointy subroutines

I'm having some trouble using the ?SUB variable in a subroutine declared with the - operator. The following code results in an error about ?SUB being undefined: my $s = - $count { if $count 10 { say $count; ?SUB($count + 1); } }; $s(1); If I change to either a named sub (sub

Re: [pugs] ?SUB and pointy subroutines

Garrett Rooney writes: I'm having some trouble using the ?SUB variable in a subroutine declared with the - operator. The following code results in an error about ?SUB being undefined: my $s = - $count { if $count 10 { say $count; ?SUB($count + 1); } }; $s(1); If I

Re: [pugs] ?SUB and pointy subroutines

Luke Palmer wrote: That's because a pointy sub is not a sub. Perhaps we should call it a pointy block. That might be clearer ;-) Not all code objects are Subs. If you call return, then you return from the innermost enclosing sub, which is marked by that word. Likewise does $?SUB. I don't

Re: [pugs] ?SUB and pointy subroutines

Garrett Rooney writes: Not all code objects are Subs. If you call return, then you return from the innermost enclosing sub, which is marked by that word. Likewise does $?SUB. I don't believe $?BLOCK has been implemented yet, but it will. If that's the case then the Pointy subs section of

Re: IMCC tracing, leaving subroutines

William Coleda [EMAIL PROTECTED] wrote: After the returncc, is it possible to indicate what routine we are returning into? Good idea. Implemented (location printing needs cleanup, so just a current hack). leo

macros outside of subroutines

btw, thanks to whoever fixed macros so that they could be defined outside of .sub's. Very handy.

Re: Still about subroutines...

On Thu, 16 Sep 2004, Jonathan Scott Duff wrote: And FWIW, I kinda like $ even with the over-done :-) me too! Michele -- [...] is like requiring to play tennis with a square ball. Which admittedly makes the game more interesting. - Giuseppe Oblomov Bilotta in comp.text.tex (edited)

Re: Still about subroutines...

On Thu, 16 Sep 2004, Larry Wall wrote: Except that only one of these variables' meanings is actually associated with subs. And I kind of like to read the C? as which. So if we actually make use of our sigils, we get possibilities like this: [snip useful examples] at first I didn't get what you

Re: Still about subroutines...

On Fri, 17 Sep 2004, Larry Wall wrote: with a named abstraction is not terribly useful. The whichness of C? happens subconsciously, whereas having a named hash forces As I said in my other mail, the more I think of this the more it seems to me to be reasonable and even natural. It's which?-ness,

Re: Still about subroutines...

On Tue, Sep 21, 2004 at 11:45:55AM +0200, Michele Dondi wrote: : at first I didn't get what you mean, but now I must admit it does make : sense and looks smart too. I can be very persuasive when I'm right, as well as the rest of the time. :-) Larry

Re: Still about subroutines...

On Fri 17 Sep, Larry Wall wrote: $?fileWhich file am I in? $?lineWhich line am I at? $?package Which package am I in? @?package Which packages am I in? $?module Which module am I in? @?module Which modules am I in? $?class Which class am I in?

Re: Still about subroutines...

Richard Proctor wrote: Maybe there are some more... $?perl Which version of perl am I in $?parrot Which version of parrot is perl running on $?parrot_runloop Which runloop is running ? etc... And relating to the outside world $?os Which operating system am I operating on $?pid

Re: Still about subroutines...

On Thu, Sep 16, 2004 at 10:35:45PM -0700, Larry Wall wrote: Except that only one of these variables' meanings is actually associated with subs. And I kind of like to read the C? as which. So if we actually make use of our sigils, we get possibilities like this: $?fileWhich file am I

Re: Still about subroutines...

On Fri, Sep 17, 2004 at 09:41:37AM -0500, Jonathan Scott Duff wrote: : Maybe I'm just being curmudgeonly, but is this really that useful to : have such shortcuts? I presume that there will be alternate ways to : access the same information (like maybe a special hash : (%*WHICH{'package'} and

Re: Still about subroutines...

On Fri, Sep 17, 2004 at 09:25:08AM +0100, Richard Proctor wrote: : Maybe there are some more... : : $?perlWhich version of perl am I in It would be Which version of Perl am I compiled with? But $?perlversion would much clearer. I suppose the same could be said for $?subname. : And

Re: Still about subroutines...

On Fri, Sep 17, 2004 at 11:59:09AM +0200, Thomas Seiler wrote: : $?parrot Which version of parrot is perl running on $?parrotversion would be which version of parrot we were compiled on. $*parrotversion would be which version of parrot we are running on. : $?parrot_runloop Which runloop

Re: Still about subroutines...

On Fri 17 Sep, Larry Wall wrote: : $?osWhich operating system am I operating on Again, which OS am I compiled on, or at best, which OS does the compiler think I'm compiling for, in the case of cross-compilation. Therefore should: $?os Be which operating system it is being

Re: Still about subroutines...

On Fri, Sep 17, 2004 at 07:35:46PM +0100, Richard Proctor wrote: : Therefore should: : : $?os Be which operating system it is being compiled on : $*os Be which operating system it is being executed on : : Some of the other special variables may have a similar dual personality. Presumably.

Re: Still about subroutines...

Larry Wall wrote: On Fri, Sep 17, 2004 at 07:35:46PM +0100, Richard Proctor wrote: : Therefore should: : : $?os Be which operating system it is being compiled on : $*os Be which operating system it is being executed on : : Some of the other special variables may have a similar dual

Re: Still about subroutines...

On Sep 17, 2004, at 12:06 PM, Larry Wall wrote: I originally made them lowercase because they were $=line variables and I didn't want them to conflict with POD names that are typically uppercase, and use of an C= secondary sigil for POD is a no-brainer. s/uppercase/lowercase/ ? David

Re: Still about subroutines...

On Fri, Sep 17, 2004 at 03:16:24PM -0400, Austin Hastings wrote: : For that matter, what's wrong with $__ as a sigil, as in $__LINE__, et : al. It combines the you can use it as a variable with the leading : underscores are magic memes, and doesn't impose any wierd learning curve. I am unlikely

Re: Still about subroutines...

On Fri, Sep 17, 2004 at 12:19:10PM -0700, David Wheeler wrote: : On Sep 17, 2004, at 12:06 PM, Larry Wall wrote: : : I originally made them lowercase because they were $=line variables : and I didn't want them to conflict with POD names that are typically : uppercase, and use of an C= secondary

Re: Still about subroutines...

On Sep 17, 2004, at 12:21 PM, Larry Wall wrote: No, not the verbs, the uppercase nouns we see like =begin COMMENT ... =end COMMENT Oh, I wasn't sure, because in the Synopses you've been using propercase for =head1 POD. But maybe it's not the subjects of the header and item type verbs

Still about subroutines...

Speaking of subs, and especially recursive ones which have been mentioned en passant earlier, I have another question of mine: I know that in the vast majority of cases this won't be useful in any way, but in the body of a (possibly anonymous) sub/block, will there be some sort of identifier to

Re: Still about subroutines...

Michele Dondi writes: Speaking of subs, and especially recursive ones which have been mentioned en passant earlier, I have another question of mine: I know that in the vast majority of cases this won't be useful in any way, but in the body of a (possibly anonymous) sub/block, will there be

Re: Still about subroutines...

On Thu, Sep 16, 2004 at 10:02:18AM -0600, Luke Palmer wrote: : The new alternative is MY.sub. I suppose that could return the current : actual sub, so if you're using a pointy sub you have to say MY.block or : something. But it's one of those two. Or something resembling them. I'm still pining

Re: Still about subroutines...

On Thu, Sep 16, 2004 at 10:07:29AM -0700, Larry Wall wrote: I like $-, $+, and $? the best. Probably should save $- and $+ for something complimentary, which leaves $?. It's visually distinctive, and recently came available. :-) Speaking of which ... why is it that $?foo and ?foo became

Re: Still about subroutines...

Jonathan Scott Duff skribis 2004-09-16 13:44 (-0500): Speaking of which ... why is it that $?foo and ?foo became $foo and foo respectively? perlcheat is one page. I hope that when Perl 6 is around, I can summarize all uses of and on one page. The second page will be for the rest of the

Re: Still about subroutines...

- Original Message - From: Juerd [EMAIL PROTECTED] Date: Thursday, September 16, 2004 2:55 pm Subject: Re: Still about subroutines... Jonathan Scott Duff skribis 2004-09-16 13:44 (-0500): Speaking of which ... why is it that $?foo and ?foo became $foo and foo respectively

Re: Still about subroutines...

Larry Wall writes: I like $-, $+, and $? the best. Probably should save $- and $+ for something complimentary, which leaves $?. It's visually distinctive, and recently came available. :-) Hmm, $ is pretty good, and it's associated with subs mnemonically, just as $= is associated with lines

Re: Still about subroutines...

On Thu, Sep 16, 2004 at 01:40:47PM -0600, Luke Palmer wrote: : Larry Wall writes: : I like $-, $+, and $? the best. Probably should save $- and $+ for something : complimentary, which leaves $?. It's visually distinctive, and recently : came available. :-) : : Hmm, $ is pretty good, and

  1   2   3   >