Re: r29976 - docs/Perl6/Spec
commitbot (), Brandon ():
+ has $!age is ref; # BUILD will automatically use ref binding, not copy
Perl6 isn't done until it has reinvented Algol 68?
Unaware of what Algol 68 represents in programming language history, I
perused Wikipedia's article on Algol 68:
http://en.wikipedia.org/wiki/ALGOL_68 (]):
] ALGOL 68 has been criticized, [...] for abandoning the simplicity of
] ALGOL 60 [and instead] becoming a vehicle for complex or overly
] general ideas, and doing little to make the compiler writer's task easy,
] [...]
I wish I knew how to follow up that with something witty, but it would
seem the quote more than speaks for itself.
But instead of fruitlessly agreeing or disagreeing with a value
judgement, let me try to summarize the discussion on-channel that led
up to this particular spec change.
When you initialize an Int attribute with an Int, you get that Int put
inside the attribute container.
$ perl6 -e 'class A { has Int $.foo }; say A.new(:foo(42)).foo'42
Similarly, when you initialize a Hash attribute with a Hash, you get
that Hash put inside the attribute container.
$ perl6 -e 'class A { has %.foo }; say A.new(:foo(bar = 42)).foo.perl'
{bar = 42}
$ perl6 -e 'class A { has %.foo }; say A.new(:foo{bar = 42}).foo.perl'
{bar = 42}
*However*, according to the way the old spec did things, and according
to current Rakudo alpha and Rakudo master, when you initialize an
Array attribute with an Array, you get that Array put inside *another*
Array inside the attribute container.
$ perl6 -e 'class A { has @.foo }; say A.new(:foo[1,2,3]).foo.perl'
[[1, 2, 3]]
(The reason for this has to do with attribute initialization having
ordinary assignment semantics, meaning that internally it translates
to something like `...@!foo = [1, 2, 3];`, which would indeed place the
[1, 2, 3] array as the first element in @!foo rather than make that
the whole array. Hashes don't suffer from this problem because `%!foo
= { bar = 42};` does the right thing and assigns the hash to %!foo.)
The discussion, starting at [1] and continuing at [2] and [3], mostly
consisted of me repeating the same question until the above
unintuitive quirk went away. It should now just create one layer of
Array upon initialization.
[1] http://irclog.perlgeek.de/perl6/2010-03-06#i_2070655
[2] http://irclog.perlgeek.de/perl6/2010-03-07#i_2073494
[3] http://irclog.perlgeek.de/perl6/2010-03-07#i_2073717
I'm not sure what exactly the repercussions of doing attribute
initialization with 'is ref' are apart from that. Brandon, if your
oblique reference to Algol 68 meant something more than what I
uncovered above, feel free to enrich the discussion by sharing what
you know about the possible consequences of spec'ing things this way.
Now if you'll excuse me, I'll go back to doing little to make the
compiler writers' task easy. :-P
// Carl
Re: r29976 - docs/Perl6/Spec
I imagine Brandon was more referring to pass-by-reference, which was
introduced into procedural HLLs by Algol-68.
On Monday, March 8, 2010, Carl Mäsak cma...@gmail.com wrote:
commitbot (), Brandon ():
+ has $!age is ref; # BUILD will automatically use ref binding, not
copy
Perl6 isn't done until it has reinvented Algol 68?
Unaware of what Algol 68 represents in programming language history, I
perused Wikipedia's article on Algol 68:
http://en.wikipedia.org/wiki/ALGOL_68 (]):
] ALGOL 68 has been criticized, [...] for abandoning the simplicity of
] ALGOL 60 [and instead] becoming a vehicle for complex or overly
] general ideas, and doing little to make the compiler writer's task easy,
] [...]
I wish I knew how to follow up that with something witty, but it would
seem the quote more than speaks for itself.
But instead of fruitlessly agreeing or disagreeing with a value
judgement, let me try to summarize the discussion on-channel that led
up to this particular spec change.
When you initialize an Int attribute with an Int, you get that Int put
inside the attribute container.
$ perl6 -e 'class A { has Int $.foo }; say A.new(:foo(42)).foo'42
Similarly, when you initialize a Hash attribute with a Hash, you get
that Hash put inside the attribute container.
$ perl6 -e 'class A { has %.foo }; say A.new(:foo(bar = 42)).foo.perl'
{bar = 42}
$ perl6 -e 'class A { has %.foo }; say A.new(:foo{bar = 42}).foo.perl'
{bar = 42}
*However*, according to the way the old spec did things, and according
to current Rakudo alpha and Rakudo master, when you initialize an
Array attribute with an Array, you get that Array put inside *another*
Array inside the attribute container.
$ perl6 -e 'class A { has @.foo }; say A.new(:foo[1,2,3]).foo.perl'
[[1, 2, 3]]
(The reason for this has to do with attribute initialization having
ordinary assignment semantics, meaning that internally it translates
to something like `...@!foo = [1, 2, 3];`, which would indeed place the
[1, 2, 3] array as the first element in @!foo rather than make that
the whole array. Hashes don't suffer from this problem because `%!foo
= { bar = 42};` does the right thing and assigns the hash to %!foo.)
The discussion, starting at [1] and continuing at [2] and [3], mostly
consisted of me repeating the same question until the above
unintuitive quirk went away. It should now just create one layer of
Array upon initialization.
[1] http://irclog.perlgeek.de/perl6/2010-03-06#i_2070655
[2] http://irclog.perlgeek.de/perl6/2010-03-07#i_2073494
[3] http://irclog.perlgeek.de/perl6/2010-03-07#i_2073717
I'm not sure what exactly the repercussions of doing attribute
initialization with 'is ref' are apart from that. Brandon, if your
oblique reference to Algol 68 meant something more than what I
uncovered above, feel free to enrich the discussion by sharing what
you know about the possible consequences of spec'ing things this way.
Now if you'll excuse me, I'll go back to doing little to make the
compiler writers' task easy. :-P
// Carl
--
Mark J. Reed markjr...@gmail.com
Re: r29976 - docs/Perl6/Spec
commitbot (), Brandon (), Mark (), Carl (): + has $!age is ref; # BUILD will automatically use ref binding, not copy Perl6 isn't done until it has reinvented Algol 68? [...] I'm not sure what exactly the repercussions of doing attribute initialization with 'is ref' are apart from that. Brandon, if your oblique reference to Algol 68 meant something more than what I uncovered above, feel free to enrich the discussion by sharing what you know about the possible consequences of spec'ing things this way. I imagine Brandon was more referring to pass-by-reference, which was introduced into procedural HLLs by Algol-68. Oh! It was that simple. Going back and doing ack on the spec, I see that this actually constitutes the only mention of 'is ref'. My confusion possibly stems from the fact that we (IIRC) used to have a param trait with this name. Anyway, the change is still pretty fresh, and we'll see if it survives. In the meantime, feel free to point out why passing by reference is a bad idea, and why getting double layers of array in the attributes would be a lesser evil. Meanwhile, the uncanny similarities between Perl 6 and Algol 68 continue to strike me: http://en.wikipedia.org/wiki/ALGOL_68 (]): ] ALGOL 68 [...] was conceived as a successor to the ALGOL 60 programming ] language, designed with the goal of a much wider scope of application and more ] rigorously defined syntax and semantics. // Carl
built-in roles/types routine boundary
Starting with the context of this piece of Synopsis 2: These types do (at least) the following roles: Class Roles = = Str Stringy Bit Numeric Boolean Integral Int Numeric Integral Num Numeric Real Rat Numeric Real Rational FatRat Numeric Real Rational Complex Numeric BoolBoolean snip So I'm wondering how the existing and anticipated built-in routines/operators/methods/etc are supposed to stratify between all these layers of roles and composing classes. Looking at Synopsis 32 seems to provide some answers, although it looks rather outdated in some respects, I think predating the above table. For example, since you've got the Numeric role, which is composed by integers, including routines that aren't closed over integers such as log, then what routines are left that are just for Integral or Real or Rational? Or actually, there is just one main thing I want to know right now ... You have roles that look like they're supposed to match one specific class each in particular, such as Boolean for Bool, Integral for Int, etc, ostensibly in case users want to declare their own classes like them. So, would Int actually have any of its own methods, or would they *all* be provided by Integral? Likewise with Bool and Boolean? And so on. -- Darren Duncan
Re: built-in roles/types routine boundary
On Mon, Mar 8, 2010 at 12:40 PM, Darren Duncan dar...@darrenduncan.net wrote:
Starting with the context of this piece of Synopsis 2:
These types do (at least) the following roles:
Class Roles
= =
Str Stringy
Bit Numeric Boolean Integral
Int Numeric Integral
Num Numeric Real
Rat Numeric Real Rational
FatRat Numeric Real Rational
Complex Numeric
Bool Boolean
snip
So I'm wondering how the existing and anticipated built-in
routines/operators/methods/etc are supposed to stratify between all these
layers of roles and composing classes.
Looking at Synopsis 32 seems to provide some answers, although it looks
rather outdated in some respects, I think predating the above table.
For example, since you've got the Numeric role, which is composed by
integers, including routines that aren't closed over integers such as log,
then what routines are left that are just for Integral or Real or Rational?
For Integral? There might be remainder-based routines, a concept
which only exists for integer math. Also, such things as greatest
common factor, or even just factors. But these are all just
extensions of the same basic principle: Division is not closed over
integers; but instead of banning integer division because the result
won't always be an integer, we instead allow it with a best match
approximation when the result isn't Integral, and add routines that
let us determine which numbers will produce Integrals (e.g., factors),
or that produce some sort of Integral representation of the rounding
error (e.g., remainders).
Similar routines could theoretically exist for Rationals and Reals: if
I raise Rational $x to the power of Rational $y, will the result be
Rational? If not, what's the nearest Rational value to $x where the
result _will_ be Rational? Such routines are not as standard for
Rational and Real as they are for Integral (and thus probably aren't
suitable for implementation in the Perl library); but the principle
remains.
As well, all three of Real, Rational, and Integral have a set of
operations that Numeric lacks: the comparison operators. Note that
Complex does Numeric; but there is no before or after for Complex,
so there cannot be a before or after for Numeric. I believe that
infix:«before after cmp are supplied by Ordered? (I could be wrong
about that.) Whatever it's called, infix:«('', '=', '', '=',
'=') are defined in Real, Rational, and Integral, but not in Numeric
or Ordered. Likewise, Stringy defines infix:«lt le gt ge leg, but
Ordered does not.
Or actually, there is just one main thing I want to know right now ...
You have roles that look like they're supposed to match one specific class
each in particular, such as Boolean for Bool, Integral for Int, etc,
ostensibly in case users want to declare their own classes like them.
So, would Int actually have any of its own methods, or would they *all* be
provided by Integral? Likewise with Bool and Boolean? And so on.
My expectation is that all of Int's methods are supplied by Integral;
all of Bool's methods are supplied by Boolean; all of Complex's
methods are supplied by Numeric; all of Num's methods are supplied by
Real; all of Rat's and FatRat's methods are supplied by Rational; and
all of Str's methods are supplied by Stringy. Conversely, Bit's
methods are supplied by both Integral and Boolean.
Mind you, this is only in terms of which methods must the class
implement? - which, ultimately, is what role composition is all
about. FatRat implements the Rational methods differently than Rat
does, and Bit might implement the Boolean methods differently than
Bool does. I expect that Stringy, Integral, and Real supply the
appropriate default implementations for Str, Int, and Num,
respectively. Rational might be a parametric role, with the default
implementations handed to Rat and FatRat differing only in terms of
which data types they work on; but I could be wrong about this. I
expect that Boolean supplies the default implementations for Bool, and
I suspect that those implementations _might_ be similar enough to what
Bit needs that they can be used there, too. OTOH, I expect that
Numeric does not provide the default implementations that are used by
Complex.
--
Jonathan Dataweaver Lang
Re: r29976 - docs/Perl6/Spec
On Mar 8, 2010, at 06:23 , Carl Mäsak wrote: commitbot (), Brandon (): +has $!age is ref; # BUILD will automatically use ref binding, not copy Perl6 isn't done until it has reinvented Algol 68? Unaware of what Algol 68 represents in programming language history, I perused Wikipedia's article on Algol 68: Actually, I was riffing on the 'is ref' stuff, since Algol68 did some interesting things with the ref keyword (and the way the language report described it was somewhat less than clear). And as such, it was a joke gone awry. (And as to it being complex, I'm tempted to invoke PL/I. It's less complex than most people think; it was just described *really poorly*.) Chew on this article instead of Wikipedia: http://www.cowlark.com/2009-11-15-go/ http://en.wikipedia.org/wiki/ALGOL_68 (]): ] ALGOL 68 has been criticized, [...] for abandoning the simplicity of ] ALGOL 60 [and instead] becoming a vehicle for complex or overly ] general ideas, and doing little to make the compiler writer's task easy, ] [...] The former sounds like the whining of a Scheme user; the latter, a holdover from ancient times. (What would the folks who complained about it not making compiler writers' lives easy have said about C++?) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
Re: r29976 - docs/Perl6/Spec
On Mar 8, 2010, at 11:04 , Carl Mäsak wrote: commitbot (), Brandon (), Mark (), Carl (): +has $!age is ref; # BUILD will automatically use ref binding, not copy Perl6 isn't done until it has reinvented Algol 68? [...] I'm not sure what exactly the repercussions of doing attribute initialization with 'is ref' are apart from that. Brandon, if your oblique reference to Algol 68 meant something more than what I uncovered above, feel free to enrich the discussion by sharing what you know about the possible consequences of spec'ing things this way. I imagine Brandon was more referring to pass-by-reference, which was introduced into procedural HLLs by Algol-68. Oh! It was that simple. Right. And just a joke, not a complaint about the language. Meanwhile, the uncanny similarities between Perl 6 and Algol 68 continue to strike me: And *that* is why I'm cracking Algol 68 jokes here. :) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part
