Change by Joe Marshall :
--
keywords: +patch
pull_requests: +24703
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26062
___
Python tracker
<https://bugs.python.org/issu
New submission from Joe Marshall :
There's a couple of wrong function signatures in dictobject.c,
dictkeys_reversed and dictitems_reversed are defined as single arg functions
like so: PyObject *(PyObject *), and are then passed around and called as
PyCFunctions, which should be PyObject
Xah Lee wrote:
Computer Language Popularity Trend
This page gives a visual report of computer languages's popularity, as
indicated by their traffic level in newsgroups. This is not a
comprehensive or fair survey, but does give some indications of
popularity trends.
Suggestions:
Provide a
Marshall wrote:
I am having a hard time with this very broad definition of aliasing.
How about this definition: Consider three variables, i, j, and k, and
a functional equivalence predicate (EQUIVALENT(i, j) returns true if
for every pure function F, F(i) = F(j)). Now suppose i and j are
Marshall wrote:
Joe Marshall wrote:
Marshall wrote:
Consider the following Java fragment:
void foo() {
int i = 0;
int j = 0;
// put any code here you want
j = 1;
i = 2;
// check value of j here. It is still 1, no matter what you filled
Marshall wrote:
Again, I disagree: it is posible to have mutability without
pointers/identity/objects.
I think you are wrong, but before I make a complete ass out of myself,
I have to ask what you mean by `mutability'. (And
pointers/identity/objects, for that matter.)
Alan Bawden discusses
Marshall wrote:
Consider the following Java fragment:
void foo() {
int i = 0;
int j = 0;
// put any code here you want
j = 1;
i = 2;
// check value of j here. It is still 1, no matter what you filled in
above.
// The assignment to i cannot be made to affect the value
David Hopwood wrote:
Joe Marshall wrote:
The point is that there exists (by construction) programs that can
never be statically checked.
I don't think you've shown that. I would like to see a more explicit
construction of a dynamically typed [*] program with a given specification
Andreas Rossberg wrote:
~/ ocaml -rectypes
Objective Caml version 3.08.3
# let rec blackhole x = blackhole;;
val blackhole : 'b - 'a as 'a = fun
The problem is, though, that almost everything can be typed once you
have unrestricted recursive types (e.g. missing
Marshall wrote:
Yes, an important question (IMHO the *more* important question
than the terminology) is what *programs* do we give up if we
wish to use static typing? I have never been able to pin this
one down at all.
It would depend on the type system, naturally.
It isn't clear to me
Marshall wrote:
Joe Marshall wrote:
Looking back in comp.lang.lisp, I see these examples:
(defun noisy-apply (f arglist)
(format t I am now about to apply ~s to ~s f arglist)
(apply f arglist))
(defun blackhole (argument)
(declare (ignore argument))
#'blackhole
QCD Apprentice wrote:
Joe Marshall wrote:
Marshall wrote:
The real question is, are there some programs that we
can't write *at all* in a statically typed language, because
they'll *never* be typable?
Certainly! As soon as you can reflect on the type system you can
construct
David Hopwood wrote:
Joe Marshall wrote:
(defun blackhole (argument)
(declare (ignore argument))
#'blackhole)
This is typeable in any system with universally quantified types (including
most practical systems with parametric polymorphism); it has type
forall a . a - #'blackhole
Marshall wrote:
I stand corrected: if one is using C and writing self-modifying
code, then one *can* zip one's pants.
Static proofs notwithstanding, I'd prefer a dynamic check just prior to
this operation.
I want my code to be the only self-modifying thing around here.
--
David Hopwood wrote:
Joe Marshall wrote:
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
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
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*
Chris Smith wrote:
Joachim Durchholz [EMAIL PROTECTED] wrote:
Assume a language that
a) defines that a program is type-correct iff HM inference establishes
that there are no type errors
b) compiles a type-incorrect program anyway, with an establishes
rigorous semantics for such
Marshall wrote:
That's really coming home to me in this thread: the terminology is *so*
bad. I have noticed this previously in the differences between
structural
and nominal typing; many typing issues associated with this distinction
are falsely labeled as a static-vs-dynamic issues, since
Chris Smith wrote:
Joe Marshall [EMAIL PROTECTED] wrote:
Agreed. That is why there is the qualifier `dynamic'. This indicates
that it is a completely different thing from static types.
If we agree about this, then there is no need to continue this
discussion. I'm not sure we do agree
Chris Smith wrote:
Knowing that it'll cause a lot of strenuous objection, I'll nevertheless
interject my plea not to abuse the word type with a phrase like
dynamically typed.
Allow me to strenuously object. The static typing community has its
own set of
terminology and that's fine.
Chris Smith wrote:
Joe Marshall [EMAIL PROTECTED] wrote:
Chris Smith wrote:
Knowing that it'll cause a lot of strenuous objection, I'll nevertheless
interject my plea not to abuse the word type with a phrase like
dynamically typed.
Allow me to strenuously object. The static
Xah Lee wrote:
in March, i posted a essay What is Expressiveness in a Computer
Language, archived at:
http://xahlee.org/perl-python/what_is_expresiveness.html
I was informed then that there is a academic paper written on this
subject.
On the Expressive Power of Programming Languages, by
Alex Martelli wrote:
Joe Marshall [EMAIL PROTECTED] wrote:
...
The problem is that a `name' is a mapping from a symbolic identifier to
an object and that this mapping must either be global (with the
attendant name collision issues) or within a context (with the
attendant question
Pisin Bootvong wrote:
Is this a Slippery Slope fallacious argument?
(http://c2.com/cgi/wiki?SlipperySlope)
if python required you to name every function then soon it will
require you to name every number, every string, every immediate result,
etc. And we know that is bad. Therefore
Alex Martelli wrote:
I think it's reasonable to make a name a part of functions, classes and
modules because they may often be involved in tracebacks (in case of
uncaught errors): to me, it makes sense to let an error-diagnosing
tracebacks display packages, modules, classes and
Alex Martelli wrote:
Ken Tilton [EMAIL PROTECTED] wrote:
...
But the key in the whole thread is simply that indentation will not
scale. Nor will Python.
Absolutely. That's why firms who are interested in building *seriously*
large scale systems, like my employer (and supplier of your
Alex Martelli wrote:
Your pragmatic benefits, if such they were, would also apply to the
issue of magic numbers, which was discussed in another subthread of
this unending thread; are you therefore arguing, contrary to widespread
opinion [also concurred in by an apparently-Lisp-oriented
Jeremy Bowers [EMAIL PROTECTED] writes:
On Thu, 31 Mar 2005 23:30:42 -0800, Erik Max Francis wrote:
Daniel Silva wrote:
Shriram Krishnamurthi has just announced the following elsewhere; it might
be of interest to c.l.s, c.l.f, and c.l.p:
29 matches
Mail list logo
