[27998] in Perl-Users-Digest
Perl-Users Digest, Issue: 9362 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 23 18:15:17 2006
Date: Fri, 23 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 Fri, 23 Jun 2006 Volume: 10 Number: 9362
Today's topics:
Re: What is Expressiveness in a Computer Language <robert.thorpe@antenova.com>
Re: What is Expressiveness in a Computer Language <rvtol+news@isolution.nl>
Re: What is Expressiveness in a Computer Language <chris.uppal@metagnostic.REMOVE-THIS.org>
Re: What is Expressiveness in a Computer Language rossberg@ps.uni-sb.de
Re: What is Expressiveness in a Computer Language <cdsmith@twu.net>
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 <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>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 23 Jun 2006 11:12:00 -0700
From: "Rob Thorpe" <robert.thorpe@antenova.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151086320.564736.272500@y41g2000cwy.googlegroups.com>
rossberg@ps.uni-sb.de wrote:
> Rob Thorpe wrote:
> >
> > But it differs from latently typed languages like python, perl or lisp.
> > In such a language there is no information about the type the variable
> > stores. The programmer cannot write code to test it, and so can't
> > write functions that issue errors if given arguments of the wrong type.
> > The programmer must use his or her memory to substitute for that
> > facility. As far as I can see this is a significant distinction and
> > warrants a further category for latently typed languages.
>
> Take one of these languages. You have a variable that is supposed to
> store functions from int to int. Can you test that a given function
> meets this requirement?
The answer is no for python and perl AFAIK. Also no for lisp _aux
naturelle_ (you can do it by modifying lisp though of-course, I believe
you can make it entirely statically typed if you want).
But the analogous criticism could be made of statically typed
languages.
Can I make a type in C that can only have values between 1 and 10?
How about a variable that can only hold odd numbers, or, to make it
more difficult, say fibonacci numbers?
> You see, IMO the difference is marginal. From my point of view, the
> fact that you can do such tests *in some very trivial cases*
They are not very trivial for practical programming purposes though,
they are important.
> in the
> languages you mention is an artefact, nothing fundamental.
The cases can be far from trivial. In lisp a type specifier can mean
something like "argument must be a 10x10 matrix with top corner element
larger than 35" You can also, for example, easily make predicates that
tell if a value is odd, or a fibonacci number.
The system simply extends in different directions.
------------------------------
Date: Fri, 23 Jun 2006 21:30:18 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <e7hmnh.1ds.1@news.isolution.nl>
Chris Smith schreef:
> Static types are not fuzzy
Static types can be fuzzy as well. For example: a language can define
that extra accuracy and bits may be used for the implementation of
calculations: d = a * b / c
Often some minimum is guaranteed.
> I see it as quite reasonable when there's an effort by several
> participants in this thread to either imply or say outright that
> static type systems and dynamic type systems are variations of
> something generally called a "type system", and given that static
> type systems are quite formally defined, that we'd want to see a
> formal definition for a dynamic type system before accepting the
> proposition that they are of a kind with each other.
The 'dynamic type' is just another type.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Fri, 23 Jun 2006 19:41:37 +0100
From: "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <449c4826$0$657$bed64819@news.gradwell.net>
Marshall wrote:
[me:]
> > But, as a sort of half-way, semi-formal, example: consider the type
> > environment in a Java runtime. The JVM does formal type-checking of
> > classfiles as it loads them. In most ways that checking is static --
> > it's treating the bytecode as program text and doing a static analysis
> > on it before allowing it to run (and rejecting what it can't prove to
> > be acceptable by its criteria). However, it isn't /entirely/ static
> > because the collection of classes varies at runtime in a (potentially)
> > highly dynamic way. So it can't really examine the "whole" text of the
> > program -- indeed there is no such thing. So it ends up with a hybrid
> > static/dynamic type system -- it records any assumptions it had to make
> > in order to find a proof of the acceptability of the new code, and if
> > (sometime in the future) another class is proposed which violates those
> > assumptions, then that second class is rejected.
>
> I have to object to the term "hybrid".
>
> Java has a static type system.
> Java has runtime tags and tag checks.
It has both, agreed, but that isn't the full story. I think I explained what I
meant, and why I feel the term is justified as well as I can in the second half
of the paragraph you quoted. I doubt if I can do better.
Maybe you are thinking that I mean that /because/ the JVM does verification,
etc, at "runtime" the system is hybrid ?
Anyway that is /not/ what I mean. I'm (for these purposes) completely
uninterested in the static checking done by the Java to bytecode translator,
javac. I'm interested in what happens to the high-level, statically typed, OO,
language called "java bytecode" when the JVM sees it. That language has a
strict static type system which the JVM is required to check. That's a
/static/ check in my book -- it happens before the purportedly correct code is
accepted, rather than while that code is running.
I am also completely uninterested (for these immediate purposes) in the run
time checking that the JVM does (the stuff that results in
NoSuchMethodException, and the like). In the wider context of the thread, I do
want to call that kind of thing (dynamic) type checking -- but those checks are
not why I call the JVMs type system hybrid either.
Oh well, having got that far, I may as well take another stab at "hybrid".
Since the JVM is running a static type system without access to the whole text
of the program, there are some things that it is expected to check which it
can't. So it records preconditions on classes which might subsequently be
loaded. Those are added to the static checks on future classes, but -- as far
as the original class is concerned -- those checks happen dynamically. So part
of the static type checking which is supposed to happen, has been postponed to
a dynamic check. It's that, and /only/ that which I meant by "hybrid".
Of course, /if/ we grant that runtime checking of the sort done by Smalltalk or
Lisp also constitutes a "type system" in some sense that puts it on a par with
static type checking, then that would be another, very different, reason to
claim that Java had a hybrid type system (though, in fact, I'd rather claim
that it had two independent type systems). But that's the bigger question
point under discussion here and I wasn't trying to beg it by using the word
"hybrid".
-- chris
------------------------------
Date: 23 Jun 2006 13:02:19 -0700
From: rossberg@ps.uni-sb.de
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151092939.711328.280740@p79g2000cwp.googlegroups.com>
Rob Thorpe write:
> >
> > Take one of these languages. You have a variable that is supposed to
> > store functions from int to int. Can you test that a given function
> > meets this requirement?
>
> The answer is no for python and perl AFAIK. Also no for lisp _aux
> naturelle_ (you can do it by modifying lisp though of-course, I believe
> you can make it entirely statically typed if you want).
>
> But the analogous criticism could be made of statically typed
> languages.
> Can I make a type in C that can only have values between 1 and 10?
> How about a variable that can only hold odd numbers, or, to make it
> more difficult, say fibonacci numbers?
Fair point. However, there are in fact static type systems powerful
enough to express all of this and more (whether they are convenient
enough in practice is a different matter). On the other hand, AFAICS,
it is principally impossible to express the above property on functions
with tags or any other purely dynamic mechanism.
> The cases can be far from trivial. In lisp a type specifier can mean
> something like "argument must be a 10x10 matrix with top corner element
> larger than 35" You can also, for example, easily make predicates that
> tell if a value is odd, or a fibonacci number.
Now, these are yet another beast. They are not tags, they are
user-defined predicates. I would not call them types either, but that's
an equally pointless battle. :-)
- Andreas
------------------------------
Date: Fri, 23 Jun 2006 14:13:07 -0600
From: Chris Smith <cdsmith@twu.net>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <MPG.1f05f9415a672d0c9896ee@news.altopia.net>
Dr.Ruud <rvtol+news@isolution.nl> wrote:
> Chris Smith schreef:
>
> > Static types are not fuzzy
>
> Static types can be fuzzy as well. For example: a language can define
> that extra accuracy and bits may be used for the implementation of
> calculations: d = a * b / c
> Often some minimum is guaranteed.
Who cares how many bits are declared by the type? Some specific
implementation may tie that kind of representation information to the
type for convenience, but the type itself is not affected by how many
bits are used by the representation. The only thing affected by the
representation is the evaluation semantics and the performance of the
language, both of which only come into play after it's been shown that
the program is well-typed.
> The 'dynamic type' is just another type.
That's essentially equivalent to giving up. I doubt many people would
be happy with the conclusion that dynamically typed languages are typed,
but have only one type which is appropriate for all possible operations.
That type system would not be implemented, since it's trivial and
behaves identically to the lack of a type system, and then we're back
where we started.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
------------------------------
Date: 23 Jun 2006 13:36:06 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151094966.249077.284610@m73g2000cwd.googlegroups.com>
Chris Uppal wrote:
> David Hopwood wrote:
>
> > > But some of the advocates of statically
> > > typed languages wish to lump these languages together with assembly
> > > language a "untyped" in an attempt to label them as unsafe.
> >
> > A common term for languages which have defined behaviour at run-time is
> > "memory safe". For example, "Smalltalk is untyped and memory safe."
> > That's not too objectionable, is it?
>
> I find it too weak, as if to say: "well, ok, it can't actually corrupt memory
> as such, but the program logic is still apt go all over the shop"...
It is impossible to evaluate your claim without a specific definition
of "go all over the shop." If it means subject to Method Not
Understood,
then we would have to say that Smalltalk can in fact go all over
the shop. If it means subject to memory corruption, then it can't.
In any event, the denotation is quite clear: Smalltalk does not
formally assign types to expressions during a static analysis
phase, and Smalltalk is not subject to memory corruption.
I have a problem with the whole line of reasoning that goes
"someone might think term x means something bad, so we
can't use it." It's unfalsifiable. It also optimizes for malicious
use of the terms. Both are bad properties to have as design
principles, at least in this context.
Marshall
------------------------------
Date: 23 Jun 2006 14:12:26 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151097146.910247.56170@g10g2000cwb.googlegroups.com>
Andreas Rossberg wrote:
>
> ... And the reason is that "type" has a
> well-established use in theory. It is not just my "assumption", it is
> established practice since 80 or so years.
Wouldn't it be fair to say it goes back a least to
Principia Mathematica, 1910?
> So far, this discussion has
> not revealed the existence of any formal work that would provide a
> theory of "dynamic types" in the sense it is used to characterise
> "dynamically typed" languages.
Indeed, the idea I am starting to get is that much of what is going
on in the dynamic/latent/untyped/whatever world is simply informal,
conceptual-level static analysis. The use of the runtime system
is a formal assistant to this informal analysis. In other words,
formal existential quantification is used as hint to help do
informal universal quantification.
Now, given that explanation, the formal analysis looks better.
But that's not the whole story. We also have the fact that
the informal analysis gets to run on the human brain, while
the static analysis has to run on a lousy microprocessor
with many orders of magnitude less processing power.
We have the fact that the formal static analysis is of
limited power. We have the fact that historically,
static languages have forbidden the use of the formal
existential method preferred by the DT crowd until
*after* the static analysis has passed, thus defeating
their purpose. And probably still more things that I
don't appreciate yet. So I'll now throw around some
terms (in an attempt to look smart :-) and say,
late binding, impredicativity.
Marshal
------------------------------
Date: 23 Jun 2006 14:37:35 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151098655.828408.286630@y41g2000cwy.googlegroups.com>
Joe Marshall wrote:
> Marshall wrote:
> > Joe Marshall wrote:
> > >
> > > That's the important point: I want to run broken code.
> >
> > I want to make sure I understand. I can think of several things
> > you might mean by this. It could be:
> > 1) I want to run my program, even though I know parts of it
> > are broken, because I think there are parts that are not broken
> > and I want to try them out.
>
> I think I mean a little of each of these.
>
> Nearly *every* program I have ever used is buggy, so this is actually a
> normal state of affairs even when I'm not debugging or developing.
That makes some sense to me.
It seems quite reasonable, as a language feature, to be
able to say to the computer: I know there are a few type
errors; just run this damn program as best you can.
> > 2) I want to run my program, even though it is broken, and I
> > want to run right up to a broken part and trap there, so I can
> > use the runtime facilities of the language to inspect what's
> > going on.
>
> I do this quite often. Sometimes I'll develop `in the debugger'. I'll
> change some piece of code and run the program until it traps. Then,
> without exiting the debugger, I'll fix the immediate problem and
> restart the program at the point it trapped. This technique takes a
> bit of practice, but if you are working on something that's complex and
> has a lot of state, it saves a lot of time because you don't have to
> reconstruct the state every time you make a change.
Wow, interesting.
(I say the following only to point out differing strategies of
development, not to say one or the other is right or bad or
whatever.)
I occasionally find myself doing the above, and when I do,
I take it as a sign that I've screwed up. I find that process
excruciating, and I do everything I can to avoid it. Over the
years, I've gotten more and more adept at trying to turn
as many bugs as possible into type errors, so I don't have
to run the debugger.
Now, there might be an argument to be made that if I had
been using a dynamic language, the process wouldn't be
so bad, and I woudn't dislike it so much. But mabe:
As a strawman: suppose there are two broad categories
of mental strategies for thinking about bugs, and people
fall naturally into one way or the other, the way there
are morning people and night people. One group is
drawn to the static analysis, one group hates it.
One group hates working in the debugger, one group
is able to use that tool very effectively and elegantly.
Anyway, it's a thought.
> > > I want to run
> > > as much of the working fragments as I can, and I want a `safety net' to
> > > prevent me from performing undefined operations, but I want the safety
> > > net to catch me at the *last* possible moment.
> >
> > This statement is interesting, because the conventional wisdom (at
> > least as I'm used to hearing it) is that it is best to catch bugs
> > at the *first* possible moment. But I think maybe we're talking
> > about different continua here. The last last last possible moment
> > is after the software has shipped to the customer, and I'm pretty
> > sure that's not what you mean. I think maybe you mean something
> > more like 2) above.
>
> It is often the case that the proximate cause of a bug is nowhere near
> where the fix needs to be applied. This is especially true with the
> really hard bugs. A static type system will tell me that there (may)
> exist a path through the code that results in an error, but the runtime
> check that fails will provide a witness.
Ah, the witness! I see the witness idea as supporting my thesis
that some people are using formal existential reasoning as a
tool for informal universal reasoning.
Very interesting. I want to again emphasize that I am not
interested in labelling one or the other of these approaches
as better or worse; rather, I want to understand both of
them, particularly to see if it is possible to have a single
language that incorporate both approaches.
This is not to say that I don't find one approach more appealing
than the other; rather it is to assert that I can tell the difference
between my personal preference and Truth. (Sometimes.)
Marshall
------------------------------
Date: 23 Jun 2006 14:44:11 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151099051.667267.202730@g10g2000cwb.googlegroups.com>
Joe Marshall wrote:
> Marshall wrote:
> > Timo Stamm wrote:
> > >
> > > This is actually one of the most interesting threads I have read in a
> > > long time. If you ignore the evangelism, there is a lot if high-quality
> > > information and first-hand experience you couldn't find in a dozen books.
> >
> > Hear hear! This is an *excellent* thread. The evangelism is at
> > rock-bottom
> > and the open exploration of other people's way of thinking is at what
> > looks to me like an all-time high.
>
> What are you, some sort of neo-static pseudo-relational
> object-disoriented fascist?
I prefer to think in terms of "object orientatedness."
But you're close. I'd say rather that I'm a quasi-theoretical,
neo-relational, crypto-logical fascist. But definitely fascist.
Once after a lengthy debate with a schemer, he
dubbed me (good naturedly) "Il Duce." Heh.
Marshall
------------------------------
Date: 23 Jun 2006 14:52:59 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151099579.205144.145130@r2g2000cwb.googlegroups.com>
Darren New wrote:
> Marshall wrote:
> > I can't see how you'd call + on a and b if you think they might
> > not be numbers.
>
> Now substitute "<" for "+" and see if you can make the same argument. :-)
If your point is about overloading, then I don't see how it affects my
point. My point was, I don't see why you'd be writing code using
operators that you thought might not be applicable to the operands.
Marshall
------------------------------
Date: 23 Jun 2006 15:00:23 -0700
From: "Marshall" <marshall.spight@gmail.com>
Subject: Re: What is Expressiveness in a Computer Language
Message-Id: <1151100023.126405.56230@c74g2000cwc.googlegroups.com>
Chris Smith wrote:
> Marshall <marshall.spight@gmail.com> wrote:
> > Ouch; I have a really hard time understanding this.
> >
> > I can't see how you'd call + on a and b if you think they might
> > not be numbers. If they could be something other than numbers,
> > and you're treating them as if they are, is that sort of like
> > doing a case analysis and only filling in one of the cases?
> > If so, wouldn't you want to record that fact somehow?
>
> The obvious answer -- I don't know if it's what Pascal meant -- is that
> they might be 4x4 matrices, or anything else that behaves predictably
> under some operation that could be called addition. As a mathematical
> analogy, the entire mathematical field of group theory comes from the
> idea of performing operations on values without really knowing what the
> values (or the operations) really are, but only knowing a few axioms by
> which the relationship between the objects and the operation is
> constrained.
>
> [As an interesting coincidence, group theory papers frequently use the
> addition symbol to represent the (arbitrary) binary relation of an
> Abelian group. Not that this has anything to do with choosing "+" for
> the example here.]
Sure. This is what abstract algebra is all about; group theory is
just an example. In particular, much of Stepanov's life work
has been developing abstract algebra within the framework
of a static type system.
http://www.stepanovpapers.com/
In particular, see the paper "Greatest Common Measure, the
Last 2500 Years."
> Programming languages do this all the time, as well. The most popular
> example is the OO sense of the word polymorphism. That's all about
> being able to write code that works with a range of values regardless of
> (or, at least, a range that less constraining than equlity in) types.
Exactly.
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 9362
***************************************
