[28031] in Perl-Users-Digest
Perl-Users Digest, Issue: 9395 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Jun 27 18:10:16 2006
Date: Tue, 27 Jun 2006 15: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 Tue, 27 Jun 2006 Volume: 10 Number: 9395
Today's topics:
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <david.nospam.hopwood@blueyonder.co.uk>
Re: What is Expressiveness in a Computer Language <ole.nielsby@snailmail.dk>
Re: What is Expressiveness in a Computer Language <pc@p-cos.net>
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 <eval.apply@gmail.com>
Re: What is Expressiveness in a Computer Language <david.nospam.hopwood@blueyonder.co.uk>
Re: What is Expressiveness in a Computer Language <eval.apply@gmail.com>
Re: What is Expressiveness in a Computer Language <sleepingsquirrel@yahoo.com>
Re: WIN32 PPM and perldoc problems jovo.miskin@sciatl.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 27 Jun 2006 11:13:22 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151432002.905190.152470@y41g2000cwy.googlegroups.com>
Joe Marshall wrote:
> Marshall wrote:
> >
> > Yes, an important question (IMHO the *more* important question
> > than the terminology) is what *programs* do we give up if we
> > wish to use static typing? I have never been able to pin this
> > one down at all.
>
> It would depend on the type system, naturally.
Naturally!
> It isn't clear to me which programs we would have to give up, either.
> I don't have much experience in sophisticated typed languages. It is
> rather easy to find programs that baffle an unsophisticated typed
> language (C, C++, Java, etc.).
C and Java, certainly, but I'm wary these days about making
any statement about limitations on C++'s type system, for it is
subtle and quick to anger.
> Looking back in comp.lang.lisp, I see these examples:
>
> (defun noisy-apply (f arglist)
> (format t "I am now about to apply ~s to ~s" f arglist)
> (apply f arglist))
>
> (defun blackhole (argument)
> (declare (ignore argument))
> #'blackhole)
>
> But wait a sec. It seems that these were examples I invented in
> response to the same question from you!
Ah, how well I remember that thread, and how little I got from it.
My memories of that thread are
1) the troll who claimed that Java was unable to read two numbers from
standard input and add them together.
2) The fact that all the smart people agreed the blackhole
function indicated something profound.
3) The fact that I didn't understand the black hole function.
The noisy-apply function I think I understand; it's generic on the
entire arglist. In fact, if I read it correctly, it's even generic
on the *arity* of the function, which is actually pretty impressive.
True? This is an issue I've been wrestling with in my own type
system investigations: how to address genericity across arity.
Does noisy-apply get invoked the same way as other functions?
That would be cool.
As to the black hole function, could you explain it a bit? I apologize
for my lisp-ignorance. I am sure there is a world of significance
in the # ' on the third line, but I have no idea what it is.
> > > If you allow Turing Complete type systems, then I would say no--every
> > > bug can be reforumlated as a type error. If you require your type
> > > system to be less powerful, then some bugs must escape it.
> >
> > I don't think so. Even with a Turing complete type system, a program's
> > runtime behavior is still something different from its static behavior.
> > (This is the other side of the "types are not tags" issue--not only
> > is it the case that there are things static types can do that tags
> > can't, it is also the case that there are things tags can do that
> > static types can't.)
>
> I agree. The point of static checking is to *not* run the program. If
> the type system gets too complicated, it may be a de-facto interpreter.
Aha! A lightbulb just want off.
Consider that a program is a function parameterized on its input.
Static
analysis is exactly the field of what we can say about a program
without
know the values of its parameters.
Marshall
------------------------------
Date: Tue, 27 Jun 2006 18:48:01 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <B3fog.484799$xt.409283@fe3.news.blueyonder.co.uk>
Marshall wrote:
> David Hopwood wrote:
>>Marshall 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.
>>>
>>>So, how does this "dynamic" type work?
>>
>><http://citeseer.ist.psu.edu/abadi89dynamic.html>
>>
>>>It can't simply be the "any" type, because that type has no/few
>>>functions defined on it.
>>
>>It isn't. From the abstract of the above paper:
>>
>> [...] even in statically typed languages, there is often the need to
>> deal with data whose type cannot be determined at compile time. To handle
>> such situations safely, we propose to add a type Dynamic whose values are
>> pairs of a value v and a type tag T where v has the type denoted by T.
>> Instances of Dynamic are built with an explicit tagging construct and
>> inspected with a type safe typecase construct.
>
> Well, all this says is that the type "dynamic" is a way to explicitly
> indicate the inclusion of rtti. But that doesn't address my objection;
> if a typesafe typecase construct is required, it's not like using
> a dynamic language. They don't require typecase to inspect values
> before one can, say, invoke a function.
I was answering the question posed above: "are there some programs that
we can't write *at all* in a statically typed language...?"
>>"Gradual typing" as described in
>><http://www.cs.rice.edu/~jgs3847/pubs/pubs/2006/siek06:_gradual.pdf> is
>>another alternative. The difference between gradual typing and a
>>"dynamic" type is one of convenience rather than expressiveness --
>>gradual typing does not require explicit tagging and typecase constructs.
>
> Perhaps this is the one I should read; it sounds closer to what I'm
> talking about.
Right; convenience is obviously important, as well as expressiveness.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: Tue, 27 Jun 2006 23:00:01 +0200
From: "Ole Nielsby" <ole.nielsby@snailmail.dk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <44a19c52$0$15784$14726298@news.sunsite.dk>
David Hopwood <...nospam....uk> wrote:
> A good debugger is invaluable regardless of your attitude
> to type systems.
I found that certain language features help greatly in pinning
the errors, when programming in my own impure fp language
(PILS).
Originally, I implemented a single-stepping debugger for the
language, but I trashed it for three reasons, of which two are
rather uninteresting here: it messed up the GUI system, and the
evaluation order of PILS made single-stepping a confusing
experience.
The interesting reason is: I didn't need single-stepping, partly
because the programming system is unit-test friendly, partly
because of language features that seem to mimick the concept
of taking responsibility.
Basically, the PILS execution mechanism is pessimistic. When
a function is called, the assumption is it won't work, and the
only way the function can return a result is by throwing an
exception. So, if a function call doesn't throw an exception,
it has failed and execution will stop unless the function call
is explicitly marked as fault tolerant, as in
f (x) else "undefined"
This has been merged with tail call flattening - rather than
throwing the result, an (expression, binding) thing is thrown
(I guess .NET'ers would call it an anonymous parameterless
delegate), and the expression is then evaluated after the throw.
Mimickally speaking, when a function body performs this
throw, it takes responsibility for getting the job done, and
if it fails, it will suffer the peril of having its guts exposed
in public by the error message window - much like certain
medieval penal systems. I will spare you for the gory details,
just let me add that to honor the demands of modern
bureaucracy, I added a "try the other office" feature so that
there are ways of getting things done without ever taking
responsibility.
Strangely, this all started 20 years ago as I struggled
implementing an early PILS version on an 8-bit Z80
processor, at a blazing 4 MHz. I needed a fast way of
escaping from a failing pattern match, and it turned
out the conditional return operation of this particular
processor was the fastest I could get. Somehow, the
concept of "if it returns, it's bad" crept into the language
design. I was puzzled by its expressiveness and the ease
of using it, only years later did I realize that its ease
of use came from the mimicking of responsibility.
I'm still puzzled that the notion of mimicking a cultural/
social concept came from a microprocessor instruction.
It seems like I - and perhaps computer language designers
in general - have a blind spot. We dig physical objects and
mathematical theories, and don't take hints from the
"soft sciences"...
Perhaps I'm over-generalizing, it just strikes me that the
dispute always seems to stand between math versus object
orientation, with seemingly no systematic attempts at
utilizing insigts from the study of languages and cultural
concepts. It's like as if COBOL and VB scared us from
ever considering the prospect of making programming
languages readable to the uninitiated.
------------------------------
Date: Tue, 27 Jun 2006 23:02:11 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4gdkmiF1ldalhU3@individual.net>
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?
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: Tue, 27 Jun 2006 23:04:39 +0200
From: Pascal Costanza <pc@p-cos.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <4gdkr6F1ldalhU4@individual.net>
Marshall wrote:
> Joe Marshall wrote:
>> Marshall wrote:
>> It isn't clear to me which programs we would have to give up, either.
>> I don't have much experience in sophisticated typed languages. It is
>> rather easy to find programs that baffle an unsophisticated typed
>> language (C, C++, Java, etc.).
>
> C and Java, certainly, but I'm wary these days about making
> any statement about limitations on C++'s type system, for it is
> subtle and quick to anger.
>
>> Looking back in comp.lang.lisp, I see these examples:
>>
>> (defun noisy-apply (f arglist)
>> (format t "I am now about to apply ~s to ~s" f arglist)
>> (apply f arglist))
>>
>> (defun blackhole (argument)
>> (declare (ignore argument))
>> #'blackhole)
>>
> The noisy-apply function I think I understand; it's generic on the
> entire arglist. In fact, if I read it correctly, it's even generic
> on the *arity* of the function, which is actually pretty impressive.
> True? This is an issue I've been wrestling with in my own type
> system investigations: how to address genericity across arity.
>
> Does noisy-apply get invoked the same way as other functions?
> That would be cool.
>
> As to the black hole function, could you explain it a bit? I apologize
> for my lisp-ignorance. I am sure there is a world of significance
> in the # ' on the third line, but I have no idea what it is.
You can ignore the #'. In Scheme this as follows:
(define blackhole (argument)
blackhole)
It just means that the function blackhole returns the function blackhole.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
------------------------------
Date: Tue, 27 Jun 2006 21:25:53 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <Bnhog.485604$xt.51621@fe3.news.blueyonder.co.uk>
Joe Marshall wrote:
> It isn't clear to me which programs we would have to give up, either.
> I don't have much experience in sophisticated typed languages. It is
> rather easy to find programs that baffle an unsophisticated typed
> language (C, C++, Java, etc.).
>
> Looking back in comp.lang.lisp, I see these examples:
>
> (defun noisy-apply (f arglist)
> (format t "I am now about to apply ~s to ~s" f arglist)
> (apply f arglist))
'noisy-apply' is typeable using either of these systems:
<http://www.cs.jhu.edu/~pari/papers/fool2004/first-class_FOOL2004.pdf>
<http://www.coli.uni-saarland.de/publikationen/softcopies/Muller:1998:TIF.pdf>
(it should be easy to see the similarity to a message forwarder).
> (defun blackhole (argument)
> (declare (ignore argument))
> #'blackhole)
This is typeable in any system with universally quantified types (including
most practical systems with parametric polymorphism); it has type
"forall a . a -> #'blackhole".
>>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?
>
> Certainly! As soon as you can reflect on the type system you can
> construct programs that type-check iff they fail to type-check.
A program that causes the type checker not to terminate (which is the
effect of trying to construct such a thing in the type-reflective systems
I know about) is hardly useful.
In any case, I think the question implied the condition: "and that you
can write in a language with no static type checking."
[...]
>>>If you allow Turing Complete type systems, then I would say no--every
>>>bug can be reforumlated as a type error. If you require your type
>>>system to be less powerful, then some bugs must escape it.
>>
>>I don't think so. Even with a Turing complete type system, a program's
>>runtime behavior is still something different from its static behavior.
>>(This is the other side of the "types are not tags" issue--not only
>>is it the case that there are things static types can do that tags
>>can't, it is also the case that there are things tags can do that
>>static types can't.)
>
> I agree. The point of static checking is to *not* run the program. If
> the type system gets too complicated, it may be a de-facto interpreter.
The following LtU post:
<http://lambda-the-ultimate.org/node/1085>
argues that types should be expressed in the same language that is being
typed. I am not altogether convinced, but I can see the writer's point.
There do exist practical languages in which types can be defined as
arbitrary predicates or coercion functions, for example E (www.erights.org).
E implementations currently perform type checking only at runtime, however,
although it was intended to allow static analysis for types that could be
expressed in a conventional static type system. I think the delay in
implementing this has more to do with the E developers' focus on other
(security and concurrency) issues, rather than an inherent difficulty.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: 27 Jun 2006 14:26:31 -0700
From: "Joe Marshall" <eval.apply@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151443591.286204.16620@x69g2000cwx.googlegroups.com>
Marshall wrote:
> Joe Marshall wrote:
> > Looking back in comp.lang.lisp, I see these examples:
> >
> > (defun noisy-apply (f arglist)
> > (format t "I am now about to apply ~s to ~s" f arglist)
> > (apply f arglist))
> >
> > (defun blackhole (argument)
> > (declare (ignore argument))
> > #'blackhole)
> >
> > But wait a sec. It seems that these were examples I invented in
> > response to the same question from you!
>
> Ah, how well I remember that thread, and how little I got from it.
>
> My memories of that thread are
> 1) the troll who claimed that Java was unable to read two numbers from
> standard input and add them together.
> 2) The fact that all the smart people agreed the blackhole
> function indicated something profound.
> 3) The fact that I didn't understand the black hole function.
>
> The noisy-apply function I think I understand; it's generic on the
> entire arglist. In fact, if I read it correctly, it's even generic
> on the *arity* of the function, which is actually pretty impressive.
> True?
Yes.
> This is an issue I've been wrestling with in my own type
> system investigations: how to address genericity across arity.
>
> Does noisy-apply get invoked the same way as other functions?
> That would be cool.
Yes, but in testing I found an incompatability. Here's a better
definiton:
(defun noisy-apply (f &rest args)
(format t "~&Applying ~s to ~s." f (apply #'list* args))
(apply f (apply #'list* args)))
CL-USER> (apply #'+ '(2 3))
5
CL-USER> (noisy-apply #'+ '(2 3))
Applying #<function + 20113532> to (2 3).
5
The internal application of list* flattens the argument list. The
Common Lisp APPLY function has variable arity and this change makes my
NOISY-APPLY be identical.
> As to the black hole function, could you explain it a bit?
It is a function that takes any argument and returns the function
itself.
> I apologize
> for my lisp-ignorance. I am sure there is a world of significance
> in the # ' on the third line, but I have no idea what it is.
The #' is a namespace operator. Since functions and variables have
different namespaces, I'm indicating that I wish to return the function
named blackhole rather than any variable of the same name that might be
around.
------------------------------
Date: Tue, 27 Jun 2006 21:57:13 GMT
From: David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <ZQhog.486001$xt.89406@fe3.news.blueyonder.co.uk>
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.
There are, however, staged compilation systems that guarantee that
the generated program will be typeable if the first-stage program
is.
(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'.)
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>
------------------------------
Date: 27 Jun 2006 14:59:43 -0700
From: "Joe Marshall" <eval.apply@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151445583.367455.288650@m73g2000cwd.googlegroups.com>
QCD Apprentice wrote:
> Joe Marshall 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?
> >
> > Certainly! As soon as you can reflect on the type system you can
> > construct programs that type-check iff they fail to type-check.
>
> Sorry, but can you elaborate on this last point a little? I think I
> missed something.
This is just the halting problem lifted up into the type domain.
------------------------------
Date: 27 Jun 2006 14:59:57 -0700
From: "Greg Buchholz" <sleepingsquirrel@yahoo.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151445597.574064.319180@j72g2000cwa.googlegroups.com>
George Neuner wrote:
> That was interesting, but the authors' method still involves runtime
> checking of the array bounds. IMO, all they really succeeded in doing
> was turning the original recursion into CPS and making the code a
> little bit clearer.
Hmm. There is a comparison in both the DML and Haskell code, but
that's just there to make the binary search terminate correctly. The
point of the exercise is the line in the DML code "val m = (hi + lo)
div 2", or the "bmiddle" function in the Haskell code. If you change
that line to something like "val m = (hi + lo)" you'll get a compiler
error complaining about an unsolved constraint. The point of the
Haskell code is to use the type system to ensure that array indices
have a know provenance. They're derived from and statically associated
with each individual array, so you can't use an index from one array
with a different array. You'll probably also enjoy the paper...
"Eliminating Array Bound Checking Through Dependent Types"
http://citeseer.ist.psu.edu/xi98eliminating.html
...and DML itself...
http://www.cs.bu.edu/~hwxi/DML/DML.html
Greg Buchholz
------------------------------
Date: 27 Jun 2006 12:24:48 -0700
From: jovo.miskin@sciatl.com
Subject: Re: WIN32 PPM and perldoc problems
Message-Id: <1151436287.988799.247290@i40g2000cwc.googlegroups.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.
C:\Perl\bin>
------------------------------
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 9395
***************************************
