[32997] in Perl-Users-Digest
Perl-Users Digest, Issue: 4273 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Aug 20 00:09:20 2014
Date: Tue, 19 Aug 2014 21:09:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 19 Aug 2014 Volume: 11 Number: 4273
Today's topics:
Re: Cannot install Perl modules on Windows <benswitala@gmail.com>
Re: Cannot install Perl modules on Windows <news@lawshouse.org>
Re: Cannot install Perl modules on Windows <rweikusat@mobileactivedefense.com>
Re: How can I point to different Perl compilers based o (Tim McDaniel)
Re: perl6 too much pointless functionality <bauhaus@futureapps.invalid>
Re: perl6 too much pointless functionality <bauhaus@futureapps.invalid>
Re: perl6 too much pointless functionality <rweikusat@mobileactivedefense.com>
Re: perl6 too much pointless functionality <hjp-usenet3@hjp.at>
Re: perl6 too much pointless functionality <bauhaus@futureapps.invalid>
Re: perl6 too much pointless functionality <rweikusat@mobileactivedefense.com>
Re: perl6 too much pointless functionality <bauhaus@futureapps.invalid>
Re: perl6 too much pointless functionality <rweikusat@mobileactivedefense.com>
Re: perl6 too much pointless functionality <kaz@kylheku.com>
Re: perl6 too much pointless functionality <rweikusat@mobileactivedefense.com>
Re: perl6 too much pointless functionality <jblack@nospam.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 18 Aug 2014 13:30:00 -0700 (PDT)
From: Ben Switala <benswitala@gmail.com>
Subject: Re: Cannot install Perl modules on Windows
Message-Id: <c033f71a-08a1-4012-9065-cf8dee98d1c1@googlegroups.com>
On Monday, August 18, 2014 12:33:14 PM UTC-7, Rainer Weikusat wrote:
> Ben Switala writes:
>=20
> > I'm trying to install a Perl module on my Windows computer, and it's
>=20
> > now working. What am I missing?
>=20
> >
>=20
> > Also, how do I get rid of the strange strings like "=E9=94=9F=E6=96=A4=
=E6=8B=B7[32m" and "=E9=94=9F=E6=96=A4=E6=8B=B7[0m"
>=20
> > from printing all over the place?
>=20
>=20
>=20
> These are character rendition of ANSI escape sequences for terminal
>=20
> control (the first one is supposed to change the foreground colour to
>=20
> green, the second to change it back to whatever it happened to be
>=20
> before). The 'window' (program) used to provide you with a way of using
>=20
> the CPAN CLI-interface should usually interpret these.
>=20
>=20
>=20
> > cpan> install Tie::IxHash
>=20
> > =E9=94=9F=E6=96=A4=E6=8B=B7[32mFetching with LWP:
>=20
> > http://ppm.activestate.com/CPAN/authors/01mailrc.txt.gz=E9=94=9F=E6=96=
=A4=E6=8B=B7[0m
>=20
> > =E9=94=9F=E6=96=A4=E6=8B=B7[32mLWP failed with code[500] message[Can't =
connect to ppm.activestate.com:80 (
>=20
> > 10060)]=E9=94=9F=E6=96=A4=E6=8B=B7[0m
>=20
>=20
>=20
> Isn't this clear-cut enough? The software tried to connect to
>=20
> ppm.activestate.com port 80 (HTTP default port) which failed.
Apparently the CLI is not interpreting those ANSI escape sequences. Do you=
know how to get it to interpret them?
Yes, it's clear-cut that cpan cannot connect to ppm.activestate.com port 80=
. But what should I do about it?
Before you answer that, though, somehow I successfully managed to d/l and i=
nstall that module. Unfortunately, I do not know what I did to cause the s=
uccessful installation. At one point I know I was running as System Admini=
strator (although I don't think I was running as such when the installation=
succeeded) and I know that I used the "ppm install" command instead of cpa=
n.
Also...as a random side note...do we normally post at the bottom or at the =
top of the input text area? Usually I think web forums (BBSs or whatever) =
don't give me an option, but in Google Groups I can strangely choose which =
post to reply to and where to type in my response. Does that question make=
sense?
------------------------------
Date: Mon, 18 Aug 2014 21:45:25 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: Cannot install Perl modules on Windows
Message-Id: <K62dnWh6Yb53-G_OnZ2dnUVZ8nmdnZ2d@giganews.com>
On 18/08/14 19:30, Ben Switala wrote:
> I'm trying to install a Perl module on my Windows computer, and it's now working.
(Presumably you mean "not working" :-) )
IIRC Activestate has its own mechanism for installing modules, called
PPM. It's some time since I did much with Perl in Windows, but when I
did I remembered (a) that Activestate strongly recommend that you use
PPM and don't install modules from CPAN; (b) that the repository
supporting PPM has modules built and tested in Windows, which makes
sense; and (c) that on the occasions when I went against ActiveState's
advice (the PPM repository doesn't contain everything that CPAN does)
then I had mixed results. Certainly any CPAN installation that needs
OS-specific binaries, or that tries to compile one in flight, is going
to struggle in Windows.
--
Henry Law Manchester, England
------------------------------
Date: Mon, 18 Aug 2014 23:29:05 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Cannot install Perl modules on Windows
Message-Id: <87iolpph3i.fsf@sable.mobileactivedefense.com>
Ben Switala <benswitala@gmail.com> writes:
> On Monday, August 18, 2014 12:33:14 PM UTC-7, Rainer Weikusat wrote:
>> Ben Switala writes:
[...]
>> > Also, how do I get rid of the strange strings like "��[32m" and "��[0m"
>> > from printing all over the place?
>>
>>
>>
>> These are character rendition of ANSI escape sequences for terminal
>> control
[...]
>> > cpan> install Tie::IxHash
>>
>> > ��[32mFetching with LWP:
>> > http://ppm.activestate.com/CPAN/authors/01mailrc.txt.gz��[0m
>> > ��[32mLWP failed with code[500] message[Can't connect to ppm.activestate.com:80 (
>> > 10060)]��[0m
>>
>>
>>
>> Isn't this clear-cut enough? The software tried to connect to
>> ppm.activestate.com port 80 (HTTP default port) which failed.
>
> Apparently the CLI is not interpreting those ANSI escape sequences.
> Do you know how to get it to interpret them?
>
> Yes, it's clear-cut that cpan cannot connect to ppm.activestate.com
> port 80. But what should I do about it?
I don't have the slighest idea (the 2nd issue suggests something
blocking outgoing network traffic from the CLI session, possibly only
for non-administrators) because I don't use Windows. Even if I had one,
'how do I get Windows to do XXX' is not really an appropriate question
for a Perl newsgroup
[...]
> Also...as a random side note...do we normally post at the bottom or at
> the top of the input text area? Usually I think web forums (BBSs or
> whatever) don't give me an option, but in Google Groups I can
> strangely choose which post to reply to and where to type in my
> response. Does that question make sense?
Short answer: The usual convention would be to mix your text with enough
of a quote from relevant predecessor articles that someone who didn't
follow the thread from the start (or who chose to reply after three
months have passed) has a chance to understand you statement in the
context it was meant to be understood.
This is not really a web forum, it is actually USENET and you're just
accessing it through a somewhat bizarre, web-based interface. locating
some kind of USENET newbies FAQ and reading that might be helpful/
insightful.
------------------------------
Date: Tue, 19 Aug 2014 23:58:15 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: How can I point to different Perl compilers based on OS?
Message-Id: <lt0oan$ela$1@reader1.panix.com>
In article <877g2gb8f3.fsf@sable.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>OSTYPE is not an environment variable, it's a 'special variable'
>supported by bash.
Of course
export OSTYPE
in bash would make it an environment variable, but that would be a
suboptimal suggestion, as it would rely on each user to have done it.
Well, it might be OK for employees at a company, for example, because
IT could set them up that way, but not as generally-distributed
software.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Tue, 19 Aug 2014 13:02:47 +0200
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: perl6 too much pointless functionality
Message-Id: <lsvaso$1i5$1@dont-email.me>
On 18.08.14 21:47, Peter J. Holzer wrote:
> I haven't really been following
> Perl6 development the last few years (I think it's a dead end), but
> AFAIK work was mostly done on the VMs (Oh, MoarVM has aquired a JIT over
> the summer), not on the syntax of Perl6.
Have a look, there are some cuties (vs Perl 5) like e.g. dropping
the () around conditionals, or assigning the result of the
conditional test to a variable by placing "-> $var" after it,
etc etc. See if this does more than creating more ways to do it, like
by displacing what is now an unnecessarily boring assignment statement.
------------------------------
Date: Tue, 19 Aug 2014 13:45:00 +0200
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: perl6 too much pointless functionality
Message-Id: <lsvdbt$ga3$1@dont-email.me>
On 18.08.14 18:03, Rainer Weikusat wrote:
> Some CPAN packages do this and they're typically not 'allowed to rot'
> (an example would be nice here).
E.g. SOAP - if an external requirement makes you need it, and you
need it within a given system setup which typically restricts
repositories permitted. Some packages work, some work partially.
At least one shows traces of former sponsoring. Creativity, fixing,
and DIY helps.
Some packages – I prefer to forget them, since that kind of
knowledge is unlikely to be profitable – have had problems
handling XS. This is somewhat expected if they are old and if
there is no automatic transformation to newer Perls and OSs.
We are therefore prepared to look for alternatives, or fix if
possible and if this does not entail too much work to be
repeated by the system administrators.
IIRC, OpenSuse has tables of Perl packages that will likely
not work in (relaively) upcoming releases of the SuSE enterprise
system, due to build failure on some or all architectures.
I am still trying to get just any Pod-to-RTF working on a non-NT
system, time permitting. That's somewhat important since we
need to provide partial documentation to people working in sales
and management. It would be nice to meet their expectations
which are necessarily Windowsâ„¢ centric.
The focus of Perl 6 is not on issues like these, I believe.
------------------------------
Date: Tue, 19 Aug 2014 14:51:33 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: perl6 too much pointless functionality
Message-Id: <87ppfwsi3e.fsf@sable.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 18.08.14 18:03, Rainer Weikusat wrote:
>> Some CPAN packages do this and they're typically not 'allowed to rot'
>> (an example would be nice here).
>
> E.g. SOAP - if an external requirement makes you need it, and you
> need it within a given system setup which typically restricts
> repositories permitted. Some packages work, some work partially.
> At least one shows traces of former sponsoring. Creativity, fixing,
> and DIY helps.
Well, "there is no such thing as a free lunch" and if you're using open
source code downloaded from the internet, you'll always either end up
fixing bug or adding features or both. Typically, this is less work then
re-implmenting something from scratch.
------------------------------
Date: Tue, 19 Aug 2014 16:05:46 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: perl6 too much pointless functionality
Message-Id: <slrnlv6mdq.nsp.hjp-usenet3@hrunkner.hjp.at>
On 2014-08-19 11:02, G.B. <bauhaus@futureapps.invalid> wrote:
> On 18.08.14 21:47, Peter J. Holzer wrote:
>> I haven't really been following
>> Perl6 development the last few years (I think it's a dead end), but
>> AFAIK work was mostly done on the VMs (Oh, MoarVM has aquired a JIT over
>> the summer), not on the syntax of Perl6.
>
> Have a look, there are some cuties (vs Perl 5)
"vs. Perl5" is irrelevant. Perl6 split from Perl5 14 years ago. If you
want to make claims about the foolishness of people still working on
Perl6, compare Perl6 now with Perl6 of a few years ago.
> like e.g. dropping the () around conditionals,
That change is already mentioned in Apocalypse 5, published in 2002.
It is definitely not a recent change.
> or assigning the result of the conditional test to a variable by
> placing "-> $var" after it,
I don't remember that, but I'd be surprised if it was recent, either.
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Tue, 19 Aug 2014 17:45:04 +0200
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: perl6 too much pointless functionality
Message-Id: <lsvre0$jca$1@dont-email.me>
On 19.08.14 15:51, Rainer Weikusat wrote:
> "G.B." <bauhaus@futureapps.invalid> writes:
>> On 18.08.14 18:03, Rainer Weikusat wrote:
>>> Some CPAN packages do this and they're typically not 'allowed to rot'
>>> (an example would be nice here).
>>
>> E.g. SOAP - if an external requirement makes you need it, and you
>> need it within a given system setup which typically restricts
>> repositories permitted. Some packages work, some work partially.
>> At least one shows traces of former sponsoring. Creativity, fixing,
>> and DIY helps.
>
> Well, "there is no such thing as a free lunch" and if you're using open
> source code downloaded from the internet, you'll always either end up
> fixing bug or adding features or both. Typically, this is less work then
> re-implmenting something from scratch.
Yes, using half-working packages can be less work than implementing
something from scratch, but doing this has nothing to do with
"open source code downloaded from the internet", in that its being
open and available facilitates the DIY work in the first place,
at least in Perl. And with supported open source Perl packages,
you'll end up reporting bugs and having them fixed for you,
possibly at a cost. (Again, the provider of fixes can't sell
the same 1 fix n times after the fix has been published, in
whatever form, closed or open.)
It is the worst situation when some work was distributed as closed
source and then becomes unavailable. (Hence source code escrow
which really is open source code kept private.)
In any case, Perl 6, if it were to introduce backwards
compatibility issues, and no automatic translation,
could only aggravate the situation.
------------------------------
Date: Tue, 19 Aug 2014 17:16:26 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: perl6 too much pointless functionality
Message-Id: <87ha18sbdx.fsf@sable.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 19.08.14 15:51, Rainer Weikusat wrote:
>> "G.B." <bauhaus@futureapps.invalid> writes:
>>> On 18.08.14 18:03, Rainer Weikusat wrote:
>>>> Some CPAN packages do this and they're typically not 'allowed to rot'
>>>> (an example would be nice here).
>>>
>>> E.g. SOAP - if an external requirement makes you need it, and you
>>> need it within a given system setup which typically restricts
>>> repositories permitted. Some packages work, some work partially.
>>> At least one shows traces of former sponsoring. Creativity, fixing,
>>> and DIY helps.
>>
>> Well, "there is no such thing as a free lunch" and if you're using open
>> source code downloaded from the internet, you'll always either end up
>> fixing bug or adding features or both. Typically, this is less work then
>> re-implmenting something from scratch.
>
> Yes, using half-working packages can be less work than implementing
> something from scratch, but doing this has nothing to do with
> "open source code downloaded from the internet", in that its being
> open and available facilitates the DIY work in the first place,
> at least in Perl. And with supported open source Perl packages,
> you'll end up reporting bugs and having them fixed for you,
> possibly at a cost.
There's a false dichotomoy in here, namely, 'DIY work' versus 'supported
open source packages', the first term suggesting lower quality
"hobbyists stuff": It's professional development either way, just done
by 'people who provide support for open sourde code to their customers'
(or the customers of their respective employers) vs 'paying the people
who are very much convinced that only they should be allowed to do this,
free software license and (often) lacking quality of work
notwithstanding'.
But that's totally off topic here.
------------------------------
Date: Tue, 19 Aug 2014 18:30:40 +0200
From: "G.B." <bauhaus@futureapps.invalid>
Subject: Re: perl6 too much pointless functionality
Message-Id: <lsvu3h$77m$1@dont-email.me>
On 19.08.14 16:05, Peter J. Holzer wrote:
> I don't remember that, but I'd be surprised if it was recent, either.
Are you insisting that whoever is working on Perl 6 is likely not
working on Perl 6 syntax and therefore that mentioning Perl 6 syntax
like the OP (in some sense) was doing, and contrasting that with the
lack of work on packages does not agree with allegedly actual Perl 6
work (on the VM(s), perhaps) as the former is passed, water under
the bridge and that therefore the whole rhetorical pattern is
logically inadequate WRT the presupposed absolute reference of what
current Perl 6 work is and therefore saying "new syntax" is wrong?
This then will miss the overarching concern during the evaluation of
Perl 6, no matter whether the person is perceiving the Perl 6 events
at wall clock time or at Perl version time or at Perl 6 perception
time: Being able to use Perl, with useful packages, while
understanding the syntax, is it.
------------------------------
Date: Tue, 19 Aug 2014 19:37:46 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: perl6 too much pointless functionality
Message-Id: <87d2bws4ud.fsf@sable.mobileactivedefense.com>
"G.B." <bauhaus@futureapps.invalid> writes:
> On 19.08.14 16:05, Peter J. Holzer wrote:
>> I don't remember that, but I'd be surprised if it was recent, either.
>
> Are you insisting that whoever is working on Perl 6 is likely not
> working on Perl 6 syntax and therefore that mentioning Perl 6 syntax
> like the OP (in some sense) was doing, and contrasting that with the
> lack of work on packages does not agree with allegedly actual Perl 6
> work (on the VM(s), perhaps) as the former is passed, water under
> the bridge and that therefore the whole rhetorical pattern is
> logically inadequate WRT the presupposed absolute reference of what
> current Perl 6 work is and therefore saying "new syntax" is wrong?
The original statement was
,----
| While there appears to be some concerted work on some
| libraries, the creative people still behind Perl 6 seem to spend
| more energy on mixing more 7 bit ASCII ideographs with the current
| syntax,
`----
This is an assertion about the present ('seem to spend more energy') and
unless these people actually do spend time on redesigning the Perl6
syntax hic et nunc, it's wrong.
Even when leaving this aside, it doesn't make too much sense: Of course,
the people who designed Perl6 spent more time on designing a new
programming language than on dealing with more-or-less obsolete
third-party packages programmed in some other programming language when
they were designing the new programming language because they were
designing a new programming language.
> This then will miss the overarching concern during the evaluation of
> Perl 6, no matter whether the person is perceiving the Perl 6 events
> at wall clock time or at Perl version time or at Perl 6 perception
> time: Being able to use Perl, with useful packages, while
> understanding the syntax, is it.
Should this perhaps have been 'an evaluation'? If so, I think the
'useful packages' are a secondary concern: If the language in itself is
useful, it can be used within the limits of the available library
support. Eg, right now, 'internet Perl5' has no useful module for
synchronous I/O mulitplexing --- either the facility is a long obsolete
technical weirdness (select) or the implementation is totally braindead
(IO::Poll, IO::EPoll, Linux::EPoll) or it is buried in some kind of
event-handling framework which can't be used without structuring the
whole program according to the whims of its author. Hence, something
providing this needs to be implemented.
------------------------------
Date: Tue, 19 Aug 2014 19:34:11 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: perl6 too much pointless functionality
Message-Id: <20140819114744.369@kylheku.com>
On 2014-08-12, George Mpouras <gravitalsun@hotmail.foo> wrote:
> For example look here http://doc.perl6.org/language/variables
>
> my $lexical = 1;
> my $*dynamic1 = 10;
> my $*dynamic2 = 100;
Lexical and dynamic scope are both very useful.
Dynamic scope lets you extend modules of code with contexts, which do not
have to appear in the argument list.
For instance, a database handle could be a dynamically scoped variable.
Dynamically scoped variables can be made thread-safe, and then they
give rise to a very nice abstraction for thread-local storage.
You can override the $*dbhandle variable in different threads with different
handles. Each thread can call database routines without passing down the handle
explicitly, yet all those calls use the correct handle for the calling thread
simply by accessing that dynamic variable.
> who asked them for all this __it ? Who needs all this pointless
> complexity ? Only those who develop this stuff in their nightmares.
> Do they ask anyone ?
They looked toward languages that support both lexical and dynamic scoping,
such as perhaps Common Lisp.
The implementation involving more sygils being piled on to identifiers
is rather ugly.
Lisp's *earmuffs* notation for special variables is part of the symbol name,
not a special syntax.
Global variables are always dynamic, and the defvar and defparameter
forms specially "bless" the symbol so that it is treated as dynamic
in subsequent scopes.
Global lexicals are largely pointless; the global environment isn't a region
of program text but a pervasive namespace.
(defvar dynamic 1)
(let ((lexical 2))
(defun test ()
(list dynamic lexical)))
(let ((dynamic 100)
(lexical 200))
(test)) -> (100 2) ;; dynamic now 100
dynamic -> 1 ;; back to 1
The let around the (test) call overrides the dynamic variable with the value
100, but has no effect on the (let ((lexical 2)) ...) binding which is a
different lexical scope.
Dynamic rebinding could lead to bugs, when a name which happens to be
a dynamic global is accidentally used as the name of a local variable,
and so dynamic variables are usually given the earmuffs notation: two
asterisks, as in *dynamic*.
This is probably what inspired the Perl6 sygil for dynamics being an asterisk.
------------------------------
Date: Tue, 19 Aug 2014 20:50:51 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: perl6 too much pointless functionality
Message-Id: <87bnrgqmw4.fsf@sable.mobileactivedefense.com>
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2014-08-12, George Mpouras <gravitalsun@hotmail.foo> wrote:
>> For example look here http://doc.perl6.org/language/variables
>>
>> my $lexical = 1;
>> my $*dynamic1 = 10;
>> my $*dynamic2 = 100;
>
> Lexical and dynamic scope are both very useful.
[examples]
>> who asked them for all this __it ? Who needs all this pointless
>> complexity ? Only those who develop this stuff in their nightmares.
>> Do they ask anyone ?
>
> They looked toward languages that support both lexical and dynamic scoping,
> such as perhaps Common Lisp.
Perl 5 also supports both lexical and dynamic scoping.
> The implementation involving more sygils being piled on to identifiers
> is rather ugly.
>
> Lisp's *earmuffs* notation for special variables is part of the symbol name,
> not a special syntax.
[...]
> This is probably what inspired the Perl6 sygil for dynamics being an
> asterisk.
But it is 'one worse': Instead of a dubious convention conveying
information which isn't relevant at the point of use (lpszBlafasel ...),
a variable whose name exists in the symbol table of the package is now a
genuinly different kind of animal than a lexical variable, ie, it's not
possible to make some existing piece of code use a variable from the
other namespace without changing all the names used by it. That's a
classic 'spaghetti construction' where the lower level suddenly
jumps back up in a semicircle and asserts control of something residing
at a higher level.
------------------------------
Date: Tue, 19 Aug 2014 22:16:48 -0500
From: John Black <jblack@nospam.com>
Subject: Re: perl6 too much pointless functionality
Message-Id: <MPG.2e5dcf0e4b7a22569897f4@news.eternal-september.org>
In article <20140819114744.369@kylheku.com>, kaz@kylheku.com says...
>
> On 2014-08-12, George Mpouras <gravitalsun@hotmail.foo> wrote:
> > For example look here http://doc.perl6.org/language/variables
> >
> > my $lexical = 1;
> > my $*dynamic1 = 10;
> > my $*dynamic2 = 100;
>
> Lexical and dynamic scope are both very useful.
>
> Dynamic scope lets you extend modules of code with contexts, which do not
> have to appear in the argument list.
>
> For instance, a database handle could be a dynamically scoped variable.
>
> Dynamically scoped variables can be made thread-safe, and then they
> give rise to a very nice abstraction for thread-local storage.
>
> You can override the $*dbhandle variable in different threads with different
> handles. Each thread can call database routines without passing down the handle
> explicitly, yet all those calls use the correct handle for the calling thread
> simply by accessing that dynamic variable.
>
> > who asked them for all this __it ? Who needs all this pointless
> > complexity ? Only those who develop this stuff in their nightmares.
> > Do they ask anyone ?
>
> They looked toward languages that support both lexical and dynamic scoping,
> such as perhaps Common Lisp.
>
> The implementation involving more sygils being piled on to identifiers
> is rather ugly.
>
> Lisp's *earmuffs* notation for special variables is part of the symbol name,
> not a special syntax.
>
> Global variables are always dynamic, and the defvar and defparameter
> forms specially "bless" the symbol so that it is treated as dynamic
> in subsequent scopes.
>
> Global lexicals are largely pointless; the global environment isn't a region
> of program text but a pervasive namespace.
>
> (defvar dynamic 1)
>
> (let ((lexical 2))
> (defun test ()
> (list dynamic lexical)))
>
> (let ((dynamic 100)
> (lexical 200))
> (test)) -> (100 2) ;; dynamic now 100
>
> dynamic -> 1 ;; back to 1
>
> The let around the (test) call overrides the dynamic variable with the value
> 100, but has no effect on the (let ((lexical 2)) ...) binding which is a
> different lexical scope.
>
> Dynamic rebinding could lead to bugs, when a name which happens to be
> a dynamic global is accidentally used as the name of a local variable,
> and so dynamic variables are usually given the earmuffs notation: two
> asterisks, as in *dynamic*.
>
> This is probably what inspired the Perl6 sygil for dynamics being an asterisk.
I'm not sure if you are trying to prove the original poster's point but none of this is
remotely comprehensible to anyone save a handful of people in the world. I think this kind
of confusing complexity might be somewhat responsible for Perl 6 not being adopted very
widely. Part of what has made Perl so successful is that it is SO easy to code in. One of
Perl's promises was that it would make the complex easy and I think it has lived up to that
promise. Does Perl 6 have that same goal?
John Black
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4273
***************************************
