Typed Python?

[Matthias]

If Python programmers don't think they have a need for pattern
matching, it's merely because they did not stumble yet on problems
where it fits.

No. It's because they don't know the concept and don't know what they
are missing.

Nobody missed OOP before it was invented. People just created
workarounds and crutches to solve problems where OOP would have been a
fit. It's not until an OOP-trained person moves to a language without
support for OOP until they realize how complicated and inelegant
things can get. (Then they might start simulating OOP one way or
another, but it's never quite the right thing.)

So, in this respect Wittgenstein applies:
"The boundaries of my language are the boundaries of my world."

Matthias

 

[Peter Hansen]

Contrarily, it took me no more than a day or two to really like the
Smalltalk language and its environment.

This is the same experience some of us had with Python...

 

[Paramjit Oberoi]

This is the same experience some of us had with Python...

The language: Python is wonderful, and I took to it more naturally than to
Smalltalk. But, the Smalltalk environment (Squeak is the only one I have
tried) is *really* quite amazing. I recommend playing with it a bit just
to get an idea of What Could Be even if you never intend to use it for
anything substantial.

 

[Donn Cave]

No. It's because they don't know the concept and don't know what they
are missing.

Nobody missed OOP before it was invented. People just created
workarounds and crutches to solve problems where OOP would have been a
fit. It's not until an OOP-trained person moves to a language without
support for OOP until they realize how complicated and inelegant
things can get. (Then they might start simulating OOP one way or
another, but it's never quite the right thing.)

So, in this respect Wittgenstein applies:
"The boundaries of my language are the boundaries of my world."

That's true, but it seems to imply that these concepts
have their own intrinsic virtue, independent of the
language within which they might be deployed.

If Python started as an ordinary procedural language and
added its OOP features later, I'm sure that would have
been cause for real celebration. In Python, the virtues
of OOP are clear. But if you look at Objective CAML, a
functional programming language with an elaborate, very
respectable OOP infrastructure, I think you would find
people tending to steer clear of OOP features. At least
that's my casual impression. It takes some effort to
learn, it has a slight performance cost compared to the
very efficient functional idioms, and it isn't really
essential outside of a few special areas of programming,
like graphic UI toolkits. I think it will probably remain
alone as a fully functional OOP functional programming
language, and the rest of the FPL world may forever say
nobody missed OOP even after it was invented.

I think pattern matching may be a bit like that from the
other direction. This feature couldn't be removed from
ML or Haskell family languages without mortal injury, but
that's about more than just their proclivity towards
recursive functions (?!) Pattern matching is integral
to their type systems, which gets into a large and complex
area of differences between them and Python. The main
application I'm thinking of is the sum type - an enumerated
union type. For example, Haskell functions often return
a parameterized "maybe" type, which may have a value of
either Nothing or Just a, where a is the parameter type.
The pattern matching feature dispatches on a type like
that - for example,

case (findone xyz) of
Nothing -> "not found"
Just t -> t

which elegantly combines type analysis and dispatch with
the unpacking function.

It's not like this principle has no application in Python,
there are examples all over the standard libraries where
dissimilar types can appear in the same context, but Python
not only lacks the infrastructure of sum types and pattern
matching, it also represents a different way of life where
the language and its users aren't as fastidious and people
just cope with the mess. The same feature is arguably much
less useful in Python, not just because people don't understand
the feature per se but because it has a different meaning here.

Donn Cave, (e-mail address removed)

 

[Peter Hansen]

The language: Python is wonderful, and I took to it more naturally than to
Smalltalk. But, the Smalltalk environment (Squeak is the only one I have
tried) is *really* quite amazing. I recommend playing with it a bit just
to get an idea of What Could Be even if you never intend to use it for
anything substantial.

My point was more subtle than it appeared. I did in fact
mean the "Python environment", as you mean the Smalltalk
environment... How I define that environment is perhaps
not obvious, but with a little imagination anyone could
start to think of ways in which I've made *my* Python
_environment_ very, very powerful, easy to work with,
etc.

And yes, I know what Smalltalk can do.

-Peter

 

[Ville Vainio]

Francois> Pythoneers do not know, or at least, do not use).
Francois> Another problem with structure matching in Python is
Francois> that a failed matching raises an exception, something
Francois> slow for applications heavy on pattern matching. For
Francois> very simple applications however, Python easily does as
Francois> it stands.

And that's where I proposed a library, taking a "structure" (tuple,
typically), a'la (int, int,(float,str),[int]) that verifies that the
tuple matches before unpacking.


Jacek> ... yup, you prove my point exactly.

Francois> And Jacek is right, once again. One should avoid being
Francois> too judgemental, especially when not much familiar with
Francois> problems at stake. (Yet, I did

I have to admit I'm not aware of my unfamiliarity with the topic. I
was thinking of pattern matching as it is used in ocaml, assuming
scheme does the same. As you can see from a previous post, I was
asking for an example on how it would *not* work, possibly as a way to
learn something new about pattern matching. It's also an idea for a
python library. So I don't think this is entirely unproductive.

Francois> presumptuous I might have been at times .) I know
Francois> that some people trigger their own education by
Francois> challenging others, which is not that humble to start
Francois> with, likely irritating to the challenged people, and
Francois> not looking very polite to the casual observers.

Well, I'm still waiting for the education, so far I've only got "you
don't understand" (w/ which I disagree, for now). For a non-casual
observer, "you don't understand" is much closer to a cheap ad-hominem
shot than "can you explain this, because I disagree with this
interpretation".

Francois> Hopefully, life will give you the opportunity for many
Francois> more checks! Pattern matching is by far not limited
Francois> to strings, and whole areas of technology are either
Francois> dedicated or based on pattern matching.

Yes, this is something I actually do understand. I wasn't thinking of
regexp pattern matching at all. I was thinking of

let rec len l =
match l with
[] -> 0
| [_] -> 1
| [_;_] -> 2
| _::xs -> 1 + len xs;;


But in theory, I agree with you about the approach of "younger"
programmers [I'm an old fart, BTW; 27 years and counting]. It's just
part of the thrills of being a programmer. I just don't have enough
real work to do ATM, I'm on summer vacation ;-).

Understanding that, and the fact that I'm back to work on monday
(ouch), probably the wise thing to do is to terminate this discussion
now. I hereby declare that Jacek won, Scheme kicks Pythons rear parts
(esp. the Bigloo implementation) and I prefer Python because I Just
Don't Get It (TM).

[and lest someone misunderstand that as bitter sarcasm, it's not -
it's more the reason of getting 0.5 hours of sleep within the last 36
hours, and I terminate this in quite a cheerful mood]

 

[Hamilcar Barca]

This is the same experience some of us had with Python...

So I've read and I've found no reason to disbelieve it. As I noted when I
said this represented "subjective" opinion, It just wasn't my experience.

 

[Michele Simionato]

I have to admit I'm not aware of my unfamiliarity with the topic. I
was thinking of pattern matching as it is used in ocaml, assuming
scheme does the same. As you can see from a previous post, I was
asking for an example on how it would *not* work, possibly as a way to
learn something new about pattern matching. It's also an idea for a
python library. So I don't think this is entirely unproductive.

Francois> presumptuous I might have been at times .) I know
Francois> that some people trigger their own education by
Francois> challenging others, which is not that humble to start
Francois> with, likely irritating to the challenged people, and
Francois> not looking very polite to the casual observers.

Well, I'm still waiting for the education, so far I've only got "you
don't understand" (w/ which I disagree, for now). For a non-casual
observer, "you don't understand" is much closer to a cheap ad-hominem
shot than "can you explain this, because I disagree with this
interpretation".

Francois> Hopefully, life will give you the opportunity for many
Francois> more checks! Pattern matching is by far not limited
Francois> to strings, and whole areas of technology are either
Francois> dedicated or based on pattern matching.

Yes, this is something I actually do understand. I wasn't thinking of
regexp pattern matching at all. I was thinking of

let rec len l =
match l with
[] -> 0
| [_] -> 1
| [_;_] -> 2
| _::xs -> 1 + len xs;;

Jacek and Francois already said what I wanted to say, so I just wanted to
give you the only reference I know about pattern matching in Scheme: google
for "Andrew Wright's pattern matching package". I looked at it in the past,
very superficially, but enough to realize that pattern matching is
something SUBSTANTIAL. An entire new way of thinking. But you should
probably be cast in the mindset of lisp-style macro programming to
appreciate it.

Also, if you don't take it as an offence, I can give you a suggestion
for a Scheme implementation you can look at, Chicken
(http://www.call-with-current-continuation.org/). I am not interested in
Bigloo since I don't care at all about being fast for numerical
analysis and I care more about other things, such as the object
system (Bigloo has a poor one because it want to be fast).

Michele Simionato

 

[Michele Simionato]

Hamilcar> How about currying and deferred list evaluation?

Deferred list evaluation: generators

Lazy evaluation in general: lambda : f(1,2)

this does not work so well; missing a constructs such as Scheme "set!" and "let"
anseverely limitates certain programming paradigms which are natural in Scheme.
This is ok, anyway, since Python is not Scheme. But you cannot claim that
Python support for certain things is as good as in other languages (say
Scheme, Haskell, etc.)

Currying: lambda x,y : f(x,y,1,2)

This is not currying. It is specializing arguments. Here is a reference about
specializing arguments in Scheme:
http://srfi.schemers.org/srfi-26/srfi-26.html

Haskell does real currying.


Michele Simionato

 

[Michele Simionato]

Paul Prescod:


Every sufficiently advanced LISP application will eventually reimplement
Python.

Neil

This is also true for Scheme:

http://srfi.schemers.org/srfi-49/srfi-49.html

SRFI-49: Indentation-sensitive syntax

Indentation will rule the world!

(even if I must confess that secretely I am not yet convinced of the
virtues of indentation and I will estimate advantages/disadvantages to
be 1:1)


Michele Simionato

 

[Siegfried Gonzi]

I have to admit I'm not aware of my unfamiliarity with the topic. I
was thinking of pattern matching as it is used in ocaml, assuming
scheme does the same.

I had't thought that my mentioning of "pattern matching" would incur a
new topic.

I do not use pattern matching every day. I mentioned pattern matching
simply due to my "Clean" experience. I must honestly admit that in
Clean pattern matching was natural. In Scheme one makes a good living
without it. However it is there in Bigloo and I red somewhere even a
note that Bigloo its pattern matching is bit more general than OCaml its
one. One may not forget that Manuel S. the developer behind Bigloo was
during his PhD work in computer science involved in the OCaml project
(there are some code snippets in OCaml which have been signed by him).

My Bigloo manual says to pattern matching:

==
Pattern matching is a key feature of most modern functional programming
languages since it allows clean and secure code to be written.
Internally, ``pattern-matching forms'' should be translated (compiled)
into cascades of ``elementary tests'' where code is made as efficient as
possible, avoiding redundant tests; Bigloo's ``pattern matching
compiler'' provides this. The technique used is described in details in
[QueinnecGeffroy92], and the code generated can be considered optimal
1due to the way this ``pattern compiler'' was obtained.

The ``pattern language'' allows the expression of a wide variety of
patterns, including:

• Non-linear patterns: pattern variables can appear more than once,
allowing comparison of subparts of the datum (through eq?)

• Recursive patterns on lists: for example, checking that the datum is
a list of zero or more as followed by zero or more bs.

• Pattern matching on lists as well as on vectors or structures.
==


Fensterbrett

 

[Jacek Generowicz]

I hereby declare that Jacek won,

Nonononooo ! I don't want to "win" anything.

Scheme kicks Pythons rear parts

In some areas. In others, Python kicks Scheme's.

I was not trying to say anything about Scheme in particular. It annoys
me to read repeatedly that something or other is not needed in Python:

We don't need pattern matching in Python.

We don't need mutable closures in Python.

We don't need native compilers in Python.

We don't need fully-fledged anonynmous functions in Python.

etc. etc. etc.

(It's particularly annoying to read this in response to someone saying
that he misses it in Python, and is putting it to good use in a
language which does provide it.)

I have two points to make about this:

a) Yes, we don't _need_ any of this. We don't need Python, a Turing
machine will do just fine.

b) The languages we use, _do_ influence the way we think about
programs: it is pointless to argue that a feature which is absent
from your language would not useful to you if it were available,
unless you are very familiar with its use in other languages,
because you will be arguing from a position of ignorance.

 

[Paul Boddie]

I was not trying to say anything about Scheme in particular. It annoys
me to read repeatedly that something or other is not needed in Python:

It annoys me to read repeatedly that something or other is desperately
needed in Python. There are certain classes of features which could be
added without ruffling the feathers of the Norwegian Blue, but more on
those shortly.

We don't need pattern matching in Python.

We don't need mutable closures in Python.

Arguably, these features could quite possibly lie outside the design
"roadmap" of the language. Sure, we could add everything and then sit
on top of our nice ivory tower claiming "expressive completeness"
whilst smugly writing Fibonacci sequence generators for the next
thirty years and claiming some kind of victory (while the rest of the
industry just gets on with business).

We don't need native compilers in Python.

Actually, and I know that you agree with me here, we do need native
compilers. Perhaps "need" is a strong word to use, but I imagine that
many people would rather like native compilers if only to...

* Avoid dipping into C/C++ for performance and introducing the
usual reliability issues that this causes.
* Simplify "frozen" executable distribution.
* Permit development for embedded systems.
* <insert your idea here>

However, a lot of this work could hopefully be done without
introducing new keywords or syntax and deprecating a ton of stuff (or
at least people would get to make the explicit decision to enable the
breakage as a tradeoff for better performance). Sadly, a lot of people
seem to like the new keywords and syntax, the deprecation and, in
particular, the campaigning: "If only Python were more like my
favourite language then it would be my favourite language."

Perhaps the natively-compiled Python isn't quite Python as we know it
(consider Pyrex), and perhaps the kind of Python you envisage isn't
quite Python either (consider Prothon). But when most Python
developers would probably benefit most from infrastructural
improvements, I'd rather see spin-off languages than see Python taken
for a ride on a selection of language design bandwagons.

Paul

 

[Siegfried Gonzi]

Also, if you don't take it as an offence, I can give you a suggestion
for a Scheme implementation you can look at, Chicken
(http://www.call-with-current-continuation.org/). I am not interested in
Bigloo since I don't care at all about being fast for numerical
analysis and I care more about other things, such as the object
system (Bigloo has a poor one because it want to be fast).

Hi:

Can you elaborate a bit why do you feel that Bigloo its object system is
limited the way it is.

I know some posts from you on comp.lang.scheme. I gather you have got a
good knowledge of Python its object system.

Can you try to summarize a short comparison between Bigloo its object
system vs. Chicken vs. Python its one.

Yes I know: different strokes for different people. But why do think
Bigloo falls short regarding its object system.


Fensterbrett

 

[Peter Maas]

> Python provides no built-in support for pattern matching, therefore
> your average happy Pythoneer will not be familiar with pattern
> matching, the point of pattern matching, the benefits of pattern
> matching, or the situations in which pattern matching is a big win.

If I understand correctly you mean that it makes a difference
whether it reads

s ~ /a.*b/

or

re.match('/a.*b/', s)

?

For me this is only a lexical issue. I use REs because I need them not
because they are builtins.

> Python provides no built-in support for pattern matching, therefore
> your average happy Pythoneer will not be familiar with pattern
> matching, the point of pattern matching, the benefits of pattern
> matching, or the situations in which pattern matching is a big win.

So you mean that one can only appreciate REs and learn to use
them if they are builtins? That's totally wrong, IMO. A beginner
learns REs because he finds them mentioned in the docs, in tutorials,
in newsgroups ... and understands their purpose. Builtins don't pop up
and say 'Use me, please', at least as long as there is no MS Perl

... yup, you prove my point exactly.

OK, all primes are odd. Proof: 47 . Ville has exaggerated a bit,
but I estimate that most RE uses can be replaced by string methods
like startswith, find etc. These are not only more readable but
also faster than REs AFAIK.

My point is, of course, not specific to Python or to pattern matching;
you can replace them with any language, and any feature missing from
that language.

Yes, poor C++ programmers are desperately trying to open files:

?> C++ provides no built-in file I/O, therefore your average happy C++
?> programmer will not be familiar with file I/O, the point of file I/O,
?> the benefits of file I/O, or the situations in which file I/O
?> is a big win.

)

Mit freundlichen Gruessen,

Peter Maas

 

[Siegfried Gonzi]

If I understand correctly you mean that it makes a difference
whether it reads

s ~ /a.*b/

or

re.match('/a.*b/', s)

?

I am not sure what you personally understand under pattern matching.

However, since they are discussing about pattern matching the following
may help:


(from list.ml; see Ocaml's standard distribution)
==
let rec map2 f l1 l2
match (l1, l2) with
([], []) -> []
| (h1::t1, h2::t2) -> let r = f h1 h2 in r::map2 f l1 l2
| (_, _) -> invalid_arg "List.map2"
==

.... and compare it with the following Bigloo function:

==
(define (map2 fun lis1 lis2)
(match-case (list lis1 lis2)
((() ()) '())
(((?h1 ???t1) (?h2 ???t2))
(cons
(fun h1 h2)
(map2 fun t1 t2)))
((?- ?-) (error "map2"
"invalid list argument" (list lis1 lis2))))
==



Fensterbrett

 

[Michele Simionato]

Can you elaborate a bit why do you feel that Bigloo its object system is
limited the way it is.

I know some posts from you on comp.lang.scheme. I gather you have got a
good knowledge of Python its object system.

Can you try to summarize a short comparison between Bigloo its object
system vs. Chicken vs. Python its one.

Yes I know: different strokes for different people. But why do think
Bigloo falls short regarding its object system.

I remember I looked at Bigloo's object system last year, and I may forgot
something now, so please correct me if I am wrong. It seems to me it was a
single inheritance object system with no meta-object protocol and some
strange concept of "widening"-"shrinking" I did not understood. At the
time I wanted to study CLOS (which is often regarded as the most sophysticated
object system ever) and Chicken had TinyClos, so it was better for my aims.
Also, I wanted to stay with Scheme and not with Common Lisp for various reasons.
The biggest difference between CLOS and Python object system are multimethods,
which Python misses. Multiple inheritance and MOP in Python are good enough
instead.

Michele Simionato

 

[Peter Maas]

I am not sure what you personally understand under pattern matching.

However, since they are discussing about pattern matching the following
may help:

Oh. Thanks for correcting me and my apologies to Jacek. I should
have read the thread from the beginning but it was way too long.

Mit freundlichen Gruessen,

Peter Maas

 

[Siegfried Gonzi]

I remember I looked at Bigloo's object system last year, and I may forgot
something now, so please correct me if I am wrong. It seems to me it was a
single inheritance object system with no meta-object protocol and some
strange concept of "widening"-"shrinking" I did not understood.

I am not an expert in CLOS programming. But what are the disadvantages of not having a meta-object protocol? What
is hard to realize then?

Fentserbrett

 

[Jacek Generowicz]

If I understand correctly you mean that it makes a difference
whether it reads

s ~ /a.*b/

or

re.match('/a.*b/', s)

?

I am afraid you do not understand correctly.

What I was talking about had nothing to do with regular expressions.

For more hints, look upthread.