[28035] in Perl-Users-Digest
Perl-Users Digest, Issue: 9399 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Jun 28 11:10:15 2006
Date: Wed, 28 Jun 2006 08:10:08 -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: 9399
Today's topics:
Re: What is Expressiveness in a Computer Language <david.nospam.hopwood@blueyonder.co.uk>
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: What is Expressiveness in a Computer Language <pc@p-cos.net>
Re: What is Expressiveness in a Computer Language <find@my.address.elsewhere>
Re: What is Expressiveness in a Computer Language <rossberg@ps.uni-sb.de>
Re: WIN32 PPM and perldoc problems jovo.miskin@sciatl.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 28 Jun 2006 11:11:23 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <vttog.230289$8W1.53535@fe1.news.blueyonder.co.uk>
Paul Rubin wrote:
> David Hopwood <david.nospam.hopwood@blueyonder.co.uk> writes:
>
>>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.
>
> It starts to look like sufficiently powerful static type systems are
> confusing enough, that programming with them is at least as bug-prone
> as imperative programming in dynamically typed languages. The static
> type checker can spot type mismatches at compile time, but the
> types themselves are easier and easier to get wrong.
My assertion above does not depend on having a "sufficiently powerful static
type system" to express a given dynamically typed program. It is true for
static type systems that are not particularly complicated, and suffice to
express all dynamically typed programs.
I disagree with your implication that in general, static type systems for
practical languages are getting too confusing, but that's a separate issue.
(Obviously one can find type systems in research proposals that are too
confusing as they stand.)
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Wed, 28 Jun 2006 14:52:37 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4gfcclF1mpbg7U1@individual.net>
David Hopwood wrote:
> Pascal Costanza wrote:
>> David Hopwood wrote:
>>> Marshall wrote:
>>>
>>>> The real question is, are there some programs that we
>>>> can't write *at all* in a statically typed language, because
>>>> they'll *never* be typable?
>>> In a statically typed language that has a "dynamic" type, all
>>> dynamically typed programs are straightforwardly expressible.
>> What about programs where the types change at runtime?
>
> Staged compilation is perfectly compatible with static typing.
> Static typing only requires that it be possible to prove absence
> of some category of type errors when the types are known; it
> does not require that all types are known before the first-stage
> program is run.
Can you change the types of the program that is already running, or are
the levels strictly separated?
> There are, however, staged compilation systems that guarantee that
> the generated program will be typeable if the first-stage program
> is.
...and I guess that this reduces again the kinds of things you can express.
> (It's clear that to compare the expressiveness of statically and
> dynamically typed languages, the languages must be comparable in
> other respects than their type system. Staged compilation is the
> equivalent feature to 'eval'.)
If it is equivalent to eval (i.e., executed at runtime), and the static
type checker that is part of eval yields a type error, then you still
get a type error at runtime!
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: Wed, 28 Jun 2006 14:21:54 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <6gwog.488405$xt.80841@fe3.news.blueyonder.co.uk>
Pascal Costanza wrote:
> David Hopwood wrote:
>> Pascal Costanza wrote:
>>> David Hopwood wrote:
>>>> Marshall wrote:
>>>>
>>>>> The real question is, are there some programs that we
>>>>> can't write *at all* in a statically typed language, because
>>>>> they'll *never* be typable?
>>>>
>>>> In a statically typed language that has a "dynamic" type, all
>>>> dynamically typed programs are straightforwardly expressible.
>>>
>>> What about programs where the types change at runtime?
>>
>> Staged compilation is perfectly compatible with static typing.
>> Static typing only requires that it be possible to prove absence
>> of some category of type errors when the types are known; it
>> does not require that all types are known before the first-stage
>> program is run.
>
> Can you change the types of the program that is already running, or are
> the levels strictly separated?
In most staged compilation systems this is intentionally not permitted.
But this is not a type system issue. You can't change the types in a
running program because you can't change the program, period. And you
can't do that because most designers of these systems consider directly
self-modifying code to be a bad idea (I agree with them).
Note that prohibiting directly self-modifying code does not prevent a
program from specifying another program to *replace* it.
>> There are, however, staged compilation systems that guarantee that
>> the generated program will be typeable if the first-stage program
>> is.
>
> ...and I guess that this reduces again the kinds of things you can express.
Yes. If you don't want that, use a system that does not impose this
restriction/guarantee.
>> (It's clear that to compare the expressiveness of statically and
>> dynamically typed languages, the languages must be comparable in
>> other respects than their type system. Staged compilation is the
>> equivalent feature to 'eval'.)
>
> If it is equivalent to eval (i.e., executed at runtime), and the static
> type checker that is part of eval yields a type error, then you still
> get a type error at runtime!
You can choose to use a system in which this is impossible because only
typeable programs can be generated, or one in which non-typeable programs
can be generated. In the latter case, type errors are detected at the
earliest possible opportunity, as soon as the program code is known and
before any of that code has been executed. (In the case of eval, OTOH,
the erroneous code may cause visible side effects before any run-time
error occurs.)
I don't know what else you could ask for.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Wed, 28 Jun 2006 16:44:31 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4gfiufF1mg6h9U1@individual.net>
David Hopwood wrote:
> Pascal Costanza wrote:
>> David Hopwood wrote:
>>> Pascal Costanza wrote:
>>>> David Hopwood wrote:
>>>>> Marshall wrote:
>>>>>
>>>>>> The real question is, are there some programs that we
>>>>>> can't write *at all* in a statically typed language, because
>>>>>> they'll *never* be typable?
>>>>> In a statically typed language that has a "dynamic" type, all
>>>>> dynamically typed programs are straightforwardly expressible.
>>>> What about programs where the types change at runtime?
>>> Staged compilation is perfectly compatible with static typing.
>>> Static typing only requires that it be possible to prove absence
>>> of some category of type errors when the types are known; it
>>> does not require that all types are known before the first-stage
>>> program is run.
>> Can you change the types of the program that is already running, or are
>> the levels strictly separated?
>
> In most staged compilation systems this is intentionally not permitted.
> But this is not a type system issue. You can't change the types in a
> running program because you can't change the program, period. And you
> can't do that because most designers of these systems consider directly
> self-modifying code to be a bad idea (I agree with them).
Whether you consider something you cannot do with statically typed
languages a bad idea or not is irrelevant. You were asking for things
that you cannot do with statically typed languages.
There are at least systems that a lot of people rely on (the JVM, .NET)
that achieve runtime efficiency primarily by executing what is
essentially self-modifying code. These runtime optimization systems have
been researched primarily for the language Self, and also implemented in
Strongtalk, CLOS, etc., to various degrees.
Beyond that, I am convinced that the ability to update a running system
without the need to shut it down can be an important asset.
> 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.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: Wed, 28 Jun 2006 09:53:01 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m1r719fi2a.fsf@hana.uchicago.edu>
Pascal Costanza <pc@p-cos.net> writes:
> Whether you consider something you cannot do with statically typed
> languages a bad idea or not is irrelevant. You were asking for things
> that you cannot do with statically typed languages.
The whole point of static type systems is to make sure that there are
things that one cannot do. So the fact that there are such things are
not an argument per se against static types.
[ ... ]
> Beyond that, I am convinced that the ability to update a running
> system without the need to shut it down can be an important asset.
And I am convinced that updating a running system in the style of,
e.g., Erlang, can be statically typed.
>> 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.
------------------------------
Date: Wed, 28 Jun 2006 16:35:31 +0200
From: Andreas Rossberg <rossberg@ps.uni-sb.de>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7u43j$9a1av$3@hades.rz.uni-saarland.de>
David Hopwood wrote:
>
> (In the case of eval, OTOH,
> the erroneous code may cause visible side effects before any run-time
> error occurs.)
Not necessarily. You can replace the primitive eval by compile, which
delivers a function encapsulating the program, so you can check the type
of the function before actually running it. Eval itself can easily be
expressed on top of this as a polymorphic function, which does not run
the program if it does not have the desired type:
eval ['a] s = typecase compile s of
f : (()->'a) -> f ()
_ -> raise TypeError
- Andreas
------------------------------
Date: 28 Jun 2006 07:03:49 -0700
From: jovo.miskin@sciatl.com
Subject: Re: WIN32 PPM and perldoc problems
Message-Id: <1151503429.834578.294230@b68g2000cwa.googlegroups.com>
Ben Morrow wrote:
> Quoth jovo.miskin@sciatl.com:
> >
> > I've tried it. The output is the same.
> > C:\Perl\bin>perldoc.bat -f gmtime
> > Syntax error
> >
> > C:\Perl\bin>
> >
> > I beleive, that both problems, perldoc and ppm are of the same nature
> > concerning
> > some sort command line interpreter compatibility issue.
> >
> > This is ppm output:
> > C:\Perl\bin>ppm
> > Unknown or ambiguous command '*'; type 'help' for commands.
>
> My (wild, unsupported) guess from this is that your .BAT association has
> got messed up. It should look something like (from memory)
>
> c:\winnt\system32\cmd.exe "%*"
>
> : is the % missing?
>
> Ben
>
> --
> Joy and Woe are woven fine,
> A Clothing for the Soul divine William Blake
> Under every grief and pine 'Auguries of Innocence'
> Runs a joy with silken twine. benmorrow@tiscali.co.uk
Ben,
The .BAT association is, I beleive, fine. I have a number of Windows XP
machines, not suffering from ths problem, and a few machine exhibiting
this problem. All
of them have .BAT association set in the same way with "%1" %*.
Jovo
------------------------------
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 9399
***************************************
