[Raku/old-design-docs]

2020-02-05 Thread Elizabeth Mattijsen
  Branch: refs/heads/design-into-raku
  Home:   https://github.com/Raku/old-design-docs


[perl6/specs] 6390a5: Move the design documents into the Raku era

2019-11-16 Thread Elizabeth Mattijsen
  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 6390a500201b5c26512940b0920cd6e9e5111abf
  
https://github.com/perl6/specs/commit/6390a500201b5c26512940b0920cd6e9e5111abf
  Author: Elizabeth Mattijsen 
  Date:   2019-11-16 (Sat, 16 Nov 2019)

  Changed paths:
M S01-overview.pod
M S02-bits.pod
M S03-operators.pod
M S04-control.pod
M S05-regex.pod
M S06-routines.pod
M S07-lists.pod
M S08-capture.pod
M S09-data.pod
M S10-packages.pod
M S11-modules.pod
M S12-objects.pod
M S13-overloading.pod
M S14-roles-and-parametric-types.pod
M S15-unicode.pod
M S16-io.pod
M S17-concurrency.pod
M S19-commandline.pod
M S21-calling-foreign-code.pod
M S22-package-format.pod
M S24-testing.pod
M S26-documentation.pod
M S28-special-names.pod
M S29-functions.pod
M S31-pragmatic-modules.pod
M S32-setting-library/Basics.pod
M S32-setting-library/Containers.pod
M S32-setting-library/Exception.pod
M S32-setting-library/IO.pod
M S32-setting-library/Numeric.pod
M S32-setting-library/Rules.pod
M S32-setting-library/Str.pod
M S32-setting-library/Temporal.pod
M S99-glossary.pod
M html/index.html
M html/perl-with-historical-message.css
M html/style.css

  Log Message:
  ---
  Move the design documents into the Raku era

This goes beyond just replacing "Perl 6" with "Raku", and "Perl 5" by "Perl".
Clearly, many of the oldes documents still assumed that Raku was going to be
another version of "Perl", hence the word "Perl" was often used without any
digit following it.  I have tried to deduce the meaning from the context and
either changed these to "Raku" (looking towards the future), or left them to
be "Perl" (when looking to the past).

I've also done this as Raku hopefully will get some more eyeballs looking at
it, and how it got designed / conceived.  Having a mix of "Perl", "Perl 5"
and "Perl 6" in there, will only cause more confusion.  Which we do *NOT*
want to have.

Errors may have been made in this editorial process.  So please do not assume
this is canon in any way!  If you think something is wrong, let us know or
even better, provide a Pull Request!

Thank you for reading this!


[perl6/specs] 3d62b9: Move the design documents into the Raku era

2019-11-16 Thread Elizabeth Mattijsen
  Branch: refs/heads/design-into-raku
  Home:   https://github.com/perl6/specs
  Commit: 3d62b9ea86f586612d5df9ea9460a12239b6ccf2
  
https://github.com/perl6/specs/commit/3d62b9ea86f586612d5df9ea9460a12239b6ccf2
  Author: Elizabeth Mattijsen 
  Date:   2019-11-16 (Sat, 16 Nov 2019)

  Changed paths:
M S01-overview.pod
M S02-bits.pod
M S03-operators.pod
M S04-control.pod
M S05-regex.pod
M S06-routines.pod
M S07-lists.pod
M S08-capture.pod
M S09-data.pod
M S10-packages.pod
M S11-modules.pod
M S12-objects.pod
M S13-overloading.pod
M S14-roles-and-parametric-types.pod
M S15-unicode.pod
M S16-io.pod
M S17-concurrency.pod
M S19-commandline.pod
M S21-calling-foreign-code.pod
M S22-package-format.pod
M S24-testing.pod
M S26-documentation.pod
M S28-special-names.pod
M S29-functions.pod
M S31-pragmatic-modules.pod
M S32-setting-library/Basics.pod
M S32-setting-library/Containers.pod
M S32-setting-library/Exception.pod
M S32-setting-library/IO.pod
M S32-setting-library/Numeric.pod
M S32-setting-library/Rules.pod
M S32-setting-library/Str.pod
M S32-setting-library/Temporal.pod
M S99-glossary.pod
M html/index.html
M html/perl-with-historical-message.css
M html/style.css

  Log Message:
  ---
  Move the design documents into the Raku era

This goes beyond just replacing "Perl 6" with "Raku", and "Perl 5" by "Perl".
Clearly, many of the oldes documents still assumed that Raku was going to be
another version of "Perl", hence the word "Perl" was often used without any
digit following it.  I have tried to deduce the meaning from the context and
either changed these to "Raku" (looking towards the future), or left them to
be "Perl" (when looking to the past).

I've also done this as Raku hopefully will get some more eyeballs looking at
it, and how it got designed / conceived.  Having a mix of "Perl", "Perl 5"
and "Perl 6" in there, will only cause more confusion.  Which we do *NOT*
want to have.

Errors may have been made in this editorial process.  So please do not assume
this is canon in any way!  If you think something is wrong, let us know or
even better, provide a Pull Request!

Thank you for reading this!


[perl6/specs] 180b53: Revert "Move the design documents into the Raku era"

2019-11-16 Thread Elizabeth Mattijsen
  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: 180b534bd6f012e7576384326f2e915162c496be
  
https://github.com/perl6/specs/commit/180b534bd6f012e7576384326f2e915162c496be
  Author: Elizabeth Mattijsen 
  Date:   2019-11-16 (Sat, 16 Nov 2019)

  Changed paths:
M S01-overview.pod
M S02-bits.pod
M S03-operators.pod
M S04-control.pod
M S05-regex.pod
M S06-routines.pod
M S07-lists.pod
M S08-capture.pod
M S09-data.pod
M S10-packages.pod
M S11-modules.pod
M S12-objects.pod
M S13-overloading.pod
M S14-roles-and-parametric-types.pod
M S15-unicode.pod
M S16-io.pod
M S17-concurrency.pod
M S19-commandline.pod
M S21-calling-foreign-code.pod
M S22-package-format.pod
M S24-testing.pod
M S26-documentation.pod
M S28-special-names.pod
M S29-functions.pod
M S31-pragmatic-modules.pod
M S32-setting-library/Basics.pod
M S32-setting-library/Containers.pod
M S32-setting-library/Exception.pod
M S32-setting-library/IO.pod
M S32-setting-library/Numeric.pod
M S32-setting-library/Rules.pod
M S32-setting-library/Str.pod
M S32-setting-library/Temporal.pod
M S99-glossary.pod
M html/index.html
M html/perl-with-historical-message.css
M html/style.css

  Log Message:
  ---
  Revert "Move the design documents into the Raku era"

This reverts commit 6390a500201b5c26512940b0920cd6e9e5111abf.

Will re-commit as a PR


[perl6/specs] c5aa24: Remove obsolete file

2019-11-16 Thread Elizabeth Mattijsen
  Branch: refs/heads/master
  Home:   https://github.com/perl6/specs
  Commit: c5aa24071599a46240ba09cd9c91a37749799d7e
  
https://github.com/perl6/specs/commit/c5aa24071599a46240ba09cd9c91a37749799d7e
  Author: Elizabeth Mattijsen 
  Date:   2019-11-16 (Sat, 16 Nov 2019)

  Changed paths:
R S22-package-format-OLD.pod

  Log Message:
  ---
  Remove obsolete file


Re: Is this a bug?

2016-09-18 Thread Elizabeth Mattijsen
It is the .perl representation of a Block.

> On 18 Sep 2016, at 22:49, Parrot Raiser <1parr...@gmail.com> wrote:
> 
> say { $_ } was the correct thing to use there. (I'm trying to avoid
> any mention of O-O for the moment.)
> say {} was a "what happens if I do this" exercise.
> 
> What is this  -> ;; $_? is raw { #`(Block|170303864) … } output?
> 
> On 9/18/16, Brent Laabs <bsla...@gmail.com> wrote:
>> Remember you can call a block with parentheses:
>> 
>>> say { 11 + 31 };
>> -> ;; $_? is raw { #`(Block|140268472711224) ... }
>>> say { 11 + 31 }();
>> 42
>> 
>> 
>> On Sun, Sep 18, 2016 at 12:58 PM, Elizabeth Mattijsen <l...@dijkmat.nl>
>> wrote:
>> 
>>> I think you want:
>>> 
>>>  .say for reverse lines;
>>> 
>>> not sure what you are trying to achieve otherwise, but:
>>> 
>>>   say { }
>>> 
>>> producing something like
>>> 
>>>   -> ;; $_? is raw { #`(Block|170303864) … }
>>> 
>>> feels entirely correct to me.   :-)
>>> 
>>> 
>>> Liz
>>> 
>>>> On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
>>>> 
>>>> This code:
>>>> 1 #! /home/guru/bin/perl6
>>>> 2
>>>> 3 # Ask for some lines and output them in reverse
>>>> 4 # Work out the appropriate EOF symbol for the OS
>>>> 5
>>>> 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
>>>> 7
>>>> 8 say "Please enter some lines and end them with $EOF";
>>>> 9
>>>> 10 say { for reverse lines() {} };
>>>> 11
>>>> 12 # End
>>>> produces this:
>>>> Please enter some lines and end them with CTRL-D# obviously from
>>> line 8
>>>> -> ;; $_? is raw { #`(Block|170303864) ... }# but
>>> this?
>>> 
>>> 
>> 



Re: Is this a bug?

2016-09-18 Thread Elizabeth Mattijsen
I think you want:

  .say for reverse lines;

not sure what you are trying to achieve otherwise, but:

   say { }

producing something like

   -> ;; $_? is raw { #`(Block|170303864) … }

feels entirely correct to me.   :-)


Liz

> On 18 Sep 2016, at 21:52, Parrot Raiser <1parr...@gmail.com> wrote:
> 
> This code:
> 1 #! /home/guru/bin/perl6
> 2
> 3 # Ask for some lines and output them in reverse
> 4 # Work out the appropriate EOF symbol for the OS
> 5
> 6 my $EOF = "CTRL-" ~ ($*DISTRO.is-win ?? "Z" !! "D");
> 7
> 8 say "Please enter some lines and end them with $EOF";
> 9
> 10 say { for reverse lines() {} };
> 11
> 12 # End
> produces this:
> Please enter some lines and end them with CTRL-D# obviously from line 8
> -> ;; $_? is raw { #`(Block|170303864) ... }# but this?



Re: Help mechanism in REPL?

2016-09-10 Thread Elizabeth Mattijsen
FWIW, the .WHY is a method just like any other.  What would need to be changed, 
is the behaviour of Mu.WHY (around line 60 in Mu.pm).

> On 10 Sep 2016, at 16:41, Brad Gilbert  wrote:
> 
> There was some talk in the past about having `.WHY` look up the
> descriptions in the POD6 doc ( so that we don't have to bloat Rakudo
> with that information )
> 
> On Fri, Sep 9, 2016 at 6:30 PM, Alex Elsayed  wrote:
>> On Wednesday, 7 September 2016 17:57:32 PDT Parrot Raiser wrote:
>>> This isn't a request for a feature, merely a thought experiment. We're
>>> still in the phase where it's more important to ensure that existing
>>> features work properly than add new ones.
>>> 
>>> How difficult would it be to include a mechanism within the REPL to
>>> select either documentation or an example, (possibly from the test
>>> suite), for a particular command? Selection might be by some control
>>> key combination,  cursor positioning, or an alternative to "enter" at
>>> the end of the line. The purpose would be to speed development, by
>>> enabling an inexperienced developer to look up details while testing.
>>> 
>>> Syntax errors generate messages which attempt to provide help; could
>>> this provide the basis for a "help" mechanism? Would this be useful?
>>> 
>>> Opinions?
>> 
>> Well, this sounds like a job for the meta-object protocol (specifically,
>> `.WHY`):
>> 
>> https://docs.perl6.org/language/mop#WHY
>> 
>> The simplest option for handling this in the REPL is probably to have some
>> sort of automatic handling of Pod sent to sink context, rendering it and
>> sending it to a pager. Then, the user could simply do
>> 
 Hash.WHY
>> (LET THERE BE DOCS!)
>> 
>> And there would be docs.



Re: A practical benchmark shows speed challenges for Perl 6

2016-03-30 Thread Elizabeth Mattijsen
> On 30 Mar 2016, at 16:06, yary <not@gmail.com> wrote:
> 
> Cross-posting to the compiler group-
> 
> On Wed, Mar 30, 2016 at 8:10 AM, Elizabeth Mattijsen <l...@dijkmat.nl> wrote:
>> If you know the line endings of the file, using 
>> IO::Handle.split($line-ending) (note the actual character, rather than a 
>> regular expression) might help.  That will read in the file in chunks of 64K 
>> and then lazily serve lines from that chunk.
> 
> This reminds me of a pet peeve I had with p5: Inability to easily
> change the default buffer size for reading & writing.
> 
> I'm the lone Perl expert at $work and at one point was trying to keep
> a file processing step in perl. These files were about 100x the size
> of the server's RAM, consisted of variable-length newline-terminated
> text, the processing was very light, there would be a few running in
> parallel. The candidate language, C#, has a text-file-reading object
> that lets you set its read-ahead buffer on creation/opening the file-
> can't remember the details. That size had a large impact on the
> performance of this task. With perl... I could not use the
> not-so-well-documented IO::Handle->setvbuf because my OS didn't
> support it. I did hack together something with sysread, but C# won in
> the end due partly to that.
> 
> It seems this "hiding-of-buffer" sub-optimal situation is being
> repeated in Perl6: neither https://doc.perl6.org/routine/open nor
> http://doc.perl6.org/type/IO::Handle mention a buffer, yet IO::Handle
> reads ahead and buffers. Experience shows that being able to adjust
> this buffer can help in certain situations. Also consider that perl5
> has defaulted to 4k and 8k, whereas perl6 is apparently using 64k, as
> evidence that this buffer needs to change as system builds evolve.
> 
> Please make this easily readable & settable, anywhere it's implemented!

Thanks for your thoughts!

I’ve implemented $*DEFAULT-READ-ELEMS in 
https://github.com/rakudo/rakudo/commit/5bd1e .

Of course, all of this is provisional, and open for debate and bikeshedding.


Liz

Re: Backwards compatibility and release 1.0

2015-10-15 Thread Elizabeth Mattijsen
> On 15 Oct 2015, at 12:57, Mark Overmeer <m...@overmeer.net> wrote:
> 
> * Elizabeth Mattijsen (l...@dijkmat.nl) [151015 10:43]:
>> FWIW, I’m with FROGGS on this.
>>  use variables :D;
> 
> In the first response to this message, Moritz spoke about
> use invocant :D;
> and use parameters :D;
> 
> Three different things?

There are actually 4 different default setters:

use variables :D;# works, e.g. ‘my Int $a = 42’
use attributes :D;   # works, e.g. ‘has Int $.a = 42’
use invocant :D; # parses, does not work yet, e.g. method a(Int:) {} # 
Int:D:
use parameters :D;   # parses, does not work yet, e.g. sub a(Int $a) {}  # Int:D


>> at the top of the scope of your code, and then you’re set.  I admit
>> it feels a *little* like the “use strict” boilerplate of Perl 5.
> 
> It is.
> 
>> On the other hand, I think by just specifying a type *without* smiley,
>> is already so much better than the situation in Perl 5 that the lacking
>> strictness of :D will not be needed much to catch programming / garbage
>> in type of errors anyway.
> 
> Much better, of course.  Programming languages are used by people
> of different taste.  Some may find "much better" enough, other people
> want more.

And sometimes less is more  :-)



Liz



Re: Backwards compatibility and release 1.0

2015-10-15 Thread Elizabeth Mattijsen

> On 15 Oct 2015, at 11:06, Tobias Leich  wrote:
> Am 15.10.2015 um 10:47 schrieb Smylers:
>> Moritz Lenz writes:
>> 
>>> On 10/13/2015 10:52 AM, Richard Hainsworth wrote:
>>> 
 Following on the :D not :D thread, something odd stuck out.
 
 On 10/13/2015 03:17 PM, Moritz Lenz wrote:
> We have 390+ modules, and hand-waving away all trouble of
> maintaining them seems a bit lofty.
 Surely, the idea of keeping the release number below 1.0 is to warn
 early adopter developers that code is subject to change and thus in
 need of maintenance?
>>> ... a large percentage of the module updates are done by group of
>>> maybe five to a dozen volunteers. ... 5 people updating 70% of 390
>>> modules. Modules they are usually not all that familiar with, and
>>> usually don't have direct access. So they need to go through the pull
>>> request dance, waiting for reaction from the maintainer. In short, it
>>> sucks.
>> Thanks for the explanation, Moritz. That does make sense.
>> 
>> I'm still a _little_ uneasy because that sounds a bit like the
>> explanation of why Makefiles have to use tab characters:
>> 
>>  I just did something simple with the pattern newline-tab. It worked,
>>  it stayed. And then a few weeks later I had a user population of about
>>  a dozen, most of them friends, and I didn't want to screw up my
>>  embedded base. The rest, sadly, is history.
>> 
>>— Stuart Feldman http://stackoverflow.com/a/1765566/1366011
>> 
>> Though the important difference is that invisible whitespace characters
>> that some editors don't even let you type are particularly
>> beginner-hostile, whereas allowing undef arguments where they don't make
>> sense (and hence where callers don't generally try supplying undef) is
>> something that many Perl 5 programs have been doing for years with no
>> widespread harm.
>> 
>> Cheers
>> 
>> Smylers
> Btw, In my opinion the current model about :D etc is very correct. I
> don't see any need to change the
> defaults as how type objects or their definedness is implementet.
> Changing for example the params
> to mean Int:D by default when one writes Int is something you have to
> explain a lot. And in fact it is a lie.
> There are some basic rules about Perl 6 like TIMTOWTDI and DRY, but
> there is also a rule about "All is
> fair if you predeclare". But if I don't predeclare that I mean Int:D by
> writing Int, then the compiler is
> not allowed to change the meaning of what I wrote.

FWIW, I’m with FROGGS on this.

Because Perl 6 has gradual typing.  Going automatically from Int to Int:D, 
doesn’t feel gradual for me.  If you want this behaviour in your code, it is as 
easy as adding a:

  use variables :D;

at the top of the scope of your code, and then you’re set.  I admit it feels a 
*little* like the “use strict” boilerplate of Perl 5.  On the other hand, I 
think by just specifying a type *without* smiley, is already so much better 
than the situation in Perl 5 that the lacking strictness of :D will not be 
needed much to catch programming / garbage in type of errors anyway.


Liz

Re: [perl6/specs] 614b6f: doc with/without

2015-08-11 Thread Elizabeth Mattijsen
If this is about:

These may be cascaded:

with   $s.index(a) { Found a at $_ }
orwith $s.index(b) { Found b at $_ }
orwith $s.index(c) { Found c at $_ }
else { Didn't find a, b or c” }

then the code is correct.  What would be the point of searching for “a” again 
and again if it wasn’t found the first time?



Liz

 On 11 Aug 2015, at 06:08, Richard Hainsworth rnhainswo...@gmail.com wrote:
 
 Is there an error in the cascade? Shouldn't the indices be 'a', 'b', 'c'; not 
 'a','a','a' ?
 
 On 08/10/2015 11:26 PM, yary wrote:
 with, without look awesome.
 
 -y
 
 On Sat, Aug 8, 2015 at 2:38 PM, GitHub nore...@github.com wrote:
   Branch: refs/heads/master
   Home:   https://github.com/perl6/specs
   Commit: 614b6f36e1cae4c787e378bc6ab2afa1f86de1f0
   
 https://github.com/perl6/specs/commit/614b6f36e1cae4c787e378bc6ab2afa1f86de1f0
   Author: TimToady la...@wall.org
   Date:   2015-08-08 (Sat, 08 Aug 2015)
 
   Changed paths:
 M S04-control.pod
 
   Log Message:
   ---
   doc with/without
 
 
 
 



Re: Synopses size and revision state

2015-05-15 Thread Elizabeth Mattijsen
 On 15 May 2015, at 16:05, Parrot Raiser 1parr...@gmail.com wrote:
 
 Without doing too much work, can anyone offer an estimate of the
 volume of the Perl 6 Synopses? I'm assuming that by now, they are
 unlikely to undergo serious modification.
 
 I'm trying to estimate the cost of rendering them to dead-tree
 versions for study. (Personal limitation; I can look up a command
 definition online, but for study and mental integration, it's got to
 be something like a real book.)

at 4+ lines and 100 lines / page, that would be about 400 pages ?



Liz


Re: S02 mistake re Blob?

2015-02-21 Thread Elizabeth Mattijsen

 On 21 Feb 2015, at 21:56, Darren Duncan dar...@darrenduncan.net wrote:
 On 2015-02-21 2:45 AM, Moritz Lenz wrote:
 On 21.02.2015 08:51, Darren Duncan wrote:
 I notice from looking at http://design.perl6.org/S02.html that Blob is 
 listed
 both as being a role and as a type.  See 
 http://design.perl6.org/S02.html#Roles
 for an example of the former, and
 http://design.perl6.org/S02.html#Immutable_types for an example of the 
 latter.
 -- Darren Duncan
 
 so, you think roles aren't types?
 
 (Also, roles auto-pun into classes upon usage).
 
 When I said type I meant class.  As I recall from the rest of the spec, 
 things were either roles or classes.  You can't instantiate a role directly, 
 so if a Blob is declared as a role you can't just instantiate one directly, 
 isn't that how it works?  Either way it seemed to be getting treated 
 differently. -- Darren Duncan

$ 6 'role A {}; my $a = A.new; say $a'
A.new()

You *can* instantiate a Role directly.  See above.



Liz

Re: state and = vs :=

2014-10-02 Thread Elizabeth Mattijsen
On 01 Oct 2014, at 07:48, Father Chrysostomos spr...@cpan.org wrote:
 Does ‘state’ govern ‘:=’ the way it governs ‘=’?  In other words, just as 
 this:
 
state $x = 1;
 
 only assigns to $x once (per closure), does the same apply to this?
 
state $x := $y;
 
 I can’t find anything in the specs that implies that it does.
 
 The reason I ask is that I am currently implementing binding for Perl 5, but 
 the syntax is different—
 
\$x = \$y;
 
 (The reason for the different syntax is that, when we tried to use :=, we 
 could not find a coherent way to handle edge cases [e.g., flattening vs not 
 flattening].  Reusing existing Perl 5 syntax seemed the most straightforward 
 and intuitive approach.)
 
 —and I am debating whether \state $x = \$y should bind only once or every 
 time the surrounding code is executed.  I could argue it either way (though I 
 am leaning toward the latter), so I thought to find out what Perl 6 does.

It would seem that binding state variables will be something that will be 
prohibited in Perl 6, until such time we find a good use case for it.


[15:55:36] lizmat  well, all of this was because of a question of Father 
Chrysostomos (a very productive p5p contributor) on p6l
[15:57:01] jnthn   OK. Well, I'll leave it at, I'm happy enough with the 
current semantics, so unless TimToady++ feels they have to chnage, then I'm not 
inclined to do much about the status quo.
[15:57:44] jnthn   (Where by the current semantics I mean, what Moar 
does, and I'm about certain what we do on JVM. I don't actually know how things 
are on Parrot.)
[15:57:59] lizmat  eh, but the current semantics silently do the wrong 
thing, no ?
[15:59:11] jnthn   lizmat: Depends how you define the semantics of state.
[15:59:44] jnthn   lizmat: Note that if you go binding a temp or let var 
you are in equal trouble.
[16:00:03] moritzwouldn't mind compile-time disallowing rebinding 
temp/let/state vars
[16:00:05] jnthn   'cus those are certainly about value, not container
[16:00:14] lizmat moritz +1
[16:00:18] jnthn   I took state to be wanting the same semantics
[16:00:31] jnthn   Yeah, I could go with a conservative approach of just 
disallow it
[16:00:53] lizmat  I'll answer FC


Hope this answer your question,


Liz

Re: Class attribute introspection

2013-10-28 Thread Elizabeth Mattijsen
Maybe http://en.wikipedia.org/wiki/Metaobject is a good start for reading up on 
what a MOP (Meta-Object Protocol) is.


Liz
===
On 28 Oct 2013, at 14:17, Richard Hainsworth rich...@rusrating.ru wrote:
 Moritz,
 
 You are the everflowing font of knowledge. Thanks.
 
 However, I read the synopsis on objects and did not find the .get_value 
 method.
 
 Pardon the ignorance, but what is the MOP. I sometimes get floored by the 
 jargon.
 
 I read about the indirection for methods, but how does that relate to 
 attributes?
 
 Richard
 
 On 10/28/2013 01:45 PM, Moritz Lenz wrote:
 Hi Richard,
 
 On 10/28/2013 08:07 AM, Richard Hainsworth wrote:
 Perhaps I am using class incorrectly, but I set up a class, then change
 some of the parameters in an instance of the class. Next I would like to
 discover what the current state of the instance is.
 
 There is a way to introspect through the MOP:
 
 class A { has $!x = 42; };
 my $obj = A.new;
 say A.^attributes[0].get_value($obj);
 
 It's not straight forwards, and that's actually a feature :-)
 
 The usual way to go is through the accessors, and indirect method calls with 
 $obj.$name();
 
 Cheers,
 Moritz
 



Re: Perl 6 in non-English languages

2010-06-23 Thread Elizabeth Mattijsen
On Jun 23, 2010, at 12:34 AM, SundaraRaman R wrote:
 This is an idea that originated in #perl6 during a discussion with slavik (
 http://irclog.perlgeek.de/perl6/2010-01-17#i_1907093). The goal is to allow
 Perl 6 source code to be written in natural languages other than English.
 The motivation would be to make programming accessible to a lot of people
 who don't know English well (or at all), to make it easier to teach
 programming to kids in non-English speaking countries, and just plain fun.
 
 Currently, since Perl 6 (afaik) supports Unicode identifiers, the only place
 a modification is required would be in the keywords. However, it is not a
 simple matter of substituting s/keyword/local_language_keyword/ since the
 resultant phrasing might be awkward or meaningless and unreadable (examples
 in the linked discussion). It requires reordering the syntax of each
 construct.
 
 Is it possible to do this at a module level? If so, how much English usage
 would that require before someone could start programming in their own
 language - say, two, for a shebang line and a use Lang::Language line?
 or zero, by using perl6 -MLang::Language in the command line?
 
 Are there any ongoing works in this vein?

Having been that road down at least once in my life already (using the TUTOR 
language), I would be very much against adding this as a standard feature.  
Unless you have people that can provide support (aka a user base) for that 
language, you are going to introduce a babylonian knot of misunderstanding in 
mailinglist, chats and what not.

If this would be added as a feature, then there should be an easy way to take 
any source file in a different natural language, and have it rendered into 
English (or any other of the languages supported that way).


My old 2cents worth...


Going back to lurking mode again.


Liz

Re: Default program

2004-04-01 Thread Elizabeth Mattijsen
At 00:05 -0800 4/1/04, Brent 'Dax' Royal-Gordon wrote:
On the other hand, the current behavior may be somewhat entrenched, and
might break our promise to assume that code is Perl 5 until we see a
different indication.  As an alternative, perhaps the -H command-line
switch could be used to use a hello world program.
I think we need to consider all of the implications here:  Hello 
World is very english centric, so I would assume that Perl 6 would 
need investigate the locale and change the text to Monde, Allo! if 
you're using a French locale, Hallo, Welt! for German locale, and 
1 april! for Dutch.  ;-)

Liz


Resource Management ?

2001-02-14 Thread Elizabeth Mattijsen

After lurking on the Perl6-lists and finally catching up on this long 
discussion about garbage collection, I'm coming out ;-).

The reason I'm coming out is that I realised that we should maybe have a 
radically different view on garbage collection than we have now.

Think about it:

1: in an ideal world with unlimited resources, who would need garbage 
collection anyway?  Or: simple oneliners and small scripts don't need GC.

2: limited resources may appear still available when in fact, they are 
not.  E.g. a limit on the total number of simultaneous database connections 
as seen from the database server, not the Perl process.  The Perl process 
still thinks it can open connections, when in fact the database server is 
already saturated.

3: some resources may not be needed temporarily, but should become 
available magically when needed.  E.g. virtual memory, database connections 
that re-connect automatically after a disconnect (for whatever reason).

4: As a Perl programmer, I don't care whether a file-handle has been closed 
because of resource management, as long as it is available to me when I 
need it.  I don't care whether a connection to a database server has been 
re-used by other database server users, as long as I have a connection 
(transparently) when I need it.

5: As a server administrator, I would like to be able to limit the 
available memory to a Perl program or maximum number of database 
connections, so that it behaves nicely towards other users of that server.


I think this calls for a resource management system, rather than a garbage 
collection system.  A resource management system with an API with which 
resources (their creation, cleanup and destruction routines) can be 
registered.  No garbage collection (which implies a not well thought out 
"way of life" to me) but planned ahead resource management (know in advance 
what you need when) for situations that need it.  (I guess my Dutch 
background is showing here, wanting to have everything neatly organised ;-).

This resource management system would ideally include a (pluggable) virtual 
memory system for Perl itself (Perl may be able to know better what to 
temporarily store on disk than any OS would).

It would include the file IO subsystem.

It would include the handling of any external connections (such as 
connections to databases).

Or any other resource that is in limited availability.


And of course, such a resource management system should degrade to a 
"everything is free" approach for simple one-liners and small scripts, like 
the current situation.



Elizabeth Mattijsen


P.S. Dan: I hope you don't mind not waiting for your PDD, but this seemed 
too important to me for the train of thought about garbage collection at 
this point in time.