[27979] in Perl-Users-Digest
Perl-Users Digest, Issue: 9343 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 22 11:10:13 2006
Date: Thu, 22 Jun 2006 08:10:06 -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 Thu, 22 Jun 2006 Volume: 10 Number: 9343
Today's topics:
Re: What is Expressiveness in a Computer Language <find@my.address.elsewhere>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Re: What is Expressiveness in a Computer Language <chris.uppal@metagnostic.REMOVE-THIS.org>
Re: What is Expressiveness in a Computer Language <chris.uppal@metagnostic.REMOVE-THIS.org>
Re: What is Expressiveness in a Computer Language <marshall.spight@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 22 Jun 2006 08:54:44 -0500
From: Matthias Blume <find@my.address.elsewhere>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <m2d5d18fdn.fsf@hanabi.local>
Pascal Bourguignon <pjb@informatimago.com> writes:
> Moreover, a good proportion of the program and a good number of
> algorithms don't even need to know the type of the objects they
> manipulate.
>
> For example, sort doesn't need to know what type the objects it sorts
> are. It only needs to be given a function that is able to compare the
> objects.
Of course, some statically typed languages handle this sort of thing
routinely.
> Only a few "primitive" functions need specific types.
Your sort function from above also has a specific type -- a type which
represents the fact that the objects to be sorted must be acceptable
input to the comparison function.
> So basically, you've got a big black box of applicaition code in the
> middle that doesn't care what type of value they get, and you've got a
> few input values of a specific type, a few processing functions
> needing a specific type and returning a specific type, and a few
> output values that are expected to be of a specific type. At anytime,
> you may change the type of the input values, and ensure that the
> needed processing functions will be able to handle this new input
> type, and the output gets mapped to the expected type.
...or you type-check your "black box" and make sure that no matter how
you will ever change the type of the inputs (in accordance with the
interface type of the box) you get a valid program.
------------------------------
Date: 22 Jun 2006 07:18:25 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150985905.819268.250640@c74g2000cwc.googlegroups.com>
Rob Warnock wrote:
> Marshall <marshall.spight@gmail.com> wrote:
> >
> > Can you be more explicit about what "latent types" means?
> > I'm sorry to say it's not at all natural or intuitive to me.
> > Are you referring to the types in the programmers head,
> > or the ones at runtime, or what?
>
> Here's what the Scheme Standard has to say:
>
> http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-4.html
> 1.1 Semantics
> ...
> Scheme has latent as opposed to manifest types. Types are assoc-
> iated with values (also called objects) rather than with variables.
> (Some authors refer to languages with latent types as weakly typed
> or dynamically typed languages.) Other languages with latent types
> are APL, Snobol, and other dialects of Lisp. Languages with manifest
> types (sometimes referred to as strongly typed or statically typed
> languages) include Algol 60, Pascal, and C.
>
> To me, the word "latent" means that when handed a value of unknown type
> at runtime, I can look at it or perform TYPE-OF on it or TYPECASE or
> something and thereby discover its actual type at the moment[1], whereas
> "manifest" means that types[2] are lexically apparent in the code.
Hmmm. If I read the R5RS text correctly, it is simply doing the
either/or thing that often happens with "static/dynamic" only
using different terms. I don't see any difference between
"latent" and "dynamic." Also, this phrase "types associated with
values instead of variables" that I'm starting to see a lot is
beginning to freak me out: the implication is that other languages
have types associated with variables and not values, which
doesn't describe anything I can think of.
In your followup paragraph, you've contrasted runtime type
introspection, vs. explicit type declarations, which seem
orthorgonal to me. (Not that you said they weren't.)
Marshall
------------------------------
Date: 22 Jun 2006 07:35:01 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150986901.299913.139200@m73g2000cwd.googlegroups.com>
Pascal Costanza wrote:
>
> A statically type language requires you to think about two models of
> your program at the same time: the static type model and the dynamic
> behavioral model. A static type system ensures that these two
> _different_ (that's important!) perspectives are always in sync. This is
> especially valuable in settings where you know your domain well and want
> to rely on feedback by your compiler that you haven't made any mistakes
> in encoding your knowledge. (A static type system based on type
> inferencing doesn't essentially change the requirement to think in two
> models at the same time.)
>
> A dynamically typed language is especially well suited when you don't
> (yet) have a good idea about your domain and you want to use programming
> especially to explore that domain. Some static typing advocates claim
> that static typing is still suitable for exploring domains because of
> the compiler's feedback about the preliminary encoding of your
> incomplete knowledge, but the disadvantages are a) that you still have
> to think about two models at the same time when you don't even have
> _one_ model ready and b) that you cannot just run your incomplete
> program to see what it does as part of your exploration.
>
> A statically typed language with a dynamic type treats dynamic typing as
> the exception, not as the general approach, so this doesn't help a lot
> in the second setting (or so it seems to me).
>
> A language like Common Lisp treats static typing as the exception, so
> you can write a program without static types / type checks, but later on
> add type declarations as soon as you get a better understanding of your
> domain. Common Lisp implementations like CMUCL or SBCL even include
> static type inference to aid you here, which gives you warnings but
> still allows you to run a program even in the presence of static type
> errors. I guess the feedback you get from such a system is probably not
> "strong" enough to be appreciated by static typing advocates in the
> first setting (where you have a good understanding of your domain).
I am sceptical of the idea that when programming in a dynamically
typed language one doesn't have to think about both models as well.
I don't have a good model of the mental process of working
in a dynamically typed language, but how could that be the case?
(I'm not asking rhetorically.) Do you then run your program over
and over, mechanically correcting the code each time you discover
a type error? In other words, if you're not thinking of the type model,
are you using the runtime behavior of the program as an assistant,
the way I use the static analysis of the program as an assistant?
I don't accept the idea about pairing the appropriateness of each
system according to whether one is doing exploratory programming.
I do exploratory programming all the time, and I use the static type
system as an aide in doing so. Rather I think this is just another
manifestation of the differences in the mental processes between
static typed programmers and dynamic type programmers, which
we are beginning to glimpse but which is still mostly unknown.
Oh, and I also want to say that of all the cross-posted mega threads
on static vs. dynamic typing, this is the best one ever. Most info;
least flames. Yay us!
Marshall
------------------------------
Date: 22 Jun 2006 07:50:52 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150987852.784870.7610@y41g2000cwy.googlegroups.com>
Andreas Rossberg wrote:
> Marshall wrote:
> >
> > What prohibits us from describing an abstract type as a set of values?
>
> If you identify an abstract type with the set of underlying values then
> it is equivalent to the underlying representation type, i.e. there is no
> abstraction.
I don't follow. Are you saying that a set cannot be described
intentionally? How is "the set of all objects that implement the
Foo interface" not sufficiently abstract? Is it possible you are
mixing in implementation concerns?
> >>There were papers observing this as early as 1970.
> >
> > References?
>
> This is 1973, actually, but most relevant:
>
> James Morris
> Types Are Not Sets.
> Proc. 1st ACM Symposium on Principles of Programming Languages, 1973
Okay. Since this paper is in the ACM walled garden, I'll have to
wait until next week to get a look at it. But thanks for the reference.
> >>(There are also theoretic problems with the types-as-sets view, because
> >>sufficiently rich type systems can no longer be given direct models in
> >>standard set theory. For example, first-class polymorphism would run
> >>afoul the axiom of foundation.)
> >
> > There is no reason why we must limit ourselves to "standard set theory"
> > any more than we have to limit ourselves to standard type theory.
> > Both are progressing, and set theory seems to me to be a good
> > choice for a foundation. What else would you use?
>
> I'm no expert here, but Category Theory is a preferred choice in many
> areas of PLT.
Fair enough.
Marshall
------------------------------
Date: Thu, 22 Jun 2006 15:49:15 +0100
From: "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <449aaea0$0$656$bed64819@news.gradwell.net>
Andreas Rossberg wrote:
[me:]
> > It's worth noting, too, that (in some sense) the type of an object can
> > change over time[*].
>
> No. Since a type expresses invariants, this is precisely what may *not*
> happen. If certain properties of an object may change then the type of
> the object has to reflect that possibility. Otherwise you cannot
> legitimately call it a type.
Well, it seems to me that you are /assuming/ a notion of what kinds of logic
can be called type (theories), and I don't share your assumptions. No offence
intended.
Actually I would go a little further than that. Granted that whatever logic
one wants to apply in order to prove <whatever> about a program execution is
abstract -- and so timeless -- that does not (to my mind) imply that it must be
/static/. However, even if we grant that additional restriction, that doesn't
imply that the analysis itself must not be cognisant of time. I see no reason,
even in practise, why a static analysis should not be able to see that the set
of acceptable operations (for some definition of acceptable) for some
object/value/variable can be different at different times in the execution. If
the analysis is rich enough to check that the temporal constraints are [not]
satisfied, then I don't see why you should want to use another word than "type"
to describe the results of its analysis.
-- chris
------------------------------
Date: Thu, 22 Jun 2006 15:49:57 +0100
From: "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <449aaea0$1$656$bed64819@news.gradwell.net>
I wrote:
> It would be interesting to see what a language designed specifically to
> support user-defined, pluggable, and perhaps composable, type systems
> would look like.
Since writing that I've come across some thoughts by Gilad Bracha (a Name known
to Java and Smalltalk enthusiasts alike) here:
http://blogs.sun.com/roller/page/gbracha?entry=a_few_ideas_on_type
and a long, and occasionally interesting, related thread on LtU:
http://lambda-the-ultimate.org/node/1311
Not much discussion of concrete language design, though.
-- chris
------------------------------
Date: 22 Jun 2006 08:03:45 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1150988625.527780.148710@c74g2000cwc.googlegroups.com>
Pascal Costanza wrote:
>
> Consider a simple expression like 'a + b': In a dynamically typed
> language, all I need to have in mind is that the program will attempt to
> add two numbers. In a statically typed language, I additionally need to
> know that there must a guarantee that a and b will always hold numbers.
I still don't really see the difference.
I would not expect that the dynamic programmer will be
thinking that this code will have two numbers most of the
time but sometimes not, and fail. I would expect that in both
static and dynamic, the thought is that that code is adding
two numbers, with the difference being the static context
gives one a proof that this is so. In this simple example,
the static case is better, but this is not free, and the cost
of the static case is evident elsewhere, but maybe not
illuminated by this example.
This thread's exploration of the mindset of the two kinds
of programmers is difficult. It is actually quite difficult,
(possibly impossible) to reconstruct mental states
though introspection. Nonetheless I don't see any
other way to proceed. Pair programming?
> My goal is not to convince anyone, my goal is to illustrate for those
> who are interested in getting a possibly different perspective.
Yes, and thank you for doing so.
Marshall
------------------------------
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 9343
***************************************
