Python from Wise Guy's Viewpoint

[ketil+news@ii.uib.no]

Re: Python from Wise Guy's Viewpoint

"Donn Cave" <donn@drizzle.c om> writes:
[color=blue]
> 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?[/color]

(This is Hugs, no?) One of the things I find much better now compared
to when I started with Haskell a couple of years ago are the error
messages of GHC -- and it will generally tell you exactly what to do
(add Show b to the context) in this case.

Then there's Helium, which has a simplified type system and primarily
tries to be helpful to beginners.

True, typing can give you difficult to comprehend error messages, but
this is obviously something developers take very seriously.

-kzm
--
If I haven't seen further, it is by standing in the footprints of giants

[Matthew Danish]

Re: Python from Wise Guy's Viewpoint

On Sat, Oct 25, 2003 at 12:37:38AM +0000, John Atwood wrote:[color=blue]
> Pascal Costanza <costanza@web.d e> wrote:
>[color=green]
> >- 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.[/color]

Wrong on all counts.

* Most Common Lisp environments compile to native code, even when
working interactively.
SBCL, for example, has no interpreter whatsoever. The interpreter is
simulated by calling the compiler and evaluating the resulting
function immediately.
* There exists statically typed language implementations which do the
same (SML/NJ)
* The behavior of redefinition in a statically typed environment
is far different from the behavior in a dynamically typed environment.
For one thing, generativity of names kicks in, which makes it
basically impossible to redefine types and functions without
recompiling all uses (and thus restarting your program), in a static
environment.

--
; 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."

[Nikodemus Siivola]

Re: Python from Wise Guy's Viewpoint

In comp.lang.lisp Marshall Spight <mspight@dnai.c om> wrote:
[color=blue]
> I'm having a hard time following you.[/color]

I have a guess about this. You seem -- by your references to Python --
to be implicitly assuming that Pascal, Joe &co are setting up Python
as the lightbearer of dynamism.

I find this rather unlikely, as most -- if not all -- of the
pro-dynamic side of this argument hail from Lisp, not Python.

Just a datapoint, since there seemed to be an unstated
misunderstandin g there.

Cheers,

-- Nikodemus

[Joachim Durchholz]

Re: Python from Wise Guy's Viewpoint

Marshall Spight wrote:
[color=blue]
> "Pascal Costanza" <costanza@web.d e> wrote:
>[color=green]
>>See the example of downcasts in Java.[/color]
>
> Downcasts in Java are not a source of problems.[/color]

Huh?
Alone the need to downcast whenever I take something out of a container
would suffice to term it as a "serious problem".
Unless you meant: it's not the downcasts that are the problem, it's the
many language mechanisms that require downcasts that are.

Regards,
Jo

[prunesquallor@comcast.net]

Re: Python from Wise Guy's Viewpoint

Dirk Thierbach <dthierbach@gmx .de> writes:
[color=blue]
> prunesquallor@c omcast.net wrote:[color=green]
>> Dirk Thierbach <dthierbach@gmx .de> writes:[/color]
>[color=green][color=darkred]
>>> Now why does a type system reject a program? Because there's a type
>>> mismatch in some branch if the program.[/color][/color]
>[color=green]
>> *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.[/color]

Only if you assume binary logic. If there are three values that
can arise --- provable-mismatch, provable-non-mismatch, and undecided
--- then you cannot assume that ~provable-mismatch = provable-non-mismatch.

My point is that type systems can reject valid programs.

[Brian McNamara!]

Re: Python from Wise Guy's Viewpoint

"Marshall Spight" <mspight@dnai.c om> once said:[color=blue]
><prunesquallor @comcast.net> wrote in message news:wuaufe52.f sf@comcast.net. ..[color=green]
>> "Marshall Spight" <mspight@dnai.c om> writes:[color=darkred]
>> > 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[/color]
....[color=blue]
>Anyone have any comments?[/color]

Well, in C++ you could say

template <class F, class A>
typename result_of<F(A)> ::type
noisy_apply( const F& f, const A& a ) {
cout << "I am now about to apply " << f << " to " << a << endl;
return f(a);
}

These assume that both "f" and "a" work with the out-streaming operator
(<<). This is just an ad-hoc version of what would be "class Show" in
Haskell. In C++ practice, most functions aren't "showable", but many
common data types are. So the most useful version of the function would
probably be

// This version works for all "f" and all Showable "a"
template <class F, class A>
typename result_of<F(A)> ::type
noisy_apply( const F& f, const A& a ) {
cout << "I am now about to apply a function with type "
<< typeid(f).name( ) << " to the value " << a << endl;
return f(a);
}

Again, provided that we have some notion of "class Show" in our
statically-typed language, then examples like these are easy to type.
(What dynamically-typed languages typically buy you is that every object
in the system provides some basic methods like toString(), which
eliminates the Show-able constraint that the statically-typed version
needs.)

--
Brian M. McNamara lorgon@acm.org : I am a parsing fool!
** Reduce - Reuse - Recycle ** : (Where's my medication? ;) )

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

"Joachim Durchholz" <joachim.durchh olz@web.de> wrote in message news:bndsch$764 $1@news.oberber g.net...[color=blue]
> Marshall Spight wrote:
>[color=green]
> > Downcasts in Java are not a source of problems.[/color]
>
> Huh?
> Alone the need to downcast whenever I take something out of a container
> would suffice to term it as a "serious problem".[/color]

Why? Here, you've assumed your conclusion. You've not given
me any reason. I will not accept any a priori criticisms of
downcasting except this one: downcasting requires the programmer
to type more characters.

Downcasts are not a source of problems in Java because
empirically, no problems result from them. (It's hard to
prove the absense of something, eh?) Years pass; hundreds
of thousands of lines of code are written, with no errors
arising from downcasting the result of ArrayList.get() .
That has been my experience.

Does the existence of downcasts point out a place where
Java is lame? Absolutely. Does extra effort result from
this lameness? Certainly. Does this extra effort cause
bugs? Nope.

(Anyway, the situation is much better with Java generics,
available now in prerelease form; mainsteam in the next
major version.)


Marshall

[Joachim Durchholz]

Re: Python from Wise Guy's Viewpoint

prunesquallor@c omcast.net wrote:
[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]

It wouldn't typecheck in Haskell because you don't restrict the elements
of the arglist to be of the "Show" type class, which is the group of
types that have a printable representation.

Other than that, the declaration of this function would be (in a
Pascal-inspired notation)

noisy_apply (f: function (x: a): b, x: a): b

Note that a and b are type parameters here: if noisy_apply is given a
function with input type a and output type b, it will /demand/ that its
second parameter is of type a, and its result type will be b.

I.e. in C++, you'd write something like

template <a, b> {
b noisy_apply ( (b) (f (a)), a x );
}

(syntax is most likely dead wrong, it's been a while since I was
actively working with C++).

For completeness, here's the Haskell type:

(a -> b) -> a -> b

(I hope I got this one right.)
The first "a -> b" translates as "a function that takes any type a and
returns any type b".
The x -> y -> z notations translates as "a function taking input values
of types x and y and returning a value of z type".
If the same type letter occurs more than once, if must be the same type
in calls.
(Yes, the function is polymorphic, though in a different way than OO
polymorphism: most OO languages don't allow expressing the restriction
that the two "a" parameters must be of the same type but the caller is
free to choose any type.)
To sum it all up: the above specifications are all intended to say the
same, namely "noisy_appl y is a function that takes an arbitrary
function, and another parameter that must be of the same type as the
input parameter for the supplied function, and that will return a value
of the same type as the supplied function will return".
Modern static type systems can express such types :-)


You might ask "where's the argument list"?
The answer is that I'm assuming a "currying" language. All functions in
such a language have a single argument; functions with multiple
arguments are written as a function that takes an argument and returns
another function which expects the next argument.

I.e.
add (3, 4)
is first evaluated as
[***] (4)
where [***] is an internally-created function that adds 3 to its single
argument.
(That's just the theory how the operation is defined. Currying languages
will usually be executed in the obvious manner, unless the code takes
specific advantage of currying.)


HTH
Jo

[Joachim Durchholz]

Re: Python from Wise Guy's Viewpoint

Marshall Spight wrote:
[color=blue]
> <prunesquallor@ comcast.net> wrote in message news:wuaufe52.f sf@comcast.net. ..
>[color=green]
>>"Marshall Spight" <mspight@dnai.c om> writes:
>>
>>(defun noisy-apply (f arglist)
>> (format t "I am now about to apply ~s to ~s" f arglist)
>> (apply f arglist))[/color]
>
> 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?[/color]

You're dead right: Java has insufficient support for typing this.

C++ would allow it, but the result isn't pretty either... which says a
lot about C++'s qualities for higher-order programming.

Regards,
Jo

[Marshall Spight]

Re: Python from Wise Guy's Viewpoint

<prunesquallor@ comcast.net> wrote in message news:ptgle760.f sf@comcast.net. ..[color=blue]
> Dirk Thierbach <dthierbach@gmx .de> writes:
>
> My point is that type systems can reject valid programs.[/color]

Agreed. But: does it matter? One thing that would help
in figuring out if it matters or not would be seeing a
small, useful program that cannot be proven typesafe.

If these programs are "all around us," and writing equivalent
typesafe programs is somewhat harder, then it matters.
If these programs are hard to come across, and writing
equivalent typesafe programs is easy, then this doesn't
matter.


Marshall

[Jon S. Anthony]

Re: Python from Wise Guy's Viewpoint

"Marshall Spight" <mspight@dnai.c om> writes:
[color=blue]
> <prunesquallor@ comcast.net> wrote in message news:wuaufe52.f sf@comcast.net. ..[color=green]
> > "Marshall Spight" <mspight@dnai.c om> writes:
> >[color=darkred]
> > > 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[/color]

Isn't Java a particularly bad thing to try here?
[color=blue]
> 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[/color]

As written, f can be any object of any type. arglist is any set of
arguments with arity 0 to <hardware limit>. It will do something
useful in all cases and something more useful if f is a function

/Jon

[Jon S. Anthony]

Re: Python from Wise Guy's Viewpoint

"Andreas Rossberg" <rossberg@ps.un i-sb.de> writes:
[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]

Your credibility just took a nose dive.

/Jon

[prunesquallor@comcast.net]

Re: Python from Wise Guy's Viewpoint

"Marshall Spight" <mspight@dnai.c om> writes:
[color=blue]
> <prunesquallor@ comcast.net> wrote in message news:ptgle760.f sf@comcast.net. ..[color=green]
>> Dirk Thierbach <dthierbach@gmx .de> writes:
>>
>> My point is that type systems can reject valid programs.[/color]
>
> Agreed. But: does it matter? One thing that would help
> in figuring out if it matters or not would be seeing a
> small, useful program that cannot be proven typesafe.[/color]

(defun lookup (item table if-found if-missing)
(cond ((null table) (funcall if-missing))
((eq item (entry-key (first-entry table)))
(funcall if-found (entry-value (first-entry table))))
(t (lookup item (remaining-entries table)
if-found
if-missing))))

(defun lookup-default (item local-table default-table if-found if-not-found)
(lookup item local-table
if-found
(lambda ()
(lookup item default-table if-found if-not-found))))

(defun transform-list (list local-table default-table if-ok if-fail)
(if (null list)
(funcall if-ok '())
(lookup-default (car list) local-table default-table
(lambda (result)
(transform-list (cdr list) local-table default-table
(lambda (remainder)
(funcall if-ok (cons result remainder)))
if-fail))
(lambda () (funcall if-fail (car list))))))

I know that simple static type checkers will be lost with this.
I do not know if the smarter ones will.

[prunesquallor@comcast.net]

Re: Python from Wise Guy's Viewpoint

gt5163b@prism.g atech.edu (Brian McNamara!) writes:
[color=blue]
> "Marshall Spight" <mspight@dnai.c om> once said:[color=green]
>><prunesquallo r@comcast.net> wrote in message news:wuaufe52.f sf@comcast.net. ..[color=darkred]
>>> "Marshall Spight" <mspight@dnai.c om> writes:
>>> > 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.
>>>
>>> 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[/color]
> ...[color=green]
>>Anyone have any comments?[/color]
>
> Well, in C++ you could say
>
> template <class F, class A>
> typename result_of<F(A)> ::type
> noisy_apply( const F& f, const A& a ) {
> cout << "I am now about to apply " << f << " to " << a << endl;
> return f(a);
> }
>[/color]

I don't mean to nitpick, but APPLY takes an arbitrary list of arguments.
How do you parameterize over that without enumerating the power set
of potential types?

What if F `returns' void?

[prunesquallor@comcast.net]

Re: Python from Wise Guy's Viewpoint

Joachim Durchholz <joachim.durchh olz@web.de> writes:
[color=blue]
> prunesquallor@c omcast.net wrote:
>[color=green]
>> "Marshall Spight" <mspight@dnai.c om> writes:
>>[color=darkred]
>>>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]
>
> To sum it all up: the above specifications are all intended to say the
> same, namely "noisy_appl y is a function that takes an arbitrary
> function, and another parameter that must be of the same type as the
> input parameter for the supplied function, and that will return a
> value of the same type as the supplied function will return".
> Modern static type systems can express such types :-)[/color]

Are they happy with something like this?

(defun black-hole (x)
#'black-hole)

(for non lispers, the funny #' is a namespace operator.
The black-hole function gobbles an argument and returns
the black-hole function.)