Darren Duncan | 1 Oct 01:42 2010
Picon

Re: [perl6/specs] 58fe2d: [S12] spec setting and getting values of attribute...

Moritz Lenz wrote:
> Darren Duncan wrote:
>> I think then that .perl needs to be updated so it is more expressly limited and 
>> only works on some objects rather than on all of them.
>>
>> The way I see it, .perl is mainly about representing *value* objects in a 
>> serialized form, and what it should produce is a value expression whose 
>> execution results in an object which would eqv the original.
> 
> Are you using "value object" in the same sense as in the Perl 6
> specification?

I'm essentially thinking in terms of the Perl 6 specified "value types" but I 
was actually being a little more general so to also include container objects 
whose current values could change over time; hence I used "eqv" rather than 
"==="; I didn't want the .perl to be more restrictive than necessary.

<snip>
>> Bottom line, if .perl isn't supposed to work on 100% of objects then we should 
>> fix .perl so it doesn't break encapsulation.
> 
> +1. The question is: how?
> 
> My proposal: the default .perl method should only spit out value for
> public attributes, ie those that have accessors. Maybe .new should also
> default to his behavior.

I agree with this proposal, and would be happy for it like Damian.  It would 
mean the langauge has a good, safe, default behavior, which does what people 
expect most of the time or is otherwise simple for users to understand and 
(Continue reading)

Timothy S. Nelson | 1 Oct 01:43 2010
Picon

Re: [perl6/specs] 58fe2d: [S12] spec setting and getting values of attribute...

On Fri, 1 Oct 2010, Damian Conway wrote:

> Jonathan wrote:
>
>> Sounds like the encapsulation breaking thingy probably wants to be looking
>> for some pragma to have been used in the lexical scope of the caller, maybe.
>> I'd rather that we called it something other than MONKEY_TYPING though.
>> Different evil, different pragma. :-)
>
> As long as it's easily searchable and vaguely pejorative (e.g. has the
> work MONKEY in it).
>
> Hmmmmm. You need to use MONKEY_TYPING when you're monkeying with typing,
> so maybe when you're monkeying with what can be seen (and abusing Perl
> 6 as if it were C)
> then you need to use MONKEY_SEE

 	We could even have one for looking at internals (called MONKEY_SEE), 
and one for changing them (MONKEY_DO).

 	:)

---------------------------------------------------------------------
| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wayland <at> wayland.id.au    | I am                           |
---------------------------------------------------------------------

----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
(Continue reading)

Timothy S. Nelson | 1 Oct 01:45 2010
Picon

Re: [perl6/specs] 58fe2d: [S12] spec setting and getting values of attribute...

On Thu, 30 Sep 2010, Damian Conway wrote:

>> And thus C<.get_value> and C<.set_value> are just convenient
>> access points for the same behaviour.
>
> Yes. People are going to shoot themselves in the foot anyway,
> so let's legalize semi-automatic weapons as well.

 	Well, of course!  What are you, a socialist Australian or something? 
Next you'll be telling me you don't even vote Libertarian!

 	:)

 	[Before anyone complains, I'm an Australian too :) ]

---------------------------------------------------------------------
| Name: Tim Nelson                 | Because the Creator is,        |
| E-mail: wayland <at> wayland.id.au    | I am                           |
---------------------------------------------------------------------

----BEGIN GEEK CODE BLOCK----
Version 3.12
GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- 
PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI++++ D G+ e++>++++ h! y-
-----END GEEK CODE BLOCK-----

Brandon S Allbery KF8NH | 1 Oct 06:31 2010
Picon

Re: [perl6/specs] 58fe2d: [S12] spec setting and getting values of attribute...


On 9/30/10 16:46 , Moritz Lenz wrote:
> 1) please don't abuse MONKEY_TYPING for anything that might look like
> dangerous

If Perl 6 is still Perl then in some sense it implies that "dangerous" is
accepted practice.  :)  That said...

> 2) I find .perl very, very valuable in real world debugging; I don't
> want to make it its usage any harder.

I'd suggest slightly different behavior for .perl:  output everything but
with a "..." so people have to do (a little) work to abuse it.  Otherwise,
though, I think I go in the direction of "if this is indeed Perl then
`private' just means `do a little more work to get at it'".  At most,
perhaps .perl would dump only public state unless some debug option were set.

As for serializeability, I think .perl is being used for two different
things and we need to separate them.  If it's there for debugging, you want
private data in some recognizeable form and you want placeholders for things
like filehandles; if for serialization, then private state can only be
exported as the class itself desires (probably as method calls to initialize
it), requiring a class to provide such serialization routine, and things
like filehandles get skipped if the class doesn't provide a serialization
for them (which it usually wouldn't).

(IIRC the point of calling it "perl" was that it was to provide a Perl
expression which would evaluate to the object, hence serialization.  So
maybe we need .debug or .dump that follows different rules?)

(Continue reading)

Brandon S Allbery KF8NH | 1 Oct 06:35 2010
Picon

Re: [perl6/specs] 58fe2d: [S12] spec setting and getting values of attribute...


On 10/1/10 00:31 , Brandon S Allbery KF8NH wrote:
> As for serializeability, I think .perl is being used for two different
> things and we need to separate them.  If it's there for debugging, you want

Addendum, since as I reread my message it looks a little scatterbrained:  if
.perl is for serialization then "..." gets added to an object which can't be
directly serialized due to private data, filehandles, etc.  Dump what we can
and ... the rest, perhaps (so the object could be used as is if it's
accessed lazily and only the dumpable parts are used).

--

-- 
brandon s. allbery     [linux,solaris,freebsd,perl]      allbery <at> kf8nh.com
system administrator  [openafs,heimdal,too many hats]  allbery <at> ece.cmu.edu
electrical and computer engineering, carnegie mellon university      KF8NH
Peter Scott | 1 Oct 08:14 2010

Re: [perl6/specs] 58fe2d: [S12] spec setting and getting values of attribute...

On Thu, 30 Sep 2010 23:40:39 +0200, Jonathan Worthington wrote:
> Plus, we probably do need *some* way for folks to write serializers in
> standard Perl 6.

^ This.

I faced precisely this problem when trying to write persistent inside-out 
classes with Class::Std.  There was no way to break encapsulation, so I 
had to write a serialize method.  The problem was, I needed to be able to 
serialize derived classes, so each of them had to say how to serialize 
themselves.  But serialization was a role - instances of the derived 
classes weren't always persistent - and that violated the separation of 
thingummy (my terminology isn't so good here, I trust you know what I 
mean).

I don't know how you solve this but please think about this use case.  Of 
course not every object can or should be serialized but elective object 
persistence is pretty important.

--

-- 
Peter Scott
http://www.perlmedic.com/     http://www.perldebugged.com/
http://www.informit.com/store/product.aspx?isbn=0137001274
http://www.oreillyschool.com/courses/perl1/

noreply | 6 Oct 19:28 2010

[perl6/specs] cb8c84: [S06] s/tail-recursion/recursion/

Branch: refs/heads/master
Home:   http://github.com/perl6/specs

Commit: cb8c8487fa0ab7156fecffdc8a52bf75d4290c1b
    http://github.com/perl6/specs/commit/cb8c8487fa0ab7156fecffdc8a52bf75d4290c1b
Author: Carl Masak <cmasak <at> gmail.com>
Date:   2010-10-06 (Wed, 06 Oct 2010)

Changed paths:
  M S06-routines.pod

Log Message:
-----------
[S06] s/tail-recursion/recursion/

Because you can use &?ROUTINE calls in a non-tail position (and execution
still carries on afterwards), it's really just normal recursion.

noreply | 11 Oct 20:44 2010

[perl6/specs] dffc82: Specified a little more support for the local time...

Branch: refs/heads/master
Home:   http://github.com/perl6/specs

Commit: dffc82fa6b3ed622fb8eeb787419915e6b9b26b7
    http://github.com/perl6/specs/commit/dffc82fa6b3ed622fb8eeb787419915e6b9b26b7
Author: Kodi Arfer <hippo <at> Thoth.(none)>
Date:   2010-10-11 (Mon, 11 Oct 2010)

Changed paths:
  M S28-special-names.pod
  M S32-setting-library/Temporal.pod

Log Message:
-----------
Specified a little more support for the local time zone, so you don't have to say 'DateTime.now.timezone'.

Ben Goldberg | 11 Oct 00:32 2010
Picon

threads?

Has there been any decision yet over what model(s) of threads perl6
will support?

Will they be POSIX-like? ithread-like? green-thread-like?

It is my hope that more than one model will be supported... something
that would allow the most lightweight threads possible to be used
where possible, and ithread-like behavior for backwards compatibility,
and perhaps something in-between where the lightest threads won't
work, but ithreads are too slow.

If perl6 can statically (at compile time) analyse subroutines and
methods and determine if they're reentrant, then it could
automatically use the lightest weight threads when it knows that the
entry sub won't have side effects or alter global data.

If an otherwise-reentrant subroutine calls other subs which have been
labelled by their authors as thread-safe, then that top subroutine can
also be assumed to be thread-safe.  This would be when the
intermediate weight threads might be used.

If thread-unsafe subroutines are called, then something like ithreads
might be used.

To allow the programmer to force perl6 to use lighter threads than it
would choose by static analysis, he should be able to declare methods,
subs, and blocks to be reentrant or threads safe, even if they don't
look that way to the compiler.  Of course, he would be doing so at his
own risk, but he should be allowed to do it (maybe with a warning).

(Continue reading)

Ben | 10 Oct 22:17 2010
Picon

Re: cb8c84: [S06] s/tail-recursion/recursion/

On Oct 6, 1:28 pm, nore... <at> github.com wrote:
> Branch: refs/heads/master
> Home:  http://github.com/perl6/specs
>
> Commit: cb8c8487fa0ab7156fecffdc8a52bf75d4290c1b
>    http://github.com/perl6/specs/commit/cb8c8487fa0ab7156fecffdc8a52bf75...
> Author: Carl Masak <cma... <at> gmail.com>
> Date:   2010-10-06 (Wed, 06 Oct 2010)
>
> Changed paths:
>   M S06-routines.pod
>
> Log Message:
> -----------
> [S06] s/tail-recursion/recursion/
>
> Because you can use &?ROUTINE calls in a non-tail position (and execution
> still carries on afterwards), it's really just normal recursion.

Shouldn't that also apply to &?BLOCK, too?


Gmane