Python from Wise Guy's Viewpoint

[Jay O'Connor]

Re: Python from Wise Guy's Viewpoint

On Fri, 24 Oct 2003 18:18:25 -0700, prunesquallor wrote:
[color=blue]
> "Andreas Rossberg" <rossberg@ps.un i-sb.de> writes:
>[color=green]
>> Sorry, but that reply of yours somewhat indicates that you haven't
>> really used modern type systems seriously.
>>
>> All decent type systems allow you to define your own types. You can
>> express any domain-specific abstraction you want in types. Hence the
>> type language gives you additional expressive power wrt the problem
>> domain.[/color]
>
> Cool! So I can declare `Euclidean rings' as a type an ensure that I
> never pass a non-Euclidean ring to a function?[/color]


In Ada, you can

--
Jay O'Connor

http://www.deskofsolomon.com

- Online organizational software for teachers

[Jay O'Connor]

Re: Python from Wise Guy's Viewpoint

On Fri, 24 Oct 2003 19:29:56 -0700, Jay O'Connor wrote:
[color=blue]
> On Fri, 24 Oct 2003 18:18:25 -0700, prunesquallor wrote:
>[color=green]
>> "Andreas Rossberg" <rossberg@ps.un i-sb.de> writes:
>>[color=darkred]
>>> Sorry, but that reply of yours somewhat indicates that you haven't
>>> really used modern type systems seriously.
>>>
>>> All decent type systems allow you to define your own types. You can
>>> express any domain-specific abstraction you want in types. Hence the
>>> type language gives you additional expressive power wrt the problem
>>> domain.[/color]
>>
>> Cool! So I can declare `Euclidean rings' as a type an ensure that I
>> never pass a non-Euclidean ring to a function?[/color]
>
>
> In Ada, you can[/color]

Ooops...


--
Jay O'Connor

http://www.deskofsolomon.com

- Online organizational software for teachers

[prunesquallor@comcast.net]

Re: Python from Wise Guy's Viewpoint

Jay O'Connor <joconnor@cyber mesa.com> writes:
[color=blue]
> On Fri, 24 Oct 2003 19:29:56 -0700, Jay O'Connor wrote:
>[color=green]
>> On Fri, 24 Oct 2003 18:18:25 -0700, prunesquallor wrote:
>>[color=darkred]
>>> "Andreas Rossberg" <rossberg@ps.un i-sb.de> writes:
>>>
>>>> Sorry, but that reply of yours somewhat indicates that you haven't
>>>> really used modern type systems seriously.
>>>>
>>>> All decent type systems allow you to define your own types. You can
>>>> express any domain-specific abstraction you want in types. Hence the
>>>> type language gives you additional expressive power wrt the problem
>>>> domain.
>>>
>>> Cool! So I can declare `Euclidean rings' as a type an ensure that I
>>> never pass a non-Euclidean ring to a function?[/color]
>>
>>
>> In Ada, you can[/color]
>
> Ooops...[/color]

Yeah, my innocent sounding question often hide some nasty pitfalls.

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Adrian Hey" <ahey@NoSpicedH am.iee.org> wrote in message news:bnci76$5ic $1$8300dec7@new s.demon.co.uk.. .[color=blue]
>
> I have a my own pet theories to explain the current exitement about
> dynamically typed languages. Here they are..[/color]

Nice analysis. I particularly liked:
[color=blue]
> But some language developers don't want to get to bogged down with
> all that difficult and boring theory stuff for however many months
> or years it takes.[/color]


Your ideas are probably biased, but your biases match mine, so
there you are.


Marshall

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Marshall Spight wrote:[color=blue]
> "Pascal Costanza" <costanza@web.d e> wrote in message news:bnc3cj$pv0 $1@f1node01.rhr z.uni-bonn.de...
>[color=green]
>>class C {
>> void m();
>>}
>>
>>class D {
>> void m();
>>}
>>
>>...
>>
>>void doSomething (Object o) {
>> if (o instanceof C) {
>> ((D)o).m();
>> }
>>}
>>
>>"Oops, by accident method m is also defined in D, although I wanted to
>>call method m in C."
>>
>>Doesn't happen in languages with proper name space management. (The
>>problem is that Java gives you only the illusion of well-behaved
>>namespaces. )[/color]
>
>
> The above code in Java would fail at runtime. What do you think it
> ought to do? What would it do in Python? How is this superior to
> what Java does? Do you consider this a real-world example?[/color]

You should be able to choose unique names in the first place. The
problem Java has here is that there is no safe way to avoid that in
general. There is a risk of name clashes here.

There is some information about one way to properly deal with namespaces
at

http://www.cs.northwestern.edu/academics/courses/325/readings/packages.html

There are also other approaches. For example, there exist several module
systems for Scheme. (I don't know a lot about them, though.)

I don't know how Python handles potential name conflicts.
[color=blue]
> Does the fact that you didn't respond to the other items
> in my post mean you are no longer holding the position that
> "explicitly cast[ing] objects" "is one of the sources for potential bugs
> that you don't have in a decent dynamically typed language."[/color]

No.

Pascal

[Pascal Costanza]

Re: Test cases and static typing

Dirk Thierbach wrote:
[color=blue]
> Pascal Costanza <costanza@web.d e> wrote:
>
>[color=green]
>>A flexible and useful IDE must treat static type checking as a separate
>>tool. It needs to be able to do useful things with code that isn't
>>correct yet.[/color]
>
> I don't agree with the "must", but type checking is a seperate phase
> in the compiler. It should be possible to make an IDE that treats
> it that way. But I doubt that particular point is high on the priority
> list of any potential programmer of an IDE.[/color]

No, it's only high on the priority list of actual programmers of IDEs.
For example, you could check what Eclipse has to offer for Java in that
regard.
[color=blue][color=green]
>>And that's all I wanted from the very beginning - static typing as an
>>additional tool, not as one that I don't have any other choice than use
>>by default.[/color]
>
> And that's fine, but it is not an issue of static typing.
>[color=green][color=darkred]
>>>>>>The type system might test too many cases.[/color][/color]
>[color=green]
>>No, it's not better to give an example in a different language. The
>>whole point of my argument is that the code above cannot be statically
>>type-checked.[/color]
>
> You can look now at two examples of code like this that can be
> statically type-checked.[/color]

I am not convinced, but let's play that game for a while: OK, we have
three programs that have the same behavior, and they especially all
behave well. Only two of them can be statically type checked.

This completes my proof that static type systems reduce expressive power.
[color=blue]
> And I had the impression that you wanted to explain why a "type system
> might test too many cases". I still don't understand this argument. I
> don't see any "case" that the type system will test in the above
> program, let alone "too many".
>[color=green][color=darkred]
>>>I could probably rewrite the code with an approximation to cerror
>>>(with the restriction that non-local control structures don't
>>>translate one to one), but even then I don't see why the type system
>>>would test too many cases for this example.[/color][/color]
>[color=green]
>>I don't want an "approximat ion of cerror". I want cerror![/color]
>
> Then use Lisp and cerror. Nobody forces you to use anything else. The
> problem is again that you want to do it only in exactly the same way
> as you are used to doing it. You don't see how to do it in another
> language, and then you say "it cannot be done". And that's just wrong.[/color]

I don't say it cannot be done. Don't put words into my mouth.

In this case, you actually need to write additional code to simulate
dynamic checks in a statically typed language that a dynamically typed
language gives you for free. I am sorry, but I don't see any advantage
in such an approach.
[color=blue]
> So can we settle on "you like to do it your way, but it is possible
> to do everything you want in a statically typed language if
> you're a little bit more flexible"? (That means of course that if
> you refuse to be a bit more flexible, it cannot be done in exactly
> the same way -- after all, they are different languages.)[/color]

Well, in my book the computer should adapt to what I want, and not the
other way around.
[color=blue]
> As long as you say "this cannot be done" you'll get answers showing
> you that it can indeed be done, only in a way that is a little bit
> different. Then you say "yes, but that's not how I want it. You're
> trying to force to use me something I don't want!".[/color]

No, I haven't said it cannot be done. I have talked about expressive
power, and that's something different.
[color=blue]
> It gets a bit silly after some iterations.[/color]

Indeed.


Pascal

[Pascal Costanza]

Re: Python from Wise Guy's Viewpoint

Andreas Rossberg wrote:
[color=blue][color=green]
>>An increase of expressive power of the static type checker decreases the
>>expressive power of the target language, and vice versa.[/color]
>
>
> That's a contradiction, because the type system is part of the "target"
> language. You cannot separate them, because the type system is more then
> just a static analysis phase - you can program it.[/color]

For christ's sake, the only interesting question here is: do statically
typed languages increase or decrease the set of programs that behave
well at runtime?


Pascal

[John Atwood]

Re: Python from Wise Guy's Viewpoint

Pascal Costanza <costanza@web.d e> wrote:
[color=blue]
>- when a test case gives me an exception, I can inspect the runtime
>environment and analyze how far the test case got, what it already
>successfully did, what is missing, and maybe even why it is missing.
>With a statically typed language, I wouldn't be able to get that far.
>
>Furthermore, when I am still in the exceptional situation, I can change
>variable settings, define a function on the fly, return some value from
>a yet undefined method by hand to see if it can make the rest of the
>code work, and so on.[/color]

That's because you're in an interpreted environemt, not because you're
using a dynamically typed language. Interpreters for statically typed
languages allow the same.

John

[Donn Cave]

Re: Python from Wise Guy's Viewpoint

Quoth Adrian Hey <ahey@NoSpicedH am.iee.org>:
| ketil+news@ii.u ib.no wrote:
|> While Mr. Martin probably should get out more, I must admit that I
|> have a nagging feeling about typing and object orientation. Somebody
|> else correlated typing with imperativity, and I suspect dynamic typing
|> is a better match for OO than static typing. But I'm probably making
|> the common error of comparing with the rather pedestrian type systems
|> of C++ and Java, perhaps O'Haskell and OCaml have systems that work
|> better?
|
| I have a my own pet theories to explain the current exitement about
| dynamically typed languages. Here they are..
|
| 1- Most of this buzz comes from OO folk, many of whom will only have
| (bad) experience of static typing from C/C++/Java.

That is true for sure with at least some of them.

While your other two theories were interesting, I think most of
it is essentially psychological. I am quite sure that some people
react to static typing with a deep personal resentment. Static
typing is discipline. It would be interesting to see how it flies
in different cultural contexts, say US vs. Japan.

But the value in not blaming it all on C++ et al. is that it gives
us some reasons to think about whether Haskell et al. are really
doing all they can to make static typing work for everyone. Like,

ERROR "hello.hs": 8 - Unresolved top-level overloading
*** Binding : main
*** Outstanding context : Show b

Not to get into the details here, but is someone who takes our
hint here and checks out Haskell really headed for a terrific
demonstration of how modern static typing is an easy and fun way
to increase programming productivity? It really is at least a
little harder than we would like to understand type errors like
this, let's admit. A significant factor in the success of languages
like Python is that their shallow learning curve allows the typical
beginner (someone who has used another language) to write a useful
program after literally a few minutes of study of the language.
People like that, they don't like frustration. Psychological thing,
as I said, but possibly something that FPLs could work on.

As for O'Haskell and Objective CAML ... I find O'Haskell really
interesting, but in my view it isn't particularly about OOP
programming in any conventional sense. Objective CAML is, but
someone else will have to tell us how well it works as an OOPL.

Donn Cave, donn@drizzle.co m

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Pascal Costanza" <costanza@web.d e> wrote in message news:bncp01$au7 $1@newsreader2. netcologne.de.. .[color=blue]
> Marshall Spight wrote:[color=green]
> >
> > The above code in Java would fail at runtime. What do you think it
> > ought to do? What would it do in Python? How is this superior to
> > what Java does? Do you consider this a real-world example?[/color]
>
> You should be able to choose unique names in the first place. The
> problem Java has here is that there is no safe way to avoid that in
> general. There is a risk of name clashes here.[/color]

Grrr. You didn't answer any of my questions. (Except the one
about Python, for which you said you didn't know.) Or maybe
your response is meant to be an answer to one or more of
them, only I can't tell which or how.

I'm having a hard time following you. Also, you seem to be
shifting what you're talking about quite frequently, which
makes me suspicious.

At this stage I've entirely lost track of the thread. Ah, well.

[color=blue][color=green]
> > Does the fact that you didn't respond to the other items
> > in my post mean you are no longer holding the position that ...[/color]
>
> No.[/color]

I didn't think so. :-)


Marshall

[Dirk Thierbach]

Re: Python from Wise Guy's Viewpoint

prunesquallor@c omcast.net wrote:[color=blue]
> Dirk Thierbach <dthierbach@gmx .de> writes:[/color]
[color=blue][color=green]
>> Now why does a type system reject a program? Because there's a type
>> mismatch in some branch if the program.[/color][/color]
[color=blue]
> *or* because the type system was unable to prove that there *isn't* a
> type mismatch in *all* branches.[/color]

I am not sure if I read this correctly, but it seems equivalent to what
I say.

\exists branch. mismatch-in (branch)

should be the same as

\not \forall branch. \not mismatch-in (branch)

Anyway, I don't understand your point.

(Hindley-Milner typechecking works by traversing the expression tree
in postfix order, matching types on binary application nodes. Typing
fails if and only if such a match fails (ignoring constraints or
similar extensions for the moment) If a match fails, there's a problem
in this branch).

- Dirk

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

<prunesquallor@ comcast.net> wrote in message news:wuaufe52.f sf@comcast.net. ..[color=blue]
> "Marshall Spight" <mspight@dnai.c om> writes:
>[color=green]
> > It would be really interesting to see a small but useful example
> > of a program that will not pass a statically typed language.
> > It seems to me that how easy it is to generate such programs
> > will be an interesting metric.[/color]
>
> Would this count?
>
> (defun noisy-apply (f arglist)
> (format t "I am now about to apply ~s to ~s" f arglist)
> (apply f arglist))[/color]

Interesting, interesting. Thanks for taking me seriously!

I'm trying to map this program into Java, and it's possible
but there are enough different ways to go about it that
I'm having a hard time reasoning about the result.

For one thing, what would f be? Probably an instance of
a class that implements a specific interface. But then,
implementing a specific interface is like saying we
know what type f is. Is it a function that takes a
single argument of type Object? If we concede
all those points, then this is fairly easy to map
into Java. If we say that f can take any single argument
then we can do it with reflection if we are willing
to add 15 lines of code, which is certainly not pretty.
If it can take any number of arguments then it's
looking triply awful now.

It's starting to feel like this is merely a demonstration
of Java's weakness in generic programming, and
not something hooked into Goedel.

Anyone have any comments?


Marshall

[Thomas Lindgren]

Re: Python from Wise Guy's Viewpoint


"Marshall Spight" <mspight@dnai.c om> writes:
[color=blue]
> "Kenny Tilton" <ktilton@nyc.rr .com> wrote in message news:Zn7mb.3548 3$pT1.33385@twi ster.nyc.rr.com ...[color=green]
> >
> > Lights out for static typing.[/color]
>
> That kind of statement reminds me a lot of the people
> who were saying in 1985 that CISC computing was
> dead.[/color]

Because Intel ultimately triumphed over the pundits advocating another
solution?

Because differences in instruction set architecture due to
implementation advances ultimately became irrelevant for
high-performance computers? (Meaning all non-embedded ones, that is.)

Because a big, somewhat worse standard (x86) beat a squabbling horde of
somewhat better contenders (RISCs)?

Because the marketplace moved on from "workstatio ns", stranding the
high-cost, high-performance systems in favour of low-cost,
nearly-same-performance systems? Which then overtook the former
champions.

Something else?

Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Thomas Lindgren" <***********@** ***.***> wrote in message news:m3ad7p33e7 .fsf@localhost. localdomain...[color=blue]
>
> "Marshall Spight" <mspight@dnai.c om> writes:
>[color=green][color=darkred]
> > > Lights out for static typing.[/color]
> >
> > That kind of statement reminds me a lot of the people
> > who were saying in 1985 that CISC computing was
> > dead.[/color]
>
> Because [...] ?[/color]

Because at no time did CISC machines ever fall below 95%
market share.

[color=blue]
> Because a big, somewhat worse standard (x86) beat a squabbling horde of
> somewhat better contenders (RISCs)?[/color]

Hey, x86 is a *lot* worse! :-)


Marshall

[Matthew Danish]

Re: Python from Wise Guy's Viewpoint

On Sat, Oct 25, 2003 at 02:47:28AM +0200, Andreas Rossberg wrote:[color=blue]
> It is not, because Lisp hasn't been designed with types in mind. It is
> pretty much folklore that retrofitting a type system onto an arbitrary
> language will not work properly. For example, Lisp makes no distinction
> between tuples and lists, which is crucial for type inference.[/color]

Tell that to the hackers who worked on the "Python" compiler found in
CMUCL, SBCL, and some others. It does extensive type inference for both
efficiency and correctness. But it doesn't get in the way (except in
certain rare cases), it just (noisely) informs you what it thinks.

Tell that to the people who wrote Chapter 4 of the Common Lisp standard.

http://www.lispworks.com/reference/HyperSpec/Body/04_.htm

[color=blue]
> If you want to have extensible overloading then static types are the only
> way I know for resolving it. Witness Haskell for example. It has a very
> powerful overloading mechanism (for which the term 'overloading' actually is
> an understatement) . It could not possibly work without static typing, which
> is obvious from the fact that Haskell does not even have an untyped
> semantics.[/color]

Correction: it could not work without typing--dynamic typing does not
imply a lack of typing. I could be wrong, but it seems you would rule
out generic functions in the CLOS (and dynamic dispatch in general) with
the above statement.
[color=blue]
> Erasing type information from a program that uses type abstraction to
> guarantee certain post conditions will invalidate those post conditions. So
> you get a program with a different meaning. It expresses something
> different, so the types it contained obviously had some expressive power.[/color]

This doesn't sound right: erasing type information should not invalidate
the post conditions; it should simply make it more difficult
(impossible?) to check the validity of the post conditions.

This program should still work, even if you fail to type-check it, if
said type-checking would have passed successfully.
[color=blue]
> Erasing type information from a program that uses overloading simply makes
> it ambiguous, i.e. takes away any meaning at all. So the types definitely
> expressed something relevant.[/color]

This statement is irrelevant because dynamic typing does not eliminate
type information.

--
; Matthew Danish <mdanish@andrew .cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian. org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."