[28039] in Perl-Users-Digest
Perl-Users Digest, Issue: 9403 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jun 28 18:15:17 2006
Date: Wed, 28 Jun 2006 15:15:10 -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 Wed, 28 Jun 2006 Volume: 10 Number: 9403
Today's topics:
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <find@my.address.elsewhere>
Re: What is Expressiveness in a Computer Language <eval.apply@gmail.com>
Re: What is Expressiveness in a Computer Language <find@my.address.elsewhere>
Re: What is Expressiveness in a Computer Language <pc@p-cos.net>
Re: What is Expressiveness in a Computer Language <david.nospam.hopwood@blueyonder.co.uk>
Re: WIN32 PPM and perldoc problems jovo.miskin@sciatl.com
Re: WIN32 PPM and perldoc problems <rvtol+news@isolution.nl>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 28 Jun 2006 11:16:03 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151518563.638141.313110@b68g2000cwa.googlegroups.com>
Matthias Blume wrote:
>
> How does this "create" such a problem? The problem is there in either
> approach. In fact, I believe that the best chance we have of
> addressing the problem is by adopting the "replace the code" model
> along with a "translate the data where necessary at the time of
> replacement". Translating the data, i.e., re-establishing the
> invariants expected by the updated/replaced code, seems much harder
> (to me) in the case of self-modifying code. Erlang got this one
> right.
Pardon my ignorance, but what is the Erlang solution to this problem?
Marshall
------------------------------
Date: Wed, 28 Jun 2006 13:50:42 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m1mzbxf725.fsf@hana.uchicago.edu>
Pascal Costanza <pc@p-cos.net> writes:
>> And I am convinced that updating a running system in the style of,
>> e.g., Erlang, can be statically typed.
>
> Maybe. The interesting question then is whether you can express the
> kinds of dynamic updates that are relevant in practice. Because a
> static type system always restricts what kinds of runtime behavior you
> can express in your language. I am still skeptical, because changing
> the types at runtime is basically changing the assumptions that the
> static type checker has used to check the program's types in the first
> place.
That's why I find the Erlang model to be more promising.
I am extremely skeptical of code mutation at runtime which would
"change types", because to me types are approximations of program
invariants. So if you do a modification that changes the types, it is
rather likely that you did something that also changed the invariants,
and existing code relying on those invariants will now break.
> For example, all the approaches that I have seen in statically typed
> languages deal with adding to a running program (say, class fields and
> methods, etc.), but not with changing to, or removing from it.
Of course, there are good reasons for that: removing fields or
changing their invariants requires that all /deployed/ code which
relied on their existence or their invariants must be made aware of
this change. This is a semantic problem which happens to reveal
itself as a typing problem. By making types dynamic, the problem does
not go away but is merely swept under the rug.
>>>> Note that prohibiting directly self-modifying code does not prevent a
>>>> program from specifying another program to *replace* it.
>>> ...and this creates problems with moving data from one version of a
>>> program to the next.
>> How does this "create" such a problem? The problem is there in
>> either
>> approach. In fact, I believe that the best chance we have of
>> addressing the problem is by adopting the "replace the code" model
>> along with a "translate the data where necessary at the time of
>> replacement". Translating the data, i.e., re-establishing the
>> invariants expected by the updated/replaced code, seems much harder
>> (to me) in the case of self-modifying code. Erlang got this one
>> right.
>
> ...and the "translate the date where necessary" approach is
> essentially triggered by a dynamic type test (if value x is of an old
> version of type T, update it to reflect the new version of type T
> [1]). QED.
But this test would have to already exist in code that was deployed
/before/ the change! How did this code know what to test for, and how
did it know how to translate the data? Plus, how do you detect that
some piece of data is "of an old version of type T"? If v has type T
and T "changes" (whatever that might mean), how can you tell that v's
type is "the old T" rather than "the new T"! Are there two different
Ts around now? If so, how can you say that T has changed?
The bottom line is that even the concept of "changing types at
runtime" makes little sense. Until someone shows me a /careful/
formalization that actually works, I just can't take it very
seriously.
------------------------------
Date: 28 Jun 2006 11:56:37 -0700
From: "Joe Marshall" <eval.apply@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151520997.731688.193710@p79g2000cwp.googlegroups.com>
David Hopwood wrote:
> Joe Marshall wrote:
> >
> > The point is that there exists (by construction) programs that can
> > never be statically checked.
>
> I don't think you've shown that. I would like to see a more explicit
> construction of a dynamically typed [*] program with a given specification,
> where it is not possible to write a statically typed program that meets
> the same specification using the same algorithms.
I think we're at cross-purposes here. It is trivial to create a static
type system that has a `universal type' and defers all the required
type narrowing to runtime. In effect, we've `turned off' the static
typing (because everything trivially type checks at compile time).
However, a sufficiently powerful type system must be incomplete or
inconsistent (by Godel). A type system proves theorems about a
program. If the type system is rich enough, then there are unprovable,
yet true theorems. That is, programs that are type-safe but do not
type check. A type system that could reflect on itself is easily
powerful enough to qualify.
> AFAIK, it is *always* possible to construct such a statically typed
> program in a type system that supports typerec or gradual typing. The
> informal construction you give above doesn't contradict that, because
> it depends on reflecting on a [static] type system, and in a dynamically
> typed program there is no type system to reflect on.
A static type system is usually used for universal proofs: For all
runtime values of such and such... Dynamic checks usually provide
existential refutations: This particular value isn't a string. It may
be the case that there is no universal proof, yet no existential
refutation.
>
> Note that I'm not claiming that you can check any desirable property of
> a program (that would contradict Rice's Theorem), only that you can
> express any dynamically typed program in a statically typed language --
> with static checks where possible and dynamic checks where necessary.
Sure. And I'm not saying that you cannot express these programs in a
static language, but rather that there exist programs that have
desirable properties (that run without error and produce the right
answer) but that the desirable properties cannot be statically checked.
The real question is how common these programs are, and what sort of
desirable properties are we trying to check.
------------------------------
Date: Wed, 28 Jun 2006 13:59:39 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m1irmlf6n8.fsf@hana.uchicago.edu>
"Marshall" <marshall.spight@gmail.com> writes:
> Matthias Blume wrote:
>>
>> How does this "create" such a problem? The problem is there in either
>> approach. In fact, I believe that the best chance we have of
>> addressing the problem is by adopting the "replace the code" model
>> along with a "translate the data where necessary at the time of
>> replacement". Translating the data, i.e., re-establishing the
>> invariants expected by the updated/replaced code, seems much harder
>> (to me) in the case of self-modifying code. Erlang got this one
>> right.
>
> Pardon my ignorance, but what is the Erlang solution to this problem?
Erlang relies on a combination of purity, concurrency, and message
passing, where messages can carry higher-order values.
Data structures are immutable, and each computational agent is a
thread. Most threads consist a loop that explicitly passes state
around. It dispatches on some input event, applies a state
transformer (which is a pure function), produces some output event (if
necessary), and goes back to the beginning of the loop (by
tail-calling itself) with the new state.
When a code update is necessary, a special event is sent to the
thread, passing along the new code to be executed. The old code, upon
receiving such an event, ceases to go back to its own loop entry point
(by simply not performing the self-tail-call). Instead it tail-calls
the new code with the current state.
If the new code can live with the same data structures that the old
code had, then it can directly proceed to perform real work. If new
invariants are to be established, it can first run a translation
function on the current state before resuming operation.
From what I hear from the Erlang folks that I have talked to, this
approach works extremely well in practice.
------------------------------
Date: Wed, 28 Jun 2006 21:06:06 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4gg291F1lsqo9U1@individual.net>
Matthias Blume wrote:
> Pascal Costanza <pc@p-cos.net> writes:
>
>>> And I am convinced that updating a running system in the style of,
>>> e.g., Erlang, can be statically typed.
>> Maybe. The interesting question then is whether you can express the
>> kinds of dynamic updates that are relevant in practice. Because a
>> static type system always restricts what kinds of runtime behavior you
>> can express in your language. I am still skeptical, because changing
>> the types at runtime is basically changing the assumptions that the
>> static type checker has used to check the program's types in the first
>> place.
>
> That's why I find the Erlang model to be more promising.
>
> I am extremely skeptical of code mutation at runtime which would
> "change types", because to me types are approximations of program
> invariants. So if you do a modification that changes the types, it is
> rather likely that you did something that also changed the invariants,
> and existing code relying on those invariants will now break.
...no, it will throw exceptions that you can catch and handle, maybe
interactively.
>> For example, all the approaches that I have seen in statically typed
>> languages deal with adding to a running program (say, class fields and
>> methods, etc.), but not with changing to, or removing from it.
>
> Of course, there are good reasons for that: removing fields or
> changing their invariants requires that all /deployed/ code which
> relied on their existence or their invariants must be made aware of
> this change. This is a semantic problem which happens to reveal
> itself as a typing problem. By making types dynamic, the problem does
> not go away but is merely swept under the rug.
...and yet this requirement sometimes comes up.
>>>>> Note that prohibiting directly self-modifying code does not prevent a
>>>>> program from specifying another program to *replace* it.
>>>> ...and this creates problems with moving data from one version of a
>>>> program to the next.
>>> How does this "create" such a problem? The problem is there in
>>> either
>>> approach. In fact, I believe that the best chance we have of
>>> addressing the problem is by adopting the "replace the code" model
>>> along with a "translate the data where necessary at the time of
>>> replacement". Translating the data, i.e., re-establishing the
>>> invariants expected by the updated/replaced code, seems much harder
>>> (to me) in the case of self-modifying code. Erlang got this one
>>> right.
>> ...and the "translate the date where necessary" approach is
>> essentially triggered by a dynamic type test (if value x is of an old
>> version of type T, update it to reflect the new version of type T
>> [1]). QED.
>
> But this test would have to already exist in code that was deployed
> /before/ the change! How did this code know what to test for, and how
> did it know how to translate the data?
In CLOS, the test is indeed already there from the beginning. It's part
of the runtime semantics. The translation of the data is handled by
'update-instance-for-redefined-class, which is a generic function for
which you can define your own methods. So this is user-extensible and
can, for example, be provided as part of the program update.
Furthermore, slot accesses typically go through generic functions (aka
setters and getters in other languages) for which you can provide
methods that can perform useful behavior in case the corresponding slots
have gone. These methods can also be provided as part of the program update.
Note that I am not claiming that CLOS provides the perfect solution, but
it seems to work reasonably well that people use it in practice.
> Plus, how do you detect that
> some piece of data is "of an old version of type T"? If v has type T
> and T "changes" (whatever that might mean), how can you tell that v's
> type is "the old T" rather than "the new T"! Are there two different
> Ts around now? If so, how can you say that T has changed?
Presumably, objects have references to their class metaobjects which
contain version information and references to more current versions of
themselves. This is not rocket science.
> The bottom line is that even the concept of "changing types at
> runtime" makes little sense. Until someone shows me a /careful/
> formalization that actually works, I just can't take it very
> seriously.
Maybe this feature just isn't made for you.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: Wed, 28 Jun 2006 21:33:05 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <lACog.230817$8W1.88545@fe1.news.blueyonder.co.uk>
Anton van Straaten wrote:
> Chris Smith wrote:
>
>> What makes static type systems interesting is not the fact that these
>> logical processes of reasoning exist; it is the fact that they are
>> formalized with definite axioms and rules of inference, performed
>> entirely on the program before execution, and designed to be entirely
>> evaluatable in finite time bounds according to some procedure or set
>> of rules, so that a type system may be checked and the same conclusion
>> reached regardless of who (or what) is doing the checking. All that,
>> and they still reach interesting conclusions about programs.
>
> There's only one issue mentioned there that needs to be negotiated
> w.r.t. latent types: the requirement that they are "performed entirely
> on the program before execution". More below.
>
>> If informal reasoning about types doesn't meet these criteria (and it
>> doesn't), then it simply doesn't make sense to call it a type system
>> (I'm using the static terminology here). It may make sense to discuss
>> some of the ways that programmer reasoning resembles types, if indeed
>> there are resemblances beyond just that they use the same basic rules
>> of logic. It may even make sense to try to identify a subset of
>> programmer reasoning that even more resembles... or perhaps even is...
>> a type system. It still doesn't make sense to call programmer
>> reasoning in general a type system.
>
> I'm not trying to call programmer reasoning in general a type system.
> I'd certainly agree that a programmer muddling his way through the
> development of a program, perhaps using a debugger to find all his
> problems empirically, may not be reasoning about anything that's
> sufficiently close to types to call them that. But "latent" means what
> it implies: someone who is more aware of types can do better at
> developing the latent types.
So these "latent types" may in some cases not exist (in any sense), unless
and until someone other than the original programmer decides how the program
could have been written in a typed language?
I don't get it.
> As a starting point, let's assume we're dealing with a disciplined
> programmer who (following the instructions found in books such as the
> one at htdp.org) reasons about types, writes them in his comments, and
> perhaps includes assertions (or contracts in the sense of "Contracts for
> Higher Order Functions[1]), to help check his types at runtime (and I'm
> talking about real type-checking, not just tag checking).
>
> When such a programmer writes a type signature as a comment associated
> with a function definition, in many cases he's making a claim that's
> provable in principle about the inputs and outputs of that function.
This is talking about a development practice, not a property of the
language. It may (for the sake of argument) make sense to assign a term
such as latent typing to this development practice, but not to call the
language "latently-typed".
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: 28 Jun 2006 12:52:12 -0700
From: jovo.miskin@sciatl.com
Subject: Re: WIN32 PPM and perldoc problems
Message-Id: <1151524332.914110.37030@j72g2000cwa.googlegroups.com>
The problem seem to be specific to passing arguments to system call.
Let' say we create a perl script called sys_args.pl that contanis the
next two lines:
#my $opt_exe = "ppm3-bin";
system($opt_exe, @ARGV);
And also we add at the top of ppm3-bin next two lines:
my $numargs = scalar @ARGV;
print "in ppm3_bin, numargs = $numargs\n";
The command line
sys_args.pl
produces output
in ppm3_bin, numargs = 1
The command line
sys_args.pl 1 2 3
produces output
in ppm3_bin, numargs = 1
Jovo
------------------------------
Date: Wed, 28 Jun 2006 22:28:53 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: WIN32 PPM and perldoc problems
Message-Id: <e7uvus.9s.1@news.isolution.nl>
jovo.miskin@sciatl.com schreef:
> I ahve installed Active Perl v5.8.7 build 813 on WindowsXP machine.
>
> Executing PPM gives this output:
> C:\Perl\bin>ppm
> Unknown or ambiguous command '*'; type 'help' for commands.
Try these:
C:> assoc .pl
C:> ftype Perl
C:> assoc .bat
C:> ftype batfile
I get these answers:
.pl=Perl
Perl="C:\Perl\bin\perl.exe" "%1" %*
.bat=batfile
batfile="%1" %*
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 V10 Issue 9403
***************************************
