[perl6/specs] bdbe96: Add postfix: to S03
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: bdbe9647f7f6c35ab5ec3e2ed7a9eb302116f1af https://github.com/perl6/specs/commit/bdbe9647f7f6c35ab5ec3e2ed7a9eb302116f1af Author: ShimmerFairy <rnd...@gmail.com> Date: 2015-09-18 (Fri, 18 Sep 2015) Changed paths: M S03-operators.pod Log Message: --- Add postfix: to S03 It wasn't mentioned at all before, and since it's at the methodcall level in rakudo, which may not be expected at first, I figured it was worth mentioning. It also makes postfix: the only operator at that level to not start with a dot, which seems like another noteworthy detail.
[perl6/specs] 392d90: [S03] remove postfix parsing constraint
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 392d9057181e96512391891e7ed5a0f7bbe28354 https://github.com/perl6/specs/commit/392d9057181e96512391891e7ed5a0f7bbe28354 Author: Moritz Lenz mor...@faui2k3.org Date: 2012-04-09 (Mon, 09 Apr 2012) Changed paths: M S03-operators.pod Log Message: --- [S03] remove postfix parsing constraint
[perl6/specs] 28401e: [S03] update to current parsing reality (postfix a...
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 28401eef20b2882989e5fe0740ce9ebce8b19360 https://github.com/perl6/specs/commit/28401eef20b2882989e5fe0740ce9ebce8b19360 Author: Moritz Lenz mor...@faui2k3.org Date: 2012-04-09 (Mon, 09 Apr 2012) Changed paths: M S03-operators.pod Log Message: --- [S03] update to current parsing reality (postfix after listop)
Re: postfix and postcircumfix
HaloO, Larry Wall wrote: It's also possible I'm just nuts, and slice context should be a purely run-time activity. Reading your explanation of array slice context I missed an answer to the question how the shape of an array is split into the contexts of functions called inside .[]. I guess the statement @array[foo;bar] breaks down into the following steps: 1) get $slice = @array.shape 2) call foo with $slice as context 3) augment $slice with whatever foo returned 4) call bar with the new $slice context 5) finalize $slice 6) call @array[$slice] The case with variables instead of functions is easier since fetching the variable's content is not interested in context, right? But then I don't understand why $foo = **; $bar = 1; @b = @array[$foo;$bar]; shouldn't slice @array in all dimensions except the last, such that @b.shape.elems == @array.shape.elems - 1. Regards, TSa. -- The Angel of Geometry and the Devil of Algebra fight for the soul of any mathematical being. -- Attributed to Hermann Weyl
Re: postfix and postcircumfix
Larry Wall larry-at-wall.org |Perl 6| wrote: I only mean that you can't simply rewrite $foo.($bar) as $foo.postcircumfix:( ).($bar) and think you've gotten anywhere, since you'd then have to rewrite it again: $foo.postcircumfix:( ).postcircumfix:( ).($bar) $foo.postcircumfix:( ).postcircumfix:( ).postcircumfix:( ).($bar) ... Something has to recognize it as a special form. You lost me. Why does it apply operator(), er, postcircumfix:( ) multiple times on successive return results? Well, it's possible the subscript itself isn't the magical part there. At minimum, the semilist rule probably needs to recognize @@ and ** at the top level (or @@ and ** need to recognize that they're at the top level of a context that wants them to interpolate multiple dimensions rather than just one). It's also possible that even this amount of syntactic magic is evil, but I'd like [1;**;3] to know it has an arbitrary number of dimensions, while [1;$two;3] should know that it has exactly three dimensions even if $two happens to contain ** or @@. Your previous description of handing * in array subscripting explained that it was done at run-time. From that earlier discussion, nothing in the parsing of the text between the brackets interacts with the declared properties of the array. So, in slice context 1;$two;3 will contain 3 lists. Even without slice context, a scalar variable like $two never interpolates but adds a single value to the list (so it is writ). So when postcircumfix:[ ] looks at its argument at runtime, it would see [ [1], [**], [3] ], assuming I'm writing that correctly. What $two happens to contain should not matter, or you've lot a lot more revising to do. It's also possible I'm just nuts, and slice context should be a purely run-time activity. That doesn't mean that the standard postcircumfix[ ] should be defined to handle what it sees as ** inside one of its arguments. Perhaps it should use the cardinality of its argument (a list of lists) as an indication of what it should do, and then if it finds something in one of those sublists that is not a list of indexes, it is an error. That means if you wanted to compose the number of dimensions at run-time, you would have to explicitly use a construct that did the proper amount of flattening, e.g. [1; @@ $two; 3]. --John
Re: postfix and postcircumfix
On Apr 6, 2008, at 12:07 , John M. Dlugosz wrote: Larry Wall larry-at-wall.org |Perl 6| wrote: and think you've gotten anywhere, since you'd then have to rewrite it again: $foo.postcircumfix:( ).postcircumfix:( ).($bar) $foo.postcircumfix:( ).postcircumfix:( ).postcircumfix:( ) .($bar) ... Something has to recognize it as a special form. You lost me. Why does it apply operator(), er, postcircumfix:( ) multiple times on successive return results? You've rewritten a method call... into a method call. Point being that treating postcircumfix tokens as method calls doesn't work when the postcircumfix token *indicates* a method call; that has to be primitive. Put another way, method call syntax is postcircumfix for lexing/syntax, but extending that to semantic analysis won't work. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH
Re: postfix and postcircumfix
Larry Wall larry-at-wall.org |Perl 6| wrote: On Wed, Apr 02, 2008 at 06:08:55PM -0700, Jon Lang wrote: : In Question on your last change to S02, Larry Wall wrote: : (By the way, you'll note the utility of being able to talk about a : postfix by saying .[], which is one of the reasons we allow the optional : dot there. :) : : Can I take this as an indication that the rules for postcircumfix : operators are an extension of the rules for postfix operators? Yes, postcircumfixes are just strange postfixes, syntactically speaking. Semantically they may do strange things such as behave more like macros than operators, of course. Certainly .() is highly magical that way, and maybe subscripts too. Larry Magical how? I take it that the macro-like behavior is in how the circumscribed text is parsed, and once that has been collected, it behaves just like a function call to a function named postcircumfix:( ) etc.? And if I create a function named postcircumfix:[ ] (or one of the others), I get the _same_ magic as normally applied to subscripts? If it's a matter of defining the argument as @@ (for subscripts) or Capture (for function-call syntax), that's not magic. --John
Re: postfix and postcircumfix
On Sat, Apr 05, 2008 at 01:41:02PM -0500, John M. Dlugosz wrote: Larry Wall larry-at-wall.org |Perl 6| wrote: On Wed, Apr 02, 2008 at 06:08:55PM -0700, Jon Lang wrote: : In Question on your last change to S02, Larry Wall wrote: : (By the way, you'll note the utility of being able to talk about a : postfix by saying .[], which is one of the reasons we allow the optional : dot there. :) : : Can I take this as an indication that the rules for postcircumfix : operators are an extension of the rules for postfix operators? Yes, postcircumfixes are just strange postfixes, syntactically speaking. Semantically they may do strange things such as behave more like macros than operators, of course. Certainly .() is highly magical that way, and maybe subscripts too. Larry Magical how? I only mean that you can't simply rewrite $foo.($bar) as $foo.postcircumfix:( ).($bar) and think you've gotten anywhere, since you'd then have to rewrite it again: $foo.postcircumfix:( ).postcircumfix:( ).($bar) $foo.postcircumfix:( ).postcircumfix:( ).postcircumfix:( ).($bar) ... Something has to recognize it as a special form. I take it that the macro-like behavior is in how the circumscribed text is parsed, and once that has been collected, it behaves just like a function call to a function named postcircumfix:( ) etc.? And if I create a function named postcircumfix:[ ] (or one of the others), I get the _same_ magic as normally applied to subscripts? If it's a matter of defining the argument as @@ (for subscripts) or Capture (for function-call syntax), that's not magic. Well, it's possible the subscript itself isn't the magical part there. At minimum, the semilist rule probably needs to recognize @@ and ** at the top level (or @@ and ** need to recognize that they're at the top level of a context that wants them to interpolate multiple dimensions rather than just one). It's also possible that even this amount of syntactic magic is evil, but I'd like [1;**;3] to know it has an arbitrary number of dimensions, while [1;$two;3] should know that it has exactly three dimensions even if $two happens to contain ** or @@. It's also possible I'm just nuts, and slice context should be a purely run-time activity. Larry
Re: postfix and postcircumfix
On Wed, Apr 02, 2008 at 06:08:55PM -0700, Jon Lang wrote: : In Question on your last change to S02, Larry Wall wrote: : (By the way, you'll note the utility of being able to talk about a : postfix by saying .[], which is one of the reasons we allow the optional : dot there. :) : : Can I take this as an indication that the rules for postcircumfix : operators are an extension of the rules for postfix operators? Yes, postcircumfixes are just strange postfixes, syntactically speaking. Semantically they may do strange things such as behave more like macros than operators, of course. Certainly .() is highly magical that way, and maybe subscripts too. Larry
the 'postfix:::' operator
that's postfix ::, as mentioned in the Names section of S02. snip There is no longer any special package hash such as %Foo::. Just subscript the package object itself as a hash object, the key of which is the variable name, including any sigil. The package object can be derived from a type name by use of the :: postfix operator: MyType::$foo snip i don't see it anywhere in S03. probably should be, if it indeed exists, method postfix. ~jerry
S09: Single typo postfix ...
There is a typo in S09 (patch included) Also, S09 uses postfix ... to mean ..Inf but S03 uses ..* for this, so one of these should likely be changed unless both are OK. -- Markus Laire patch-S09 Description: Binary data
prefix-postfix [was Re: NaN semantics]
U mean something like 'term' (or how this thing is called 'bareword' ? )
So I can say :
# $x = 10k;
my sub operator:number is postfix(k) ($num) {
return $num * 1000
}
# $x = 10K;
my sub operator:number is postfix(K) ($num) {
return $num * 1024
}
#u can say later print $x if $x?; :)
my sub operator:var is postfix:(?) ($var) {
$num 10 ?? 1 :: 0;
}
my sub operator:sub is prefix:(U) () {
uc @params
}
very oversimplified of course... It become funny :) isn't it...
=
iVAN
[EMAIL PROTECTED]
=
| On Wed, Oct 10, 2001 at 05:21:02PM +0200, raptor wrote:
| | So the imaginary numbers would be standard literals? Like
| |
| | $x=2+10i;
| |
| | Great idea, as well as sqrt(-1) returning 1i istead of raising the
| | exception. BTW, I was thinking once that numeral literals like 4k or
10G
| | (meaning 4*2**10, 10*2**30) would be very nice. What do you think?
|
| I like the idea ... this is one of the ways to suspend the calculations
to
| the last moment...
| But one probelm comes to my mind, what the k,G etc mean
| 1000 or 1024
| or k = 1000, K = 1024
|
| Or probably the best way will be to have a hook so that we can specify
what
| is a Number and how it has to be calculated down to the real
number...!!!
|
| How about we let users define their own postfix operators such that
| they can make 10K, 10M, 10G mean whatever they want. Perhaps this is
| also where the postfix ? and ! from Ruby can come in.
|
| I'd still advocate supporting imaginary numbers in core somehow
| though. With a pragma would be best I think so that exceptions are
| thrown on sqrt(-1) unless they really want imaginaries.
Re: prefix-postfix [was Re: NaN semantics]
On Wed, Oct 10, 2001 at 06:28:42PM +0200, raptorVD wrote:
U mean something like 'term' (or how this thing is called 'bareword' ? )
So I can say :
# $x = 10k;
my sub operator:number is postfix(k) ($num) {
return $num * 1000
}
I think that would be
sub operator:K is postfix prec(\operator:-($)) ($num) {
return $num * 1000;
}
but yeah, that's the idea. And it would live in a module so that
users would have to do
use BinaryMetric; # or some such
to get it.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Postfix !
If postfix ! was up for grabs - which it probably isn't - what would
you do with it?
One interesting suggestion was to have it as a shorthand for assertion:
sub foo {
(@_ 0)!;
...
}
(Or even have ! be a valid statement terminator, so (@_0)! would work.)
Or you could have it doing something to variables: $a = $b! + $c;
(But what?)
Fun, eh?
--
The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offence.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
Re: Postfix !
On Mon, 23 Apr 2001 13:22:54 +0100, Simon Cozens [EMAIL PROTECTED] wrote:
If postfix ! was up for grabs - which it probably isn't - what would
you do with it?
One interesting suggestion was to have it as a shorthand for assertion:
sub foo {
(@_ 0)!;
...
}
(Or even have ! be a valid statement terminator, so (@_0)! would work.)
Or you could have it doing something to variables: $a = $b! + $c;
(But what?)
Fun, eh?
DWIM would be faculty
--
H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 623 on HP-UX 10.20 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro WinCE 2.11 often with Tk800.022 /| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: Postfix !
On Mon, 23 Apr 2001 14:57:50 +0200, Davíð Helgason [EMAIL PROTECTED] wrote:
H.Merijn Brand wrote:
On Mon, 23 Apr 2001 13:22:54 +0100, Simon Cozens [EMAIL PROTECTED] wrote:
If postfix ! was up for grabs - which it probably isn't - what would
you do with it?
One interesting suggestion was to have it as a shorthand for assertion:
sub foo {
(@_ 0)!;
...
}
(Or even have ! be a valid statement terminator, so (@_0)! would work.)
Or you could have it doing something to variables: $a = $b! + $c;
(But what?)
Fun, eh?
DWIM would be faculty
yeah, but kinda useless unless when teaching (with) perl.
What about assert (and having just written that, I notice that is
exactly what Cozens suggested So it must be a good idea)?
I like it.
When do we get to use unicode operators? (inverse question and
exclamation marks!!!)
joking
I'd personally like to see the plusminus, both as operator and as leading
parameter mark ;-P
if ($a ± $b) { ±c = 1; }
meaning if $a is near to $b (almost the same being defined by $±)
/joking
--
H.Merijn BrandAmsterdam Perl Mongers (http://www.amsterdam.pm.org/)
using perl-5.6.1, 5.7.1 623 on HP-UX 10.20 11.00, AIX 4.2, AIX 4.3,
WinNT 4, Win2K pro WinCE 2.11 often with Tk800.022 /| DBD-Unify
ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: Postfix !
Simon Cozens wrote: If postfix ! was up for grabs - which it probably isn't - what would you do with it? If it wasn't the factorial operator, our math caucus would be rather unhappy... -- John Porter
Re: Postfix !
On Mon, Apr 23, 2001 at 10:47:26AM -0400, John Porter wrote: If it wasn't the factorial operator, our math caucus would be rather unhappy... Good, good. :) $$y = \pi + 4 x $$, Just another Perl and \TeX\ hacker; -- Momomoto, Famous Japanese, can swallow his nose.
