Re: Fortran vs Python - Newbie Question
Carl Banks wrote: > On Mar 26, 10:11 am, "Andy Dingley" <[EMAIL PROTECTED]> wrote: > >>On 26 Mar, 14:20, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: >> >> >>>what are the advantages of using Python for >>>creating number crunching apps over Fortran?? >> >>If you have to ask, you've not experienced enough Fortran to know its >>sheer horror. >> >>You can write programs in Python that do usefully complicated things, >>and you can get them to work in a reasonable time. Fortran can't do >>this, for anything more than the trivial. "Classic" Fortran tasks of >>the past are now seen as trivial. OK, so they did it to a lot of data, >>but they really didn't do anything very complex to it. > > > You couldn't be more incorrect. I have run some very old (pre-Fortran > 77) programs that are very far from trivial. > > >>You can also write Python that other people can read and maintain. You >>can't do this in Fortran, without a truly insane amount of trouble. > > > This is a lie. I've seen some Fortran code that was hellspawned, and > some that was clear as glass. The latter came about without a "truly > insane amount of trouble". > > >>As >>Fortran programs have historically been authored and hacked on by >>successive generations of grad students, this is the most vital >>feature of all. > > > Perhaps this is your impression because it's the only Fortran code > you've ever been exposed to? > > >>Finally we're no longer so interested in "number crunching". Number >>crunching used to consist of simple operations over vast arrays of >>data, although this was data with remarkably simple structure by >>today's standards. These just aren't the major class of problems of >>interest today. > > > I suspect you're speaking from a narrow perspective, because "number > crunching", as you define it, is still a problem of interest and > heavily researched. Maybe it's not in your field. Anyways, you seem > to be ignorant of the complexities of "simple operations over vast > arrays", as if it you could accomplish these operations with a few > lines of Python and numpy. That might be true for your homework, but > good number-crunching codes often did a lot of stuff under the covers. > > Hear hear. Python and Fortran both have their place. I'm a grad student in Electromagnetics (radio frequency research) and I depend a lot on "number crunching" to help me design the latest and greatest rader array to the coolest cell phone that will connect anywhere. I actually use python to speed up my development of codes for Fortran. I prototype some function that I want in python and then use the final draft of it in my fortran code. What used to take several hours I can do in less than one by leveraging both languages for what they're good for, Python for RAD and Fortran for fast number crunching of my research. Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: numpy help
robert wrote: > Chris Smith wrote: > >>Howdy, >> >>I'm a college student and for one of we are writing programs to >>numerically compute the parameters of antenna arrays. I decided to use >>Python to code up my programs. Up to now I haven't had a problem, >>however we have a problem set where we are creating a large matrix and >>finding it's inverse to solve the problem. To invert the matrix I've >>tried using numpy.numarray.linear_algebra.inverse and >>numpy.oldnumeric.linear_algebra.inverse which both give me the same >>error ( I was hoping they called different routines but I think they >>call the same one ). >> > > > try scipy.linalg.inv etc. > > (you are using outdated old NumPy modules with recent array type which > sometimes creates type conflicts. > > robert > I tried that one also, and it didn't work. Chris -- http://mail.python.org/mailman/listinfo/python-list
numpy help
Howdy, I'm a college student and for one of we are writing programs to numerically compute the parameters of antenna arrays. I decided to use Python to code up my programs. Up to now I haven't had a problem, however we have a problem set where we are creating a large matrix and finding it's inverse to solve the problem. To invert the matrix I've tried using numpy.numarray.linear_algebra.inverse and numpy.oldnumeric.linear_algebra.inverse which both give me the same error ( I was hoping they called different routines but I think they call the same one ). This is the error message I receive: Traceback (most recent call last): File "C:\Documents and Settings\Chris & Esther\Desktop\636_hw5_2\elen636_hw5_2.py", line 60, in matrix_inverse = numpy.numarray.linear_algebra.generalized_inverse(matrix) File "C:\Python25\lib\site-packages\numpy\oldnumeric\linear_algebra.py", line 59, in generalized_inverse return linalg.pinv(a, rcond) File "C:\Python25\lib\site-packages\numpy\linalg\linalg.py", line 557, in pinv u, s, vt = svd(a, 0) File "C:\Python25\lib\site-packages\numpy\linalg\linalg.py", line 485, in svd a = _fastCopyAndTranspose(t, a) File "C:\Python25\lib\site-packages\numpy\linalg\linalg.py", line 107, in _fastCopyAndTranspose cast_arrays = cast_arrays + (_fastCT(a.astype(type)),) TypeError: can't convert complex to float; use abs(z) I've tried inverting small complex matrices and it worked fine. Does anyone know why it won't work for this larger matrix? Any ideas how I can work around this problem and get the correct inverse matrix? Chris P.S. elen636_math.py is my personal library of functions I've create to solve the problem while elen636_hw5_2.py is the program that I'm actually running # Purpose: # This is a library of functions for ELEN 636 that # so far has the ability to calculate the Sine and # Cosine integrals as well as the mutual impedance # between two parallel antennas. # # Author: Christopher Smith # E-mail: [EMAIL PROTECTED] # Date: 10/30/2006 ### ### NOTE: The functions below for the sine and cosine integrals are similar ### to the functions I turned in for homework assignment 4 problem 6 ### except that I added the ability to check for convergence. ### I also added the factor into the mutual impedance formula so that the ### answer is given in terms of the terminal input impedance instead of ### the loop impedance as it was formerly giving. ### # depends on the math library from math import * import numpy.numarray, numpy def factorial(n): """ This function calculates the factorial of a number. """ sum = 1.0 for m in range(1, int(n)+1): sum = float(m)*sum return sum def Si(x): """ This function computes the sine integral. It uses a power series expansion that can be found in Abramowitz and Stegun's math functions reference book. """ start = 0.0 stop = 10.0 sine_int = 0.0 convergence = 1.0*10**(-6) # want to have the difference between # the last run and this run below # this value while 1: for n in range(int(start), int(stop)): n = float(n) sine_int += ((-1)**n)*x**(2*n +1)/((2*n+1)*factorial(2*n+1)) sine_int_new = sine_int + ((-1.)**stop)*x**(2.*stop +1.)/((2.*stop+1.)*factorial(2.*stop+1.)) converge_check = sine_int_new - sine_int if abs(converge_check) < convergence: break else: start = stop stop += 5.0 return sine_int_new def Ci(x): """ This function computes the cosine integral. It uses a power series expansion that can be found in Abramowitz and Stegun's math functions reference book. """ start = 1.0 stop = 10.0 convergence = 1.0*10.**(-6) # want to have the difference between # the last run and this run below # this value # The first number in the sum is Euler's constant to 10 digits cosine_int = 0.5772156649 + log(x) while 1: for n in range(int(start), int(stop)): m = float(n) cosine_int = cosine_int +((-1)**m)*x**(2*m)/((2*m)*factorial(2*m)) cosine_int_new = cosine_int + ((-1)**stop)*x**(2*stop)/((2*stop)*factorial(2*stop)) converge_check = cosine_int_new - cosine_int if abs(converge_check) < convergence: break else: start = stop stop += 5.0 #print stop return cosine_int_new def mutual_impedance(length1_tot, length2_tot, stagger, d): """ This function computes the mutual impedance between two antennas for the Parallel in Echelon Configuration. The formulas are taken from a paper by Howard King, "Mutual Impedance of Unequal Length Antennas in Echelon"
auto fill out web form
Does anyone know of any python scripts that can help me automatically navigate through some forms so I can schedule the download the file at the end of all the questions? -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marshall <[EMAIL PROTECTED]> wrote: > Yes, these *performance* issues make assignment prohibitive for > real-world use, at least if we are talking about data management > in the large. This is not the same thing as saying the resulting > language is a toy language, though; its semantics are quite > interesting and possibly a better choice for *defining* the semantics > of the imperative operations than directly modelling the imperative > operations. (Or maybe not.) In any event, it's worth thinking about, > even if performance considerations make it not worth implementing. My "toy language" comment was directed at a language that I mistakenly thought you were proposing, but that you really weren't. You can ignore it, and all the corresponding comments about assignment being less powerful, etc. I was apparently not skilled at communication when I tried to say that in the last message. It is, perhaps, worth thinking about. My assertion here (which I think I've backed up, but there's been enough confusion that I'm not surprised if it was missed) is that the underlying reasons that performance might be poor for this language are a superset of the performance problems caused by aliasing. Hence, when discussing the problems caused by aliasing for the performance of language implementations (which I believe was at some point the discussion here), this isn't a particularly useful example. It does, though, have the nice property of hiding the aliasing from the semantic model. That is interesting and worth considering, but is a different conversation; and I don't know how to start it. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marshall <[EMAIL PROTECTED]> wrote: > > If the relations are to > > be considered opaque, then there's clearly no aliasing going on. > > Not certain I understand, but I think I agree. My condition, though, was that relations be opaque. Since you will be violating that condition further on down, I just felt that it's useful to point that out here. > No, such a language is entirely useful, since relational assignment > is *more* expressive than insert/update/delete. Assignment is more powerful *as* assignment. However, it is less powerful when the task at hand is deriving new relations from old ones. Assignment provides absolutely no tools for doing that. I thought you were trying to remove those tools from the language entirely in order to remove the corresponding aliasing problems. I guess I was wrong, since you make it clear below that you intend to keep at least basic set operations on relations in your hypothetical language. > Consider: > > i := i + 1; > > Note that the new value of i didn't just appear out of thin air; it was > in fact based on the previous value of i. Right. That's exactly the kind of thing I thought you were trying to avoid. > So we can define insert, update and delete in terms of relational > assignment, relational subtraction, and relational union. Type > checking details omitted. Then the problem is in the step where you assign the new relation to the old relational variable. You need to check that the new relation conforms to the invariants that are expressed on that relational variable. If you model this as assignment of relations (or relation values... I'm unclear on the terminology at this point) then naively this requires scanning through an entire set of relations in the constraint, to verify that the invariant holds. You've may have avoided "aliasing" in any conventional sense of the word by stretching the word itself beyond breaking... but you've only done it by proactively accepting its negative consequences. It remains non-trivial to scan through a 2 GB database table to verify that some attribute of every tuple matches some attribute of another table, even if you call the entire thing one relational variable. The implementation, of course, isn't at all going to make a copy of the entire (possibly several GB) relation and rewrite it all every time it makes a change, and it isn't going to give up and rescan all possible invariants every time every change is made. In other words, you've risen to a layer of abstraction where the aliasing problem does not exist. The implementation is still going to deal with the aliasing problem, which will resurface once you pass over to the other side of the abstraction boundary. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marshall <[EMAIL PROTECTED]> wrote: > We seem to have slipped back from the hypothetical relation language > with only assignement back to SQL. I missed the point where we started discussing such a language. I suspect it was while some of us were still operating under the misconception that you assignment to attributes of tuples, rather than to entire relations. I don't see how such a language (limited to assignment of entire relations) is particularly helpful to consider. If the relations are to be considered opaque, then there's clearly no aliasing going on. However, such a language doesn't seem to solve any actual problems. It appears to be nothing other than a toy language, with a fixed finite set of variables having only value semantics, no scope, etc. I assume that relational databases will have the equivalent of SQL's update statement; and if that's not the case, then I would need someone to explain how to accomplish the same goals in the new relational language; i.e. it would need some way of expressing transformations of relations, not just complete replacement of them with new relations that are assumed to appear out of thin air. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Joachim Durchholz <[EMAIL PROTECTED]> wrote: > I fail to see an example that would support such a claim. > > On the other hand, UPDATE can assign any value to any field of any > record, so it's doing exactly what an assignment does. INSERT/DELETE can > create resp. destroy records, which is what new and delete operators > would do. > > I must really be missing the point. I *think* I understand Marshall here. When you are saying "assignment", you mean assignment to values of attributes within tuples of the cell. When Marshall is saying "assignment", he seems to mean assigning a completely new *table* value to a relation; i.e., wiping out the entire contents of the relation and replacing it with a whole new set of tuples. Your assignment is indeed less powerful than DML, whereas Marshall's assignment is more powerful than DML. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Darren New <[EMAIL PROTECTED]> wrote: > I'm not sure what linear or uniqueness typing is. It's typestate, and if > I remember correctly the papers I read 10 years ago, the folks at > TJWatson that invented Hermes also invented the concept of typestate. > They at least claim to have coined the term. Coining the term is one thing, but I feel pretty confident that the idea was not invented in 1986 with the Hermes language, but rather far earlier. Perhaps they may have invented the concept of considering it any different from other applications of types, though. I still have trouble delineating how to consider "typestate" different from ordinary types in formal terms, unless I make the formal model complex enough to include some kind of programmer-defined identifiers such as variables. The distinction is not at all relevant to common type system models based on the lambda calculus. While acknowledging, on the one hand, that the word "typestate" is used to describe this, I also object that types have *always* been assigned to expressions in differing type environments. Otherwise, it would be impossible to assign types to lambda abstractions in the simply typed lambda calculus, the simplest of all generally studied type systems. What is being named here is the overcoming of a limitation that programming language designers imposed upon themselves, whether from not understanding the theoretical research or not believing it important, I don't know. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
David Hopwood <[EMAIL PROTECTED]> wrote: > Chris Smith wrote: > > If checked by execution, yes. In which case, I am trying to get my head > > around how it's any more true to say that functional languages are > > compilable postconditions than to say the same of imperative languages. > > A postcondition must, by definition [*], be a (pure) assertion about the > values that relevant variables will take after the execution of a subprogram. Okay, my objection was misplaced, then, as I misunderstood the original statement. I had understood it to mean that programs written in pure functional languages carry no additional information except for their postconditions. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marshall <[EMAIL PROTECTED]> wrote: > Is it possible you're being distracted by the syntax? WHERE is a > binary operation taking a relation and a filter function. I don't > think of filters as being like array indexing; do they appear > analogous to you? (Always a difficult question because often > times A and B share some qualities and not others, and > what does one call that?) This is definitely a good question. Nevertheless, I think we're fooling ourselves if we decide that we've made progress by defining part of the problem out of existence. The original problem was that when there are several ways of getting access to something that is identical (rather than just equal), this causes problems for invariant checking. These several ways of accessing data are being called 'aliasing' -- I have no comment on whether that's standard usage or not, because I don't know. I suspect that aliasing is normally used for something closer to the physical level. The point is that whatever "aliasing" really means, what we're discussing is having two paths by which one may access identical data. So there are infinitely complex ways in which this can occur. I can have pointers that are aliased. I can have integers, which by themselves are just plain values, but can alias each other as indices into an array. I can have strings that do the same thing for an associative array. I can, of course, have arbitrarily more complex data structures with exactly the same issue. I can also have two different WHERE clauses, which when applied to the same relation yield exactly the same set of tuples. The problem arises when code is written to update some value (or set of tuples, in the SQL case, since definitions differ there) using one pointer/int/string/WHERE clause/etc, and at the same time an invariant was written using the other pointer/int/WHERE/etc, the result is that either of: a) The compiler has to be able to prove that the two are not aliased b) The compiler has to re-evaluate the invariant from scratch when this operation is performed. (Yeah, there's actually a whole continuum between a and b, based on more limited abilities of the compiler to prove things. I'm oversimplifying, and I think it's rather benign in this case.) So in this sense, a WHERE clause is a binary operation in exactly the same way that an array indexing expression is a binary operation, and both are capable of aliasing in at least this logical sense. Now it's certainly true that languages with unrestricted pointers are less successful at limiting the scope of re-evaluation of invariants. In the array or SQL relation cases, there's a limited set of value/tuple modifications that might cause the invariant to need rechecking (specifically those that point to the same array, or to the relation or one of its views). A language with unrestricted untyped pointers, if it doesn't get lucky with the capture analysis, may have to re-evaluate all invariants in the application on any given assignment. Nevertheless, the re-evaluation of the invariant still needs to be done. -- Chris Smith - Lead Software Developer /Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
We Chris's stick together, as always. Marshall <[EMAIL PROTECTED]> wrote: > > Unfortunately, they are the right level. Actually,the right level > > might even be lower, the fields within a record, but that's moving > > even farther away from the direction you wish to go. The right level > > is the lowest level at which the programmer can see and manipulate > > values. > > But how is this not always "the bit"? First of all, we should be consistent in speaking about the logical language semantics, which may not include bits anyway. That said, if bits were the primitive concept of data in a language, then we'd be able to get away with talking about higher-level concepts because we agree to always manipulate a larger structure (a byte, for example) as a pure value. If we were using bitwise operators, then we wouldn't be able to get away with it, for example. That said, it's also quite possible to consider aliasing on higher levels as well; it's just not possible to point out the lack of aliasing for higher levels of abstraction, and thus conclude that no aliasing exists. Aliasing is still possible for entities within those layers of abstraction. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marshall wrote... > I am having a hard time with this very broad definition of aliasing. > Would we also say that a[1+1] and a[2] are aliases? It seems > to me, above, that we have only a, and with only one variable > there can be no aliasing. The problem with this (and with the relational one as well) is that the practical problems don't go away by redefining "variable" to mean larger collections of values. > given a 32 bit integer variable x, and offsets i and j (equal as in > the above example) would you say that > >x &= (1 << i) > and >x &= (1 << j) > > are aliased expressions for setting a particular bit in x? I don't know about Joachim, but yes, I would. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marshall <[EMAIL PROTECTED]> wrote: > > What you are asking for is some subset of identity, and I've not yet > > succeeded in understanding exactly what it is or what its limits are... > > except that so far, it seems to have everything to do with pointers or > > aliasing. > > Perhaps it is specifically first-class identity, rather than identity > per se. As in: "the value of one variable can (be/refer to/depend on) the identity of another variable"? I can certainly see this as as reasonable concept to consider. > > I'm not yet convinced that this is any different from a language with > > standard pointer aliasing. If I have two tables A and B, and a foreign > > key from A into B, then I run into the same problems with enforcing > > constraints that I would see with a pointer model... when I update a > > relation, I need to potentially check every other relation that contains > > a foreign key into it, in order to ensure that its constraints are not > > violated by that constraint. That's the same thing that is being > > pointed out as a negative consequence of aliasing in other languages. > > No, that's not the same thing. What you are describing here is > not an aliasing issue, but simply the consequences of allowing > constraints to mention more than one variable. > A foreign key constraint is a multi-variable constraint. > Specifically, a foreign key from table A, attribute a > to table B, attribute b is the constraint: > > forall a in A, exists b in B such that a = b. > > Note that two variables, A and B, are referenced in > the constraint. There's confusion here coming from different usages of the word variable. Let us talk instead of values, and of the abstract structures that gives them meaning. In both cases (invariants in a hypothetical imperative language, and in a relational database), the constraints make reference to these structures of values (relations, for example, or various kinds of data structures), and not to the individual values or objects that they contain. In both cases, the problem is not that we don't know what structures to check to verify the invariant; rather, it's that we have to check ALL of the values in that structure. As someone pointed out, this is to be expected in a world of mutable things with identity that are globally locatable. It is simple fact that if I tell you "I spoke to Barbara's husband", you may need to trace down who Barbara's husband is before you could discover that, for example, maybe I actually spoke to your boss, or to your nephew's best- friend's father. If databases are capable of modeling these kinds of relationships (and of course they are), then they are as susceptible to "aliasing" -- in a logical sense that avoids mention of pointer -- as anyone else. > I don't see any aliasing in this example either. > Actually, this was probably a bad example. Let's stick to the others involving relationships between tuples. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marshall <[EMAIL PROTECTED]> wrote: > Chris Smith wrote: > > Darren New <[EMAIL PROTECTED]> wrote: > > > Chris Smith wrote: > > > > Unless I'm missing your point, I disagree with your disagreement. > > > > Mutability only makes sense because of object identity (in the generic > > > > sense; no OO going on here). > > > > > > Depends what you mean by "object". > > > > > > int x = 6; int y = 5; x = y; > > > > > > I'd say x was mutable, with no "identity" problems involved? > > > > The variable x definitely has identity that's independent of its value. > > I'm not sure what you mean by that. I mean, simply, that when you can assign a value to a variable, then you care that it is that variable and not a different one. That's identity in the normal sense of the word. The code elsewhere in the procedure is able to access the value of 'x', and that has meaning even though you don't know what value 'x' has. This has definite implications, and is a useful concept; for example, it means that the pure lambda calculus no longer sufficient to express the semantics of the programming language, but instead something else is required. What you are asking for is some subset of identity, and I've not yet succeeded in understanding exactly what it is or what its limits are... except that so far, it seems to have everything to do with pointers or aliasing. > > I also see, though, that the majority (so far, I'd > > say all) of the potential uses for which it's worth introducing mutation > > into an otherwise mutation-free language allow the possibility of > > aliasing, which sorta makes me wonder whether this problem is worth > > solving. > > What about my example of SQL? Mutation, no pointers, no aliasing. > Yet: useful. I'm not yet convinced that this is any different from a language with standard pointer aliasing. If I have two tables A and B, and a foreign key from A into B, then I run into the same problems with enforcing constraints that I would see with a pointer model... when I update a relation, I need to potentially check every other relation that contains a foreign key into it, in order to ensure that its constraints are not violated by that constraint. That's the same thing that is being pointed out as a negative consequence of aliasing in other languages. For example, executing: UPDATE P SET x = 5 WHERE y = 43; may result in the database having to re-evaluate the constraint that says that for all P(x, y, z), x must be less than 4 when z = 17. One difference is that while in general purpose programming languages this appears to be a daunting task, databases are set up to do these kinds of things all the time and contain optimizations for it... but the problem is still the same, and it would still present the same difficulties in doing formal proofs that running the above UPDATE statement doesn't violate any invariants. (If I'm wrong about that, please let me know; I'd very interested if that's so.) -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
David Hopwood <[EMAIL PROTECTED]> wrote: > This is true, but note that postconditions also need to be efficient > if we are going to execute them. If checked by execution, yes. In which case, I am trying to get my head around how it's any more true to say that functional languages are compilable postconditions than to say the same of imperative languages. In both cases, some statement is asserted through a description of a means of computing it. There may be a distinction worth making here, but I'm missing it so far. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Darren New <[EMAIL PROTECTED]> wrote: > Chris Smith wrote: > > Unless I'm missing your point, I disagree with your disagreement. > > Mutability only makes sense because of object identity (in the generic > > sense; no OO going on here). > > Depends what you mean by "object". > > int x = 6; int y = 5; x = y; > > I'd say x was mutable, with no "identity" problems involved? The variable x definitely has identity that's independent of its value. Some might call that a problem in and of itself, as it complicates the formal model of the language and makes it difficult to predict what result will be produced by normal order evaluation. On the other hand, this thread seems to be using "identity" to mean "identity with potential for aliasing", in which case it is vacuously true that eliminating identity also prevents the problems that arise from aliasing. It is true, and I agree on this with Marshall, that eliminating the potential for aliasing solves a lot of problems with checking invariants. I also see, though, that the majority (so far, I'd say all) of the potential uses for which it's worth introducing mutation into an otherwise mutation-free language allow the possibility of aliasing, which sorta makes me wonder whether this problem is worth solving. I'd like to see an example of code that would be harder to write without mutation, but which can obey any restriction that's sufficient to prevent aliasing. > Why is it problematic that variables have identity and are mutable? > Certainly I can later "find" whatever value I put into x. I simply found the language confusing. I said it would be nonsensical for a language to have mutation without identity. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marshall <[EMAIL PROTECTED]> wrote:
> Hmmm, well, I cannot agree. You've defined away the pointers
> but then slipped them back in again by assumption ("objects
> of these types have identity".)
>
> First let me say that the terminology is somewhat problematic.
> For the specific issue being discussed here, pointers, identity,
> and objects are all the same concept. (I agree that "pointer"
> connotes a low-level construct, however.)
Unless I'm missing your point, I disagree with your disagreement.
Mutability only makes sense because of object identity (in the generic
sense; no OO going on here). Without object identities, mutability is
useless. What's the use of changing something if you're not sure you'll
ever be able to find it again?
You may limit the scope of object identity arbitrarily, even to the
point that aliasing is impossible (though with lexical closure, that
gets even more limiting than it may first appear)... but you're just
trading off power for simplicity, and the really interesting uses of
mutations are those that allow access to specific objects from any
number different bits of code, on a program-wide or at least module-wide
scope. Most mediocre programmers could replace assignment with
recursion if that assignment is limited to local variables of a single
subroutine. I don't necessarily agree that the result will be a better
program despite others' conviction on the matter; however, the
difference certainly isn't worth complicating the language with mutation
unless you're willing to allow the interesting uses of mutation as well.
> Mutability by itself does not imply identity. I agree that mutability
> plus identity implies aliasing problems, however.
We might have a terminological issue, then. I'd tend to say that
mutability definitely does imply identity, but identity doesn't imply
aliasing. Same difference.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Joachim Durchholz <[EMAIL PROTECTED]> wrote: > OTOH, isn't that the grail that many people have been searching for: > programming by simply declaring the results that they want to see? Possibly. > No, FPLs are actually just that: compilable postconditions. This seems to me a bit misleading. Perhaps someone will explain why I should stop thinking this way; but currently I classify statements like this in the "well, sort of" slot of my mind. If functional programming were really just compilable postconditions, then functional programmers would be able to skip a good bit of stuff that they really can't. For example, time and space complexity of code is still entirely relevant for functional programming. I can't simply write: (define fib (lambda (x) (if (< x 2) 1 (+ (fib (- x 1)) (fib (- x 2)) and expect the compiler to create an efficient algorithm for me. This is true even though the above is (the LISP transcription of) the most natural way to describe the fibonacci sequence from a mathematical standpoint. It still runs in exponential time, and it still matters that it runs in exponential time; and LISP programmers adapt their so- called declarative code to improve time bounds all the time. This makes it harder for me to call it declarative (or "compilable postconditions") and feel entirely honest. (Yes, I realize that the above could be optimized in a language that does normal order evaluation with common subexpression elimination. and become linear-time. However, that's not true of algorithms in general. It is not the case that all that's needed to find an efficient algorithm for something is to plug it into a Haskell compiler and observe what happens. Or, if that is the case, there are a few CS professors I know who would be quite interested in hearing so.) > Computability issues aren't more or less a factor than with other kinds > of compilers: they do limit what you can do, but these limits are loose > enough that you can do really useful stuff within them (in particular, > express all algorithms). Is it really consistent to say that postconditions allow you to express algorithms? -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marshall <[EMAIL PROTECTED]> wrote: > David Hopwood wrote: > > Marshall wrote: > > > Mightn't it also be possible to > > > leave it up to the programmer whether a given contract > > > was compile-time or runtime? > > > > That would be possible, but IMHO a better option would be for an IDE to give > > an indication (by highlighting, for example), which contracts are > > dynamically > > checked and which are static. > > > > This property is, after all, not something that the program should depend > > on. > > It is determined by how good the static checker currently is, and we want > > to be > > able to improve checkers (and perhaps even allow them to regress slightly in > > order to simplify them) without changing programs. > > Hmmm. I have heard that argument before and I'm conflicted. > > I can think of more reasons than just runtime safety for which I'd > want proofs. Termination for example, in highly critical code; > not something for which a runtime check will suffice. On the > other hand the points you raise are good ones, and affect > the usability of the language. There doesn't seem to be a point of disagreement here. Programmers often need to require certain properties to be checked at compile-time. Others could go either way. There is no property that a program would rationally desire to *require* be checked at runtime; that would only occur because the compiler doesn't know how to check it at compile time. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marshall <[EMAIL PROTECTED]> wrote: > Chris Smith wrote: > > Going back to my > > handy copy of Pierce's book again, he claims that range checking is a > > solved problem in theory, and the only remaining work is in how to > > integrate it into a program without prohibitive amounts of type > > annotation. > > This is in TAPL? Or ATTPL? Can you cite it a bit more specifically? > I want to reread that. It's TAPL. On further review, I may have done more interpretation than I remembered. In particular, the discussion is limited to array bounds checking, though I don't see a fundamental reason why it wouldn't extend to other kinds of range checking against constant ranges as we've been discussing here. Relevant sections are: Page 7 footnote: Mentions other challenges such as tractability that seem more fundamental, but those are treated as trading off against complexity of annotations; in other words, if we didn't require so many annotations, then it might become computationally intractable. The next reference better regarding tractability. Section 30.5, pp. 460 - 465: Gives a specific example of a language (theoretical) developed to use limited dependent types to eliminate array bounds checking. There's a specific mention there that it can be made tractable because the specific case of dependent types needed for bounds checking happens to have efficient algorithms, although dependent types are intractable in the general case. I'm afraid that's all I've got. I also have come across a real-life (though not general purpose) languages that does bounds checking elimination via these techniques... but I can't find them now for the life of me. I'll post if I remember what it is, soon. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marcin 'Qrczak' Kowalczyk <[EMAIL PROTECTED]> wrote:
> Chris Smith <[EMAIL PROTECTED]> writes:
> >> No what happens if right here you code
> >>b := 16;
> >>
> >> Does that again change the type of "b"? Or is that an illegal
> >> instruction, because "b" has the "local type" of (18..22)?
> >
> > It arranges that the expression "b" after that line (barring further
> > changes) has type int{16..16}, which would make the later call to
> > signContract illegal.
>
> The assignment might be performed in a function called there, so it's
> not visible locally.
Indeed, I pointed that out a few messages ago. That doesn't mean it's
impossible, but it does mean that it's more difficult. Eventually, the
compiler will have to stop checking something, somewhere. It certainly
doesn't, though, have to stop at the first functional abstraction it
comes to. The ways that a function modifies the global application
state certainly ought to be considered part of the visible API of that
function, and if we could reasonably express that in a type system, then
that's great! Granted, designing such a type system for an arbitrary
imperative language seems a little scary.
> Propagating constraints from conditionals is not applicable to mutable
> variables, at least not easily.
Certainly it worked in the code from my original response to George.
Regardless of whether it might not work in more complex scenarios (and I
think it could, though it would be more challenging), it still doesn't
seem reasonable to assert that the technique is not applicable. If the
type system fails, then it fails conservatively as always, and some
programmer annotation and runtime check is needed to enforce the
condition.
> I think that constant bounds are not very useful at all. Most ranges
> are not known statically, e.g. a variable can span the size of an
> array.
I think you are overestimating the difficulties here. Specialized
language already exist that reliably (as in, all the time) move array
bounds checking to compile time; that means that there exist at least
some languages that have already solved this problem. Going back to my
handy copy of Pierce's book again, he claims that range checking is a
solved problem in theory, and the only remaining work is in how to
integrate it into a program without prohibitive amounts of type
annotation.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
David Hopwood <[EMAIL PROTECTED]> wrote: > I don't think that placing too much emphasis on any individual example is > the right way of thinking about this. What matters is that, over the range > of typical programs written in the language, the value of the increased > confidence in program correctness outweighs the effort involved in both > adding annotations, and understanding whether any remaining run-time checks > are guaranteed to succeed. Are you really that short on people to disagree with? In this particular branch of this thread, we were discussing George's objection that it would be ridiculous for a type system to check that a variable should be greater than 18. There is no such thing as placing too much emphasis on what we were actually discussing. If you want to discuss something else, feel free to post about it. Why does it bother you that I'm considering George's point? -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
David Hopwood <[EMAIL PROTECTED]> wrote: > Maybe I'm not understanding what you mean by "complete". Of course any > type system of this expressive power will be incomplete (whether or not > it can express conditions 3 to 5), in the sense that it cannot prove all > true assertions about the types of expressions. Ah. I meant complete enough to accomplish the goal in this subthread, which was to ensure that the compiler knows when a particular int variable is guaranteed to be greater than 18, and when it is not. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
David Hopwood <[EMAIL PROTECTED]> wrote: > 1 and 2 are easy enough. 3 to 5 are best expressed as assertions rather > than types. One of us is missing the other's meaning here. If 3 to 5 were expressed as assertions rather than types, then the type system would become incomplete, requiring frequent runtime-checked type ascriptions to prevent it from becoming impossible to write software. That's not my idea of a usable language. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Darren New <[EMAIL PROTECTED]> wrote:
> Chris Smith wrote:
> > // Inside this block, a has type int{17..21} and b has type
> > // int{18..22}
>
> No what happens if right here you code
>b := 16;
>
> Does that again change the type of "b"? Or is that an illegal
> instruction, because "b" has the "local type" of (18..22)?
It arranges that the expression "b" after that line (barring further
changes) has type int{16..16}, which would make the later call to
signContract illegal.
> If the former (i.e., if reassigning to "b" changes the "static type" of
> b, then the term you're looking for is not type, but "typestate".
We're back into discussion terminology, then. How fun. Yes, the word
"typestate" is used to describe this in a good bit of literature.
Nevertheless, a good number of authors -- including all of them that I'm
aware of in programming language type theory -- would agree that "type"
is a perfectly fine word.
When I said b has a type of int{18..22}, I meant that the type that will
be inferred for the expression "b" when it occurs inside this block as
an rvalue will be int{18..22}. The type of the variable didn't change,
because variables don't *have* types. Expressions (or, depending on
your terminology preference, terms) have types. An expression "b" that
occurs after your assignment is a different expression from the one that
occurs before your assignment, so it's entirely expected that in the
general case, it may have a different type.
It's also the case (and I didn't really acknowledge this before) that
the expression "b" when used as an lvalue has a different type, which is
determined according to different rules. As such, the assignment to b
was not at all influenced by the new type that was arranged for the
expression "b" as an rvalue.
(I'm using lvalue and rvalue intuitively; in practice, these would be
assigned on a case-by-case basis along the lines of actual operators or
language syntax.)
> In other words, this is the same sort of test that disallows using an
> unassigned variable in a value-returning expression.
Yes, it is.
> When
>{ int a; int b; b := a; }
> returns a compile-time error because "a" is uninitialized at the
> assignment, that's not the "type" of a, but the typestate. Just FYI.
If you wish to say "typestate" to mean this, be my guest. It is also
correct to say "type".
> It actually works quite well if the language takes advantage of it
> consistantly and allows you to designate your expected typestates and such.
I'm not aware of a widely used language that implements stuff like this.
Are you?
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marshall <[EMAIL PROTECTED]> wrote: > It's never been a strong point. Made worse now that my daughter > is one of those up-at-the-crack-of-dawn types, and not old enough > to understand why it's not nice to jump on mommy and daddy's > bed while they're still asleep. But aren't you actually a time zone > or two east of me? Yes, I confess I'm one time zone to your east, and I was posting later than you. So perhaps it wasn't really past your bedtime. > The fields of an object/struct/what have you are often hidden behind > a method-based interface (sometimes callled "encapsulated") only > because we can't control their values otherwise. I believe there are actually two kinds of encapsulation. The kind of encapsulation that best fits your statement there is the getter/setter sort, which says: "logically, I want an object with some set of fields, but I can't make them fields because I lose control over their values". That part can definitely be replaced, in a suitably powerful language, with static constraints. The other half of encapsulation, though, is of the sort thatI mentioned in my post. I am intentionally choosing to encapsulate something because I don't actually know how it should end up being implemented yet, or because it changes often, or something like that. I may encapsulate the implementation of current tax code specifically because I know that tax code changes on a year-to-year basis, and I want to ensure that the rest of my program works no matter how the tax code is modified. There may be huge structural changes in the tax code, and I only want to commit to leaving a minimal interface. In practice, the two purposes are not cleanly separated from each other. Most people, if asked why they write getters and setters, would respond not only that they want to validate against assignments to the field, but also that it helps isolate changes should they change the internal representation of the class. A publicly visible static constraint language that allows the programmer to change the internal representation of a class obviously can't make reference to any field, since it may cease to exist with a change in representation. > However for a function, the "fields" are the in and out parameters. > The specific values in the relation that the function is aren't known > until runtime either, (and then only the subset for which we actually > perform computation.) > > Did that make sense? I didn't understand that last bit. > There are certainly syntactic issues, but I believe these are amenable > to the usual approaches. The runtime/compile time question, and > decidability seem bigger issues to me. Well, the point of static typing is to do what's possible without reaching the point of undecidability. Runtime support for checking the correctness of type ascriptions certainly comes in handy when you run into those limits. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Marshall <[EMAIL PROTECTED]> wrote:
> Chris Smith wrote:
> >
> > But this starts to look bad, because we used to have this nice property
> > called encapsulation. To work around that, we'd need to make one of a
> > few choices: (a) give up encapsulation, which isn't too happy; (b) rely
> > on type inference for this kind of stuff, and consider it okay if the
> > type inference system breaks encapsulation; or (c) invent some kind of
> > generic constraint language so that constraints like this could be
> > expressed without exposing field names. Choice (b) is incomplete, as
> > there will often be times when I need to ascribe a type to a parameter
> > or some such thing, and the lack of ability to express the complete type
> > system will be rather limiting. Choice (c), though, looks a little
> > daunting.
>
> Damn the torpedoes, give me choice c!
You and I both need to figure out when to go to sleep. :) Work's gonna
suck tomorrow.
> I've been saying for a few years now that encapsulation is only
> a hack to get around the lack of a decent declarative constraint
> language.
Choice (c) was meant to preserve encapsulation, actually. I think
there's something fundamentally important about information hiding that
can't be given up. Hypothetically, say I'm writing an accounting
package and I've decided to encapsulate details of the tax code into one
module of the application. Now, it may be that the compiler can perform
sufficient type inference on my program to know that it's impossible for
my taxes to be greater than 75% of my annual income. So if my income is
stored in a variable of type decimal{0..10}, then the return type of
getTotalTax may be of type decimal{0..75000}. Type inference could do
that.
But the point here is that I don't WANT the compiler to be able to infer
that, because it's a transient consequence of this year's tax code. I
want the compiler to make sure my code works no matter what the tax code
is. The last thing I need to to go fixing a bunch of bugs during the
time between the release of next year's tax code and the released
deadline for my tax software. At the same time, though, maybe I do want
the compiler to infer that tax cannot be negative (or maybe it can; I'm
not an accountant; I know my tax has never been negative), and that it
can't be a complex number (I'm pretty sure about that one). I call that
encapsulation, and I don't think that it's necessary for lack of
anything; but rather because that's how the problem breaks down.
Note that even without encapsulation, the kind of typing information
we're looking at can be very non-trivial in an imperative language. For
example, I may need to express a method signature that is kind of like
this:
1. The first parameter is an int, which is either between 4 and 8, or
between 11 and 17.
2. The second parameter is a pointer to an object, whose 'foo' field is
an int between 0 and 5, and whose 'bar' field is a pointer to another
abject with three fields 'a', 'b', and 'c', each of which has the full
range of an unconstrained IEEE double precision floating point number.
3. After the method returns, it will be known that if this object
previously had its 'baz' field in the range m .. n, it is now in the
range (m - 5) .. (n + 1).
4. After the method returns, it will be known that the object reached by
following the 'bar' field of the second parameter will be modified so
that the first two of its floating point numbers are guaranteed to be of
the opposite sign as they were before, and that if they were infinity,
they are now finite.
5. After the method returns, the object referred to by the global
variable 'zab' has 0 as the value of its 'c' field.
Just expressing all of that in a method signature looks interesting
enough. If we start adding abstraction to the type constraints on
objects to support encapsulation (as I think you'd have to do), then
things get even more interesting.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
I <[EMAIL PROTECTED]> wrote:
> Incidentally, I'm not saying that such a feature would be a good idea.
> It generally isn't provided in languages specifically because it gets to
> be a big pain to maintain all of the type specifications for this kind
> of stuff.
There are other good reasons, too, as it turns out. I don't want to
overstate the "possible" until it starts to sound like "easy, even if
it's a pain". This kind of stuff is rarely done in mainstream
programming languages because it has serious negative consequences.
For example, I wrote that example using variables of type int. If we
were to suppose that we were actually working with variables of type
Person, then things get a little more complicated. We would need a few
(infinite classes of) derived subtypes of Person that further constrain
the possible values for state. For example, we'd need types like:
Person{age:{18..29}}
But this starts to look bad, because we used to have this nice property
called encapsulation. To work around that, we'd need to make one of a
few choices: (a) give up encapsulation, which isn't too happy; (b) rely
on type inference for this kind of stuff, and consider it okay if the
type inference system breaks encapsulation; or (c) invent some kind of
generic constraint language so that constraints like this could be
expressed without exposing field names. Choice (b) is incomplete, as
there will often be times when I need to ascribe a type to a parameter
or some such thing, and the lack of ability to express the complete type
system will be rather limiting. Choice (c), though, looks a little
daunting.
So I'll stop there. The point is that while it is emphatically true
that this kind of stuff is possible, it is also very hard in Java.
Partly, that's because Java is an imperative language, but it's also
because there are fundamental design trade-offs involved between
verbosity, complexity, expressive power, locality of knowledge, etc.
that are bound to be there in all programming languages, and which make
it harder to take one design principle to its extreme and produce a
usable language as a result. I don't know that it's impossible for this
sort of thing to be done in a usable Java-like language, but in any
case, the way to accomplish it is not obvious.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
George Neuner wrote:
> Now this is getting ridiculous.
It's not at all ridiculous. The fact that it seems ridiculous is a good
reason to educate people about what static typing does (and doesn't)
mean, and specifically that it doesn't imply any constraints on the kind
of behavioral property that's being checked; but only on the way that
the check occurs.
(As a subtle point here, we're assuming that this really is an error;
i.e., it shouldn't happen in a correct program. If this is validation
against a user mistake, then that's a different matter; obviously, that
would typically be done with a conditional statement like if, and
wouldn't count as a type error in any context.)
> Regardless of implementation
> language, Pascal's example is of a data dependent, runtime constraint.
99% of program errors (excluding only syntax errors and the like) are
data-dependent runtime errors. Types are a way of classifying that data
until such errors become obvious at compile time.
> Is the compiler to forbid a person object from aging? If not, then
> how does this person object suddenly become a different type when it
> becomes 18? Is this conversion to be automatic or manual?
The object doesn't have a type (this is static typing, remember?), but
expressions do. The expressions have types, and those types are
probably inferred in such a circumstance (at least, this one would even
more of a pain without type inference).
> If your marvelous static type
> checker does the conversion automatically, then obviously types are
> not static and can be changed at runtime.
There really is no conversion, but it does infer the correct types
automatically. It does so by having more complex rules regarding how to
determine the type of an expression. Java's current type system, of
course, is considerably less powerful. In particular, Java mostly
assures that a variable name has a certain type when used as an
expression, regardless of the context of that expression. Only with
some of the Java 5 features (capture conversion, generic method type
inference, etc) did this cease to be the case. It would be necessary to
drop this entirely to make the feature above work. For example,
consider the following in a hypothetical Java language augmented with
integer type ranges:
int{17..26} a;
int{14..22} b;
...
if (a < b)
{
// Inside this block, a has type int{17..21} and b has type
// int{18..22}
signContract(a); // error, because a might be 17
signContract(b); // no error, because even though the declared
// type of b is int{14..22}, it has a local
// type of int{18..22}.
}
(By the way, I hate this example... hence I've changed buyPorn to
signContract, which at least in the U.S. also requires a minimum age of
18. Hopefully, you'll agree this doesn't change the sunstantive
content. :)
Note that when a programmer is validating input from a user, they will
probably write precisely the kind of conditional expression that allows
the compiler to deduce a sufficiently restrictive type and thus allows
the type checker to succeed. Or if they don't do so -- say, for
example, the programmer produces a fencepost error by accidentally
entering "if (age >= 17)" instead of "if (age > 17)" -- then the
compiler will produce a type error as a result. If the programmer
stores the value into a variable of general type int (assuming such a
thing still exists in our augmented Java-esque language), then the
additional type information is forgotten, just like type information is
forgotten when a reference of type String is assigned to a reference of
type Object. In both cases, a runtime-checked cast will be required to
restore the lost type information.
Incidentally, I'm not saying that such a feature would be a good idea.
It generally isn't provided in languages specifically because it gets to
be a big pain to maintain all of the type specifications for this kind
of stuff. However, it is possible, and it is a static type system,
because expressions are assigned typed syntactically, rather than values
being checked for correctness at runtime.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Costanza <[EMAIL PROTECTED]> wrote: > You can ignore the #'. In Scheme this as follows: > > (define blackhole (argument) >blackhole) > > It just means that the function blackhole returns the function blackhole. So, in other words, it's equivalent to (Y (\fa.f)) in lambda calculus, where \ is lambda, and Y is the fixed point combinator? -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Dr.Ruud <[EMAIL PROTECTED]> wrote: > > So it seems to me that we have this ideal point at which it is > > possible to write all correct or interesting programs, and impossible > > to write buggy programs. > > I think that is a misconception. Even at the idealest point it will be > possible (and easy) to write buggy programs. Gödel! I agree. I never said that the ideal point is achievable... only that there is a convergence toward it. (In some cases, that convergence may have stalled at some equilibrium point because of the costs of being near that point.) -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
George Neuner wrote: > We're talking at cross purposes. I'm questioning whether a strong > type system can be completely static as some people here seem to > think. I maintain that it is simply not possible to make compile time > guarantees about *all* runtime behavior and that, in particular, > narrowing conversions will _always_ require runtime checking. Nah, we're not at cross-purposes. I'm discussing the same thing you are. My answer is that while narrowing conversion are not (by definition) type-safe, a sufficiently strong type system can remove these type-unsafe narrowing conversions from a program. > Again, the discussion is about narrowing the result. It doesn't > matter how much the compiler knows about the ranges. When the > computation mixes types, the range of the result can only widen as the > compiler determines the types involved. Well, there are certain operations that can reduce the range. For example, dividing a number that's known to be in the range 6-10 by the exact constant 2 yields a result that's guaranteed to be in the range 3- 5. That's a smaller range. That said, though, there is a more fundamental point here. When you perform a a narrowing type conversion, one of two things must be true: (a) you know more about the types than the compiler, and thus know that the conversion is safe, or (b) your code is broken. Exluding the possibility that you've written buggy code, you must possess some knowledge that convinces you the conversion is safe. In that case, we need only allow the type system to have that same knowledge, and the problem is solved. (One thing worth pointing out here is that it's quite possible that you want to do something different depending on the kind of data. In that case, the sufficiently powerful type system would need to have rules so that an if statemement creates a modified type environment to take that into account. This is different from a runtime type check, in that you are writing explicit code that provides correct program behavior in either case.) -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall <[EMAIL PROTECTED]> 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. You'd need to clarify what you mean by "use static typing". Clearly, if you use forms of static typing that currently exist for Java, there's considerable limitation in expressiveness. If you mean a hypothetical "perfect" type system, then there would be no interesting programs you couldn't write, but such a system may not be possible to implement, and certainly isn't feasible. So it seems to me that we have this ideal point at which it is possible to write all correct or interesting programs, and impossible to write buggy programs. Pure static type systems try to approach that point from the conservative side. Pure dynamic systems (and I actually think that design-by-contract languages and such apply here just as well as type tagging) try to approach that point via runtime verification from the liberal side. (No, this has nothing to do with George Bush or Noam Chomsky... :) Either side finds that the closer they get, the more creative they need to be to avoid creating development work that's no longer commensurate with the gains involved (whether in safety or expressiveness). I think I am now convinced that the answer to the question of whether there is a class of type errors in dynamically checked languages is the same as the answer for static type systems: no. In both cases, it's just a question of what systems may be provided for the purposes of verifying (more or less conservatively or selectively) certain program properties. Type tags or other features that "look like" types are only relevant in that they encapsulate common kinds of constraints on program correctness without requiring the programmer to express those constraints in any more general purpose language. As for what languages to use right now, we are interestingly enough back where Xah Lee started this whole thread. All languages (except a few of the more extreme statically typed languages) are Turing complete, so in order to compare expressiveness, we'd need some other measure that considers some factor or factors beyond which operations are expressible. > There are also what I call "packaging" issues, such as > being able to run partly-wrong programs on purpose so > that one would have the opportunity to do runtime analysis > without having to, say, implement parts of some interface > that one isn't interested in testing yet. These could also > be solved in a statically typed language. (Although > historically it hasn't been done that way.) I'll note veryh briefly that the built-in compiler for the Eclipse IDE has the very nice feature that when a particular method fails to compile, it can still produces a result but replace the implementation of that method with one that just throws an Error. I've taken advantage of that on occasion, though it doesn't allow the same range of options as a language that will just go ahead and try the buggy operations. > 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? I think there might be, but I've > never been able to find a solid example of one. This seems to depend on the specific concept of equivalence of programs that you have in mind. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris F Clark <[EMAIL PROTECTED]> wrote: > And to me the question is what kinds of types apply to these dynamic > programs, where in fact you may have to solve the halting problem to > know exactly when some statement is executed. Yes, I believe (static) type systems will always end up approximating (conservatively) the possible behavior of programs in order to perform their verification. > Or, perhaps we have static type checkers which can do > computations of unbounded complexity. However, I thought that one of > the characteristics of type systems was that they did not allow > unbounded complexity and weren't Turing Complete. Honestly, I suspect you'd get disagreement within the field of type theory about this. Certainly, there are plenty of researchers who have proposed type systems that potentially don't even terminate. The consensus appears to be that they are worth studying within the field of type theory, but I note that Pierce still hasn't dropped the word "tractable" from his definition in his introductory text, despite acknowledging only a couple pages later that languages exist whose type systems are undecidable, and apparently co-authoring a paper on one of them. The consensus seems to be that such systems are interesting if they terminate quickly for interesting cases (in which case, I suppose, you could hope to eventually be able to formalize what cases are interesting, and derive a truly tractable type system that checks that interesting subset). Interestingly, Pierce gives ML as an example of a language whose type checker does not necesarily run in polynomial time (thus failing some concepts of "tractable") but that does just fine in practice. I am just quoting here, so I don't know exactly how this is true. Marshall mentioned template meta-programming in C++, which is definitely Turing- complete. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Pascal Costanza <[EMAIL PROTECTED]> wrote: > > Clearly, in this example, the program > > is invoking an operation (division) on values that are not appropriate > > (zero for the second argument). Hence, if your definition really is a > > definition, then this must qualify. > > Here, you are asking more from dynamic type systems than any existing > type system provides. The definition of what is considered to be a type > error and what not is always part of the specification of a type system. No, I'm not. Were we to follow this path of definition, it would not require that dynamic type systems catch ALL type errors; only that they catch some. Not that it matters, though. I am analyzing the logical consequences of your own definition. If those logical consequences were impossible to fulfill, that would be an even more convincing reason to find a new definition. Concepts of fairness don't enter into the equation. > > If you want to make a statement instead of the sort you've implied > > above... namely that a type error is *any* error that's raised by a type > > system, then that's fine. It certainly brings us closer to static > > types. Now, though, the task is to define a type system without making > > a circular reference to types. You've already rejected the statement > > that all runtime errors are type errors, because you specifically reject > > the division by zero case as a type error for most languages. What is > > that distinction? > > I don't need such a distinction. I can just define what is covered by a > type system and what is not. All type systems work that way. You've got to define something... or, I suppose, just go on using words without definitions. You claimed to give a definition, though. I have been led by others to believe that the right way to go in the dynamic type sense is to first define type errors, and then just call anything that finds type errors a type system. That would work, but it would require a type error. You seem to want to push that work off of the word "type error" and back onto "type system", but that requires that you define what a type system is. It doesn't work for you to say BOTH that a type system is anything that catches type errors, AND that a type error is anything that's caught by a type system. That's not a definition; it's just circular reasoning. If I can plug in: type error = fly, type system = frog, and get a valid instance of your definitions, then you aren't giving much of a definition. (Unless you think that frogs are perfectly good examples of type systems.) Incidentally, in the case of static type systems, we define the system (for example, using the definition given from Pierce many times this thread), and then infer the definition of types and type errors from there. Because a solid definition has been given first for a type system without invoking the concepts of types or type errors, this avoids being circular. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris F Clark <[EMAIL PROTECTED]> wrote: > Ok, we'll get there. First, we need to step back in time, to when there > was roughly algol, cobol, fortran, and lisp. Back then, at least as I > understood things, there were only a few types that generally people > understood integer, real, and (perhaps) pointer. In order to continue my tradition of trying to be as precise as possible, let me point out that of course there were more "candidate types", as it were, and that people understood them just fine. They just didn't have a type system in place to make them into real types, so they didn't think to call them types. > The important thing is the dynamicism of lisp allowed one to write > polymorphic programs, before most of us knew the term. Sure. In exchange for giving up the proofs of the type checker, you could write all kinds of programs. To this day, we continue to write programs in languages with dynamic checking features because we don't have powerful enough type systems to express the corresponding type system. > Thus, as we traverse a list, the first element might be an integer, > the second a floating point value, the third a sub-list, the fourth > and fifth, two more integers, and so on. If you look statically at > the head of the list, we have a very wide union of types going by. > However, perhaps there is a mapping going on that can be discerned. > For example, perhaps the list has 3 distinct types of elements > (integers, floating points, and sub-lists) and it circles through the > types in the order, first having one of each type, then two of each > type, then four of each type, then eight, and so on. The world is now > patterned. > > However, I don't know how to write a static type annotation that > describes exactly that type. I believe that, in fact, it would be trivial to imagine a type system which is capable of expressing that type. Okay, not trivial, since it appears to be necessary to conceive of an infinite family of integer types with only one value each, along with range types, and relationships between them; but it's probably not completely beyond the ability of a very bright 12-year-old who has someone to describe the problem thoroughly and help her with the notation. The more interesting problem is whether this type system could be made: (a) unobstrusive enough, probably via type inference or something along those lines, that it would be usable in practice; and (b) general enough that you could define a basic type operator that applies to a wide range of problems rather than revising your type operator the first time you need a complete 3-tree of similar form. > That may just be my lack of experience > in writing annotations. You would, of course, need a suitable type system first. For example, it appears to me that there is simply no possible way of expressing what you've described in Java, even with the new generics features. Perhaps it's possible in ML or Haskell (I don't know). My point is that if you were allowed to design a type system to meet your needs, I bet you could do it. > And, this brings us to the point, if the data that my program > encounters doesn't match the model I have formulated, then something > is of the wrong "type". Equally importantly, the dynamic tags, have > helped me discover that type error. Sure. The important question, then, is whether there exists any program bug that can't be formulated as a type error. And if so, what good does it do us to talk about type errors when we already have the perfectly good word "bug" to describe the same concept? > Now, the example may have seemed arbitrary to you, and it was in some > sense arbitrary. Arbitrary is good. One of the pesky things that keeps getting in the way here is the intuition attached to the word "type" that makes everyone think "string or integer". -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
George Neuner wrote: > On Sun, 25 Jun 2006 14:28:22 -0600, Chris Smith <[EMAIL PROTECTED]> > wrote: > > >George Neuner wrote: > >> >Undecidability can always be avoided by adding annotations, but of > >> >course that would be gross overkill in the case of index type widening. > >> > >> Just what sort of type annotation will convince a compiler that a > >> narrowing conversion which could produce an illegal value will, in > >> fact, never produce an illegal value? > > > >The annotation doesn't make the narrowing conversion safe; it prevents > >the narrowing conversion from happening. > > That was my point ... you get a program that won't compile. That's not actually the case here. If we're talking only about type conversions and not value conversions (see below), then narrowing conversions are only necessary because you've forgotten some important bit of type information. By adding annotations, you can preserve that piece of information and thus avoid the conversion and get a program that runs fine. > I worked in signal and image processing for many years and those are > places where narrowing conversions are used all the time - in the form > of floating point calculations reduced to integer to value samples or > pixels, or to value or index lookup tables. Often the same > calculation needs to be done for several different purposes. These are value conversions, not type conversions. Basically, when you convert a floating point number to an integer, you are not simply promising the compiler something about the type; you are actually asking the compiler to convert one value to another -- i.e., see to it that whatever this is now, it /becomes/ an integer by the time we're done. This also results in a type conversion, but you've just converted the value to the appropriate form. There is a narrowing value conversion, but the type conversion is perfectly safe. > I can know that my conversion of floating point to integer is going to > produce a value within a certain range ... but, in general, the > compiler can't determine what that range will be. If you mean "my compiler can't", then this is probably the case. If you mean "no possible compiler could", then I'm not sure this is really very likely at all. > Like I said to Ben, I haven't seen any _practical_ static type system > that can deal with things like this. I agree. Such a thing doesn't currently exist for general-purpose programming languages, although it does exist in limited languages for some specific domains. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Pascal Costanza <[EMAIL PROTECTED]> wrote: > Chris Smith wrote: > > Of course zero is not appropriate as a second argument to the division > > operator! I can't possibly see how you could claim that it is. The > > only reasonable statement worth making is that there doesn't exist a > > type system in widespread use that is capable of checking this. > > ...and this is typically not even checked at the stage where type tags > are checked in dynamically-typed languages. Hence, it is not a type > error. (A type error is always what you define to be a type error within > a given type system, right?) Sure, it's not a type error for that language. > Note, this example was in response to David's reply that my definition > turns every runtime error into a type error. That's not the case, and > that's all I want to say. But your definition does do that. Your definition of a type error was when a program attempts to invoke an operation on values that are not appropriate for this operation. Clearly, in this example, the program is invoking an operation (division) on values that are not appropriate (zero for the second argument). Hence, if your definition really is a definition, then this must qualify. > > However, it sounds as > > if you're claiming that it wouldn't be possible for the type system to > > do this? > > No. I only need an example where a certain error is not a type error in > _some_ language. I don't need to make a universal claim here. Definitions are understood to be statements of the form "if and only if". They assert that /everything/ that fits the definition is describable by the word, and /everything/ that doesn't is not describable by the word. If that's not what you meant, then we are still in search of a definition. If you want to make a statement instead of the sort you've implied above... namely that a type error is *any* error that's raised by a type system, then that's fine. It certainly brings us closer to static types. Now, though, the task is to define a type system without making a circular reference to types. You've already rejected the statement that all runtime errors are type errors, because you specifically reject the division by zero case as a type error for most languages. What is that distinction? -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Pascal Costanza <[EMAIL PROTECTED]> wrote:
> Consider division by zero: appropriate arguments for division are
> numbers, including the zero. The dynamic type check will typically not
> check whether the second argument is zero, but will count on the fact
> that the processor will raise an exception one level deeper.
Of course zero is not appropriate as a second argument to the division
operator! I can't possibly see how you could claim that it is. The
only reasonable statement worth making is that there doesn't exist a
type system in widespread use that is capable of checking this.
> This is maybe better understandable in user-level code. Consider the
> following class definition:
>
> class Person {
>String name;
>int age;
>
>void buyPorn() {
> if (< this.age 18) throw new AgeRestrictionException();
> ...
>}
> }
>
> The message p.buyPorn() is a perfectly valid message send and will pass
> both static and dynamic type tests (given p is of type Person in the
> static case).
It appears you've written the code above to assume that the type system
can't cerify that age >= 18... otherwise, the if statement would not
make sense. It also looks like Java, in which the type system is indeed
not powerfule enough to do that check statically. However, it sounds as
if you're claiming that it wouldn't be possible for the type system to
do this? If so, that's not correct. If such a thing were checked at
compile-time by a static type check, then failing to actually provide
that guarantee would be a type error, and the compiler would tell you
so.
Whether you'd choose to call an equivalent runtime check a "dynamic type
check" is a different matter, and highlights the fact that again there's
something fundamentally different about the definition of a "type" in
the static and dynamic sense.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
efore, if you want "real" types, then my first intuition is that you should avoid looking in the static types of programming languages. At best, they happen to coincide frequently with "real" types, but that's only a pragmatic issue if it means anything at all. > So when well-typed program fragments are considered as part of a larger > untyped program, you're suggesting that this so radically changes the > picture, that we can no longer distinguish the types we identified as > being anything beyond programmer reasoning in general? Is this so awfully surprising, when the type system itself is just programmer reasoning? When there ceases to be anything that's provable about the program, there also ceases to be anything meaningful about the type system. You still have the reasoning, and that's all you ever had. You haven't really lost anything, except a name for it. Since I doubt the name had much meaning at all (as explained above), I don't count that as a great loss. If you do, though, then this simple demonstrates that you didn't really mean "type systems (in the static sense)". > > Hopefully, this isn't perceived as too picky. I've already conceded > > that we can use "type" in a way that's incompatible with all existing > > research literature. > > Not *all* research literature. There's literature on various notions of > dynamic type. I haven't seen it, but I'll take your word that some of it exists. I wouldn't tend to read research literature on dynamic types, so that could explain the discrepancy. > > I would, however, like to retain some word with > > actually has that meaning. Otherwise, we are just going to be > > linguistically prevented from discussing it. > > For now, you're probably stuck with "static type". That's fine. I replied to your attempting to apply "static type" in a sense where it doesn't make sense. > In CS, we don't have the luxury > of using the classic mathematician's excuse when confronted with > inconvenient philosophical issues, of claiming that type theory is just > a formal symbolic game, with no meaning outside the formalism. As it turns out, my whole purpose here is to address the idea that type theory for programming languages is limited to some subset of problems which people happen to think of as type problems. If type theorists fourty years ago had limited themselves to considering what people thought of as types back then, we'd be in a considerably worse position today with regard to the expressive power of types in commonly used programming languages. Hence, your implication that insisting on a formal rather than intuitive definition is opposed to the real-world usefulness of the field is actually rather ironic. The danger lies in assuming that unsolved problems are unsolvable, and therefore defining them out of the discussion until the very idea that someone would solve that problem with these techniques starts to seem strange. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris F Clark <[EMAIL PROTECTED]> wrote: > These informal systems, which may not prove what they claim to prove > are my concept of a "type system". Okay, that works. I'm not sure where it gets us, though, except for gaining you the right to use "type system" in a completely uninteresting sense to describe your mental processes. You still need to be careful, since most statements from type theory about type systems tend to implicitly assume the property of being sound. I'm not exactly convinced that it's possible to separate that set of reasoning people do about programs into types and not-types, though. If you want to stretch the definition like this, then I'm afraid that you end up with the entire realm of human thought counting as a type system. I seem to recall that there are epistemologists who would be happy with that conclusion (I don't recall who, and I'm not actually interested enough to seek them out), but it doesn't lead to a very helpful sort of characterization. > It is to the people who are reasoning informally about > the program we wish to communicate that there is a type error. That > is, we want someone who is dealing with the program informally to > realize that there is an error, and that this error is somehow related > to some input not being kept within proper bounds (inside the domain > set) and that as a result the program will compute an unexpected and > incorrect result. I've lost the context for this part of the thread. We want this for what purpose and in what situation? I don't think we necessarily want this as the goal of a dynamic type system, if that's what you mean. There is always a large (infinite? I think so...) list of potential type systems under which the error would not have been a type error. How does the dynamic type system know which informally defined, potentially unsound, mental type system to check against? If it doesn't know, then it can't possibly know that something is a type error. If it does know, then the mental type system must be formally defined (if nothing else, operationally by the type checker.) > I also stress the informality, because beyond a certain nearly trivial > level of complexity, people are not capable of dealing with truly > formal systems. I think (hope, anyway) that you overstate the case here. We can deal with formal systems. We simply make errors. When those errors are found, they are corrected. Nevertheless, I don't suspect that a large part of the established base of theorems of modern mathematics are false, simply because they are sometimes rather involved reasoning in a complex system. Specifications are another thing, because they are often developed under time pressure and then extremely difficult to change. I agree that we should write better specs, but I think the main challenges are political and pragmatic, rather than fundamental to human understanding. > Therefore, I do not want to exlcude from type systems, things wich are > informal and unsound. They are simply artifacts of human creation. Certainly, though, when it is realized that a type system is unsound, it should be fixed as soon as possible. Otherwise, the type system doesn't do much good. It's also true, I suppose, that as soon as a person realizes that their mental thought process of types is unsound, they would want to fix it. The difference, though, is that there is then no formal definition to fix. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
George Neuner wrote: > >Undecidability can always be avoided by adding annotations, but of > >course that would be gross overkill in the case of index type widening. > > Just what sort of type annotation will convince a compiler that a > narrowing conversion which could produce an illegal value will, in > fact, never produce an illegal value? The annotation doesn't make the narrowing conversion safe; it prevents the narrowing conversion from happening. If, for example, I need to subtract two numbers and all I know is that they are both between 2 and 40, then I only know that the result is between -38 and 38, which may contain invalid array indices. However, if the numbers were part of a pair, and I knew that the type of the pair was , then I would know that the difference is between 0 and 38, and that may be a valid index. Of course, the restrictions on code that would allow me to retain knowledge of the form [pair of numbers, 2 through 40, a > b] may be prohibitive. That is an open question in type theory, as a matter of fact; whether types of this level of power may be inferred by any tractable procedure so that safe code like this may be written without making giving the development process undue difficulty by requiring ten times as much type annotations as actual code. There are attempts that have been made, and they don't look too awfully bad. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Andrew McDonagh <[EMAIL PROTECTED]> wrote: > I haven't read all of this thread, I wonder, is the problem to do with > Class being mistaken for Type? (which is usually the issue) Hi Andrew! Not much of this thread has to do with object oriented languages... so the word "class" would be a little out of place. However, it is true that the word "type" is being used in the dynamically typed sense to include classes from class-based OO languages (at least those that include run-time type features), as well as similar concepts in other languages. Some of us are asking for, and attempting to find, a formal definition to justify this concept, and are so far not finding it. Others are saying that the definition is somehow implicitly psychological in nature, and therefore not amenable to formal definition... which others (including myself) find rather unacceptable. I started out insisting that "type" be used with its correct formal definition, but I'm convinced that was a mistake. Asking someone to change their entire terminology is unlikely to succeed. I'm now focusing on just trying to represent the correct formal definition of types in the first place, and make it clear when one or the other meaning is being used. Hopefully, that's a fair summary of the thread to date. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Joachim Durchholz <[EMAIL PROTECTED]> wrote: > > The immutability comes from the fact (perhaps implicit in these > > textbooks, or perhaps they are not really texts on formal type theory) > > that types are assigned to expressions, > > That doesn't *define* what's a type or what isn't! > I'm sorry if you don't like it, but that's all there is. That's the point that's being missed here. It's not as if there's this thing called a type, and then we can consider how it is used by formal type systems. A type, in formal type theory, is ANY label that is assigned to expressions of a program for the purpose of making a formal type system work. If you wish to claim a different use of the word and then try to define what is or is not a type, then be my guest. However, formal type theory will still not adopt whatever restrictions you come up with, and will continue to use the word type as the field has been using the word for a good part of a century now. The first step toward considering the similarities and differences between the different uses of "type" in dynamic type systems and formal type theory is to avoid confusing aspects of one field with the other. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying "latently-typed language" is making a category mistake
Chris Uppal wrote: > It seems to me that most (all ? by definition ??) kinds of reasoning where > we > want to invoke the word "type" tend to have a form where we reduce values (and > other things we want to reason about) to equivalence classes[*] w.r.t the > judgements we wish to make, and (usually) enrich that structure with > more-or-less stereotypical rules about which classes are substitutable for > which other ones. So that once we know what "type" something is, we can > short-circuit a load of reasoning based on the language semantics, by > translating into type-land where we already have a much simpler calculus to > guide us to the same answer. > > (Or representative symbols, or... The point is just that we throw away the > details which don't affect the judgements.) One question: is this more specific than simply saying that we use predicate logic? A predicate divides a set into two subsets: those elements for which the predicate is true, and those for which it is false. If we then apply axioms or theorems of the form P(x) -> Q(x), then we are reasoning from an "equivalence class", throwing away the details we don't care about (anything that's irrelevant to the predicate), and applying stereotypical rules (the theorem or axiom). I don't quite understand what you mean by substituting classes. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
is also over when you decide that the answer is to weaken static typing until the word applies to informal reasoning. If the goal isn't to reach a formal understanding, then the word "static type" shouldn't be used; and when that is the goal, it still shouldn't be applied to process that aren't formalized until they manage to become formalized. Hopefully, this isn't perceived as too picky. I've already conceded that we can use "type" in a way that's incompatible with all existing research literature. I would, however, like to retain some word with actually has that meaning. Otherwise, we are just going to be linguistically prevented from discussing it. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Joachim Durchholz <[EMAIL PROTECTED]> wrote: > Sorry, I have to insist that it's not me who's stretching terms here. > > All textbook definitions that I have seen define a type as the > set/operations/axioms triple I mentioned above. > No mention of immutability, at least not in the definitions. The immutability comes from the fact (perhaps implicit in these textbooks, or perhaps they are not really texts on formal type theory) that types are assigned to expressions, and the program is not likely to change as it executes. Even such oddities as "self-modifying code" are generally formally modeled as a single program, which reduces to other programs as it evaluates just like everything else. The original program doesn't change in the formal model. Hence the common (and, I think, meaningless) distinction that has been made here: that static type systems assign types to expressions (sometimes I hear variables, which is limiting and not really correct), while dynamic type systems do so to values. However, that falls apart when you understand what formal type systems mean by types. What they mean, roughly, is "that label which we attach to an expressions according to fixed rules to help facilitate our proofs". Since dynamic type systems don't do such proofs, I'm having trouble understanding what could possibly be meant by assigning types to values, unless we redefine type. That's what I've been trying to do. So far I've had only limited success, although there is definite potential in one post by Chris Uppal and another by Chris Clark (or maybe I'm just partial to other people named Chris). -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
if that input has been passed in, then this program already beyond the possibility of producing a correct result. #1 would, therefore, be a more global form of analysis than #2, rather than being merely a question of whether you are fallible or not. > Expanding that a little. I expect the language to catch type errors > where I violate model 3. So would I. (Actually, that's another pesky question; if the language "catches" it, did the error even occur, or did the expression just gain a defined result such that domain #3 is indistinguishable from the set of all possible inputs. I tend to agree with Chris Uppal, I suppose, that the latter is really the case, so that dynamic type systems in languages, if they are sound, prevent concept #3 from ever being in question. But, of course, you don't think about it that way, which distinguishes 2 from 3.) -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris F Clark <[EMAIL PROTECTED]> wrote: > Chris Smith <[EMAIL PROTECTED]> writes: > > I thought about this in the context of reading Anton's latest post to > > me, but I'm just throwing out an idea. > > I wrote: > > I think there is some sense of convergence here. > > Apologies for following-up to my own post, but I forgot to describe > the convergence. > > The convergence is there is something more general that what type > theorists talk about when discussing types. Type theory is an > abstraction and systemization of reasoning about types. This more > general reasoning doesn't need to be sound, it just needs to be based > aound "types" and computations. Unfortunately, I have to again reject this idea. There is no such restriction on type theory. Rather, the word type is defined by type theorists to mean the things that they talk about. Something becomes a type the instant someone conceives of a type system that uses it. We could try to define a dynamic type system, as you seem to say, as a system that checks against only what can be known about some ideal type system that would be able to prove the program valid... but I immediately begin to wonder if it would ever be possible to prove that something is a dynamic type system for a general-purpose (Turing- complete) language. If you could define types for a dynamic type system in some stand-alone way, then this difficulty could be largely pushed out of the way, because we could say that anything that checks types is a type system, and then worry about verifying that it's a sound type system without worrying about whether it's a subset of the perfect type system. So back to that problem again. You also wrote: > I consider any case where a program gives a function outside of its > domain a "type error", because an ideal (but unacheivable) type system > would have prevented it. That does not make all errors, type errors, > because if I give a program an input within its domain and it > mis-computes the result, that is not a type error. So what is the domain of a function? (Heck, what is a function? I'll neglect that by assuming that a function is just an expression; otherwise, this will get more complicated.) I see three possible ways to look at a domain. (I need a word here that implies something like a set, but I don't care to verify the axioms of set theory. I'm just going to use set. Hope that's okay.) 1. The domain is the set of inputs to that expression which are going to produce a correct result. 2. The domain is the set of inputs that I expected this expression to work with when I wrote it. 3. The domain is the set of inputs for which the expression has a defined result within the language semantics. So the problem, then, more clearly stated, is that we need something stronger than #3 and weaker than #1, but #2 includes some psychological nature that is problematic to me (though, admittedly, FAR less problematic than the broader uses of psychology to date.) Is that a fair description of where we are in defining types, then? -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall <[EMAIL PROTECTED]> wrote: > I stand corrected: if one is using C and writing self-modifying > code, then one *can* zip one's pants. I believe you'd need quite the creative USB-based or similar peripheral device, as well. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
perty of being types at all. At that point, it's best to drop "static", which is not true anyway, and switch over to the other set of terminology where it makes sense to call them types. > There's a sense in which one can say that yes, the informal types I'm > referring to have an interesting degree of overlap with static types; > and also that static types do, loosely speaking, have the "purpose" of > formalizing the informal properties I'm talking about. Static types have the property of proving ANY properties of a program that may be proven. Certainly, research is pragmatically restricted to specific problems that are (1) useful and (2) solvable. Aside from that, I can't imagine any competent language designer building a type system, but rejecting some useful and solvable feature for the sole reason that he or she doesn't think of it as solving a type error. > But I hardly see why such an informal characterization should bother > you. It doesn't affect the definition of static type. I hope I've explained how it does affect the definition of a static type. > This is based on the assumption that all we're talking about is > "well-defined semantics". Indeed. My statement there will not apply if we find some formal definition of a dynamic type system that doesn't reduce to well-defined semantics once you remove the intuitive bits from it. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying "latently-typed language" is making a category mistake
Chris Uppal wrote: > > I'd be more careful in the analogy, there. Since type theory (as > > applied to programming languages, anyway) is really just a set of > > methods of proving arbitrary statements about program behaviors, > > Not "arbitrary" -- there is only a specific class of statements that any given > type system can address. And, even if a given statement can be proved, then > it > might not be something that most people would want to call a statement of type > (e.g. x > y). [My understanding is that we're discussing static types and type theory here. If you mean dynamic types, then what I'm about to say won't apply.] I acknowledge that there are things that type systems are not going to be capable of proving. These are not excluded a priori from the set of problems that would count as type errors if the language's type system caught them. They are merely excluded for pragmatic reasons from the set of errors that someone would be likely to write a type system to check. That is the case simply because there is a decided disadvantage in having a compiler that isn't guaranteed to ever finish compiling your program, or that doesn't finish in polynomial time on some representative quantity in nearly all cases, etc. On the other hand, statements about program behavior that can be proved in reasonable time frames are universally valid subjects for type systems. If they don't look like type errors now, they nevertheless will when the type system is completed to demonstrate them. If someone were to write a language in which is could be statically proved that a pair of expressions has the property that when each is evaluated to their respective values x and y, (x > y) will be true, then proving this would be a valid subject of type theory. We would then define that property as a type, whose values are all pairs that have the property (or, I suppose, a nominal type whose values are constrained to be pairs that have this property, though that would get painful very quickly), and then checking this property when that type is required -- such as when I am passing (x - y) as a parameter to a function that requires a positive integer -- would be called type checking. In fact, we've come full circle. The intial point on which I disagreed with Torben, while it was couched in a terminological dispute, was whether there existed a (strict) subset of programming errors that are defined to be type errors. Torben defined the relationship between static and dynamic types in terms of when they solved "type errors", implying that this set is the same between the two. A lot of the questions I'm asking elsewhere in this thread are chosen to help me understand whether such a set truly exists for the dynamic type world; but I believe I know enough that I can absolutely deny its existence within the realm of type theory. I believe that even Pierce's phrase "for proving the absence of certain program behaviors" in his definition of a type system only excludes possible proofs that are not interesting for determining correctness, if in fact it limits the possible scope of type systems at all. However, your definition of type errors may be relevant for understanding concepts of dynamic types. I had understood you to say earlier that you thought something could validly qualify as a dynamic type system without regard for the type of problem that it verifies (that was denoted by "something" in a previous conversation). I suppose I was misinterpreting you. So your definition was: > It seems to me that most (all ? by definition ??) kinds of reasoning where > we > want to invoke the word "type" tend to have a form where we reduce values (and > other things we want to reason about) to equivalence classes[*] w.r.t the > judgements we wish to make, and (usually) enrich that structure with > more-or-less stereotypical rules about which classes are substitutable for > which other ones. So that once we know what "type" something is, we can > short-circuit a load of reasoning based on the language semantics, by > translating into type-land where we already have a much simpler calculus to > guide us to the same answer. > > (Or representative symbols, or... The point is just that we throw away the > details which don't affect the judgements.) I don't even know where I'd start in considering the forms of reasoning that are used in proving things. Hmm. I'll have to ponder this for a while. > I think that, just as for static theorem proving, there is informal reasoning > that fits the "type" label, and informal reasoning that doesn't. So while I disagree in the static case, it seems likely that this is true of what is meant by dynamic types, at least by most people in this discussion. I'd previously classified you as not agreeing. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Chris Uppal <[EMAIL PROTECTED]> wrote:
> > if (x != 0) y = 1 / x;
> > else y = 9;
> >
> > is not all that much different from:
> >
> > try { y = 1 / x; }
> > catch (ArithmeticException e) { y = 9; }
> My immediate thought is that the same question is equally applicable (and
> equally interesting -- i.e. no simple answer ;-) for static typing.
I don't see that. Perhaps I'm missing something. If I were to define a
type system for such a language that is vaguely Java-based but has
NotZero as a type, it would basically implement your option [D], and
contain the following rules:
1. NotZero is a subtype of Number
2. Zero is a subtype of Number
3. If x : Number and k : Zero, then "if (x != k) a else b" is well-typed
iff "a" is well-typed when the type-environment is augmented with the
proposition "x : NotZero" and "b" is well-typed when the type-
environment is augmented with the new proposition "x : Zero".
Yes, I know that Java doesn't do this right now in similar places (e.g.,
instanceof), and I don't know why not. This kind of thing isn't even
theoretically interesting at all, except that it makes the proof of
type-soundness look different. As far as I can see, it ought to be
second-nature in developing a type system for a language.
In that case, the first example is well-typed, and also runs as
expected. The second bit of code is not well-typed, and thus
constitutes a type error. The way we recognize it as a type error,
though, is in the fact that the compiler aborts while checking the
typing relation, rather than because of the kind of problem prevented.
Of course, it would be possible to build a static type system in which
different things are true. For example, Java itself is a system in
which both terms are well-typed.
>From a dynamic type perspective, the litany of possibilities doesn't
really do much for defining a dynamic type system, which I thought was
our goal in this bit of the thread. I may not have been clear enough
that I was look for an a priori grounds to classify these two cases by
the definition. I was assuming the existing behavior of Java, which
says that both accomplish the same thing and react in the same way, yet
intuitively we seem to think of one as a type error being "solved",
whereas the other is not.
Anyway, you just wrote another message that is far closer to what I feel
we ought to be thinking about than my question here... so I will get to
reading that one, and perhaps we can take up this point later when and
if it is appropriate.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Dr.Ruud <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall <[EMAIL PROTECTED]> wrote: > Java has a static type system. > Java has runtime tags and tag checks. Yes. > The two are distinct, and neither one is less than complete How is neither one less than complete? -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris Smith <[EMAIL PROTECTED]> wrote: > 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. It's now dawned on me that I need not have restricted this to the OO sense of polymorphism. So let me rephrase. Polymorphism *is* when programming languages do that. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall <[EMAIL PROTECTED]> 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.] 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. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Chris Uppal <[EMAIL PROTECTED]> wrote:
> That was the point of my first sentence (quoted above). I take it, and I
> assumed that you shared my view, that there is no single "the" type system --
> that /a/ type system will yield judgements on matters which it has been
> designed to judge.
Yes, I definitely agree.
My point was that if you leave BOTH the "something" and the response to
verification failure undefined, then your definition of a dynamic type
system is a generalization of the definition of a conditional
expression. That is (using Java),
if (x != 0) y = 1 / x;
else y = 9;
is not all that much different from (now restricting to Java):
try { y = 1 / x; }
catch (ArithmeticException e) { y = 9; }
So is one of them a use of a dynamic type system, where the other is
not?
> Incidentally, using that idea, we get a fairly close analogy to the difference
> between strong and weak static type systems.
I think, actually, that the analogy of the strong/weak distinction
merely has to do with how much verification is done. But then, I
dislike discussion of strong/weak type systems in the first place. It
doesn't make any sense to me to say that we verify something and then
don't do anything if the verification fails. In those cases, I'd just
say that verification doesn't really exist or is incorrectly
implemented. Of course, this would make the type system weaker.
> I wonder whether that way of looking at it -- the "error" never happens since
> it is replaced by a valid operation -- puts what I want to call dynamic type
> systems onto a closer footing with static type systems.
Perhaps. I'm thinking some things over before I respond to Anton. I'll
do that first, and some of my thoughts there may end up being relevant
to this question.
> b) I want to separate the systems of reasoning (whether formal or informal,
> static or dynamic, implemented or merely conceptual, and /whatever/ we call
> 'em
> ;-) from the language semantics. I have no objection to
> being used as part of a language specification, but I don't want to restrict
> types to that.
In the pragmatic sense of this desire, I'd suggest that a way to
characterize this is that your type system is a set of changes to the
language semantics. By applying them to a language L, you obtain a
different language L' which you can then use. If your type system has
any impact on the set of programs accepted by the language (static
types) or on any observable behavior which they exhibit (dynamic types),
then I can't see a justification for claiming that the result is the
same language; and if it does not, then the whole exercise is silly.
> Of course, we can talk about what kinds of operations we want to forbid, but
> that seems (to me) to be orthogonal to this discussion. Indeed, the question
> of dynamic/static is largely irrelevant to a discussion of what operations we
> want to police, except insofar as certain checks might require information
> which isn't available to a (feasible) static theorem prover.
Indeed, that is orthogonal to the discussion from the perspective of
static types. If you are proposing that it is also orthogonal with
respect to dynamic types, that will be a welcome step toward our goal of
a grand unified type theory, I suppose. I have heard from others in
this thread that they don't believe so. I am also interested in your
response to the specific example involving an if statement at the
beginning of this reply.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Re: Saying "latently-typed language" is making a category mistake
Vesa Karvonen <[EMAIL PROTECTED]> wrote: > I think that we're finally getting to the bottom of things. While reading > your reponses something became very clear to me: latent-typing and latent- > types are not a property of languages. Latent-typing, also known as > informal reasoning, is something that all programmers do as a normal part > of programming. To say that a language is latently-typed is to make a > category mistake, because latent-typing is not a property of languages. It's pretty clear to me that there are two different things here. There is the set of reasoning that is done about programs by programmers. This may or may not have some subset called "type reasoning", depending on whether there's a real difference between type reasoning and any other reasoning about program behavior, or it's just a word that we've learned from early experience to use in certain rather arbitrary contexts. In either case, then there are language features that look sort of type-like which can support that same reasoning about program behavior. It is, to me, an interesting question whether those language features are really intrinsically connected to that form of reasoning about program behavior, or whether they are just one way of doing it where others would suffice as well. Clearly, there is some variation in these supporting language features between languages that have them... for example, whether there are only a fixed set of type tags, or an infinite (or logically infinite, anyway) set, or whether the type tags may have other type tags as parameters, or whether they even exist as tags at all or as sets of possible behaviors. Across all these varieties, the phrase "latently typed language" seems to be a reasonable shorthand for "language that supports the programmer in doing latent-type reasoning". Of course, there are still problems here, but really only if you share my skepticism that there's any difference between type reasoning and any other reasoning that's done by programmers on their programs. Perhaps, if you wanted to be quite careful about your distinctions, you may want to choose different words for the two. However, then you run into that same pesky "you can't choose other people's terminology" block again. > A programmer, working in any language, whether typed or not, performs > informal reasoning. I think that is fair to say that there is a > correspondence between type theory and such informal reasoning. The > correspondence is like the correspondence between informal and formal > math. I'd be more careful in the analogy, there. Since type theory (as applied to programming languages, anyway) is really just a set of methods of proving arbitrary statements about program behaviors, a corresponding "informal type theory" would just be the entire set of informal reasoning by programmers about their programs. That would agree with my skepticism, but probably not with too many other people. > An example of a form of informal reasoning that (practically) every > programmer does daily is termination analysis. Or perhaps you agree with my skepticism, here. This last paragraph sounds like you're even more convinced of it than I am. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying "latently-typed language" is making a category mistake
Patricia Shanahan <[EMAIL PROTECTED]> wrote: > Vesa Karvonen wrote: > ... > > An example of a form of informal reasoning that (practically) every > > programmer does daily is termination analysis. There are type systems > > that guarantee termination, but I think that is fair to say that it is not > > yet understood how to make a practical general purpose language, whose > > type system would guarantee termination (or at least I'm not aware of such > > a language). It should also be clear that termination analysis need not > > be done informally. Given a program, it may be possible to formally prove > > that it terminates. > > To make the halting problem decidable one would have to do one of two > things: Depend on memory size limits, or have a language that really is > less expressive, at a very deep level, than any of the languages > mentioned in the newsgroups header for this message. Patricia, perhaps I'm misunderstanding you here. To make the halting problem decidable is quite a different thing than to say "given a program, I may be able to prove that it terminates" (so long as you also acknowledge the implicit other possibility: I also may not be able to prove it in any finite bounded amount of time, even if it does terminate!) The fact that the halting problem is undecidable is not a sufficient reason to reject the kind of analysis that is performed by programmers to convince themselves that their programs are guaranteed to terminate. Indeed, proofs that algorithms are guaranteed to terminate even in pathological cases are quite common. Indeed, every assignment of a worst-case time bound to an algorithm is also a proof of termination. This is, of course, a very good reason to reject the idea that the static type system for any Turing-complete language could ever perform this same kind analysis. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris Smith <[EMAIL PROTECTED]> wrote: > 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" [...] I didn't say that right. Obviously, no one is making all that great an EFFORT to say anything. Typing is not too difficult, after all. What I meant is that there's an argument being made to that effect. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
he language translator. I suppose that it is possible to have an unimplemented type system, but it would be unimplemented only because someone hasn't felt the need nor gotten around to it. Being implementABLE is a crucial part of the definition of a static type system. I am beginning to suspect that you're make the converse of the error I made earlier in the thread. That is, you may be saying things regarding the psychological processes of programmers and such that make sense when discussing dynamic types, and in any case I haven't seen any kind of definition of dynamic types that is more acceptable yet; but it's completely irrelevant to static types. Static types are not fuzzy -- if they were fuzzy, they would cease to be static types -- and they are not a phenomenon of psychology. To try to redefine static types in this way not only ignores the very widely accepted basis of entire field of existing literature, but also leads to false ideas such as that there is some specific definable set of problems that type systems are meant to solve. Skipping ahead a bit... > I agree, to make the comparison perfect, you'd need to define a type > system. But that's been done in various cases. I don't think that has been done, in the case of dynamic types. It has been done for static types, but much of what you're saying here is in contradiction to the definition of a type system in that sense of the word. > The problem we're dealing with in this case is that anything that's not > formally defined is essentially claimed to not exist. 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. So far, all the attempts I've seen to define a dynamic type system seem to reduce to just saying that there is a well- defined semantics for the language. I believe that's unacceptable for several reasons, but the most significant of them is this. It's not reasonable to ask anyone to accept that static type systems gain their essential "type system-ness" from the idea of having well-defined semantics. From the perspective of a statically typed language, this looks like a group of people getting together and deciding that the real "essence" of what it means to be a type system is... and then naming something that's so completely non- essential that we don't generally even mention it in lists of the benefits of static types, because we have already assumed that it's true of all languages except C, C++, and assembly language. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Claudio Grondi <[EMAIL PROTECTED]> wrote: > Looking this thread growing it appears to me, that at least one thing > becomes evident here: > > Xah unwillingness to learn from the bad past experience contaminates > others (who are still posting to his trolling threads). > > Here another try to rescue these ones who are just virgin enough not to > know what I am speaking about: I am enjoying the discussion. I think several other people are, too. (At least, I hope so!) It matters not one whit to me who started the thread, or the merits of the originating post. Why does it matter to you? -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Chris Uppal <[EMAIL PROTECTED]> wrote: > I think we're agreed (you and I anyway, if not everyone in this thread) that > we > don't want to talk of "the" type system for a given language. We want to > allow > a variety of verification logics. So a static type system is a logic which > can > be implemented based purely on the program text without making assumptions > about runtime events (or making maximally pessimistic assumptions -- which > comes > to the same thing really). I suggest that a "dynamic type system" is a > verification logic which (in principle) has available as input not only the > program text, but also the entire history of the program execution up to the > moment when the to-be-checked operation is invoked. I am trying to understand how the above statement about dynamic types actually says anything at all. So a dynamic type system is a system of logic by which, given a program and a path of program execution up to this point, verifies something. We still haven't defined "something", though. We also haven't defined what happens if that verification fails. One or the other or (more likely) some combination of the two must be critical to the definition in order to exclude silly applications of it. Presumably you want to exclude from your definition of a dynamic "type system" which verifies that a value is non-negative, and if so executes the block of code following "then"; and otherwise, executes the block of code following "else". Yet I imagine you don't want to exclude ALL systems that allow the programmer to execute different code when the verification fails (think exception handlers) versus succeeds, nor exclude ALL systems where the condition is that a value is non-negative. In other words, I think that everything so far is essentially just defining a dynamic type system as equivalent to a formal semantics for a programming language, in different words that connote some bias toward certain ways of looking at possibilities that are likely to lead to incorrect program behavior. I doubt that will be an attractive definition to very many people. > Note that not all errors that I would want to call type errors are necessarily > caught by the runtime -- it might go happily ahead never realising that it had > just allowed one of the constraints of one of the logics I use to reason about > the program. What's known as an undetected bug -- but just because the > runtime > doesn't see it, doesn't mean that I wouldn't say I'd made a type error. (The > same applies to any specific static type system too, of course.) In static type system terminology, this quite emphatically does NOT apply. There may, of course, be undetected bugs, but they are not type errors. If they were type errors, then they would have been detected, unless the compiler is broken. If you are trying to identify a set of dynamic type errors, in a way that also applies to statically typed languages, then I will read on. > But the checks the runtime does perform (whatever they are, and whenever they > happen), do between them constitute /a/ logic of correctness. In many highly > dynamic languages that logic is very close to being maximally optimistic, but > it doesn't have to be (e.g. the runtime type checking in the JMV is pretty > pessimistic in many cases). > > Anyway, that's more or less what I mean when I talk of dynamically typed > language and their dynamic type systems. So my objections, then, are in the first paragraph. > [**] Although there are operations which are not possible, reading another > object's instvars directly for instance, which I suppose could be taken to > induce a non-trivial (and static) type logic. In general, I wouldn't consider a syntactically incorrect program to have a static type error. Type systems are, in fact, essentially a tool so separate concerns; specifically, to remove type-correctness concerns from the grammars of programming languages. By doing so, we are able at least to considerably simplify the grammar of the language, and perhaps also to increase the "tightness" of the verification without risking making the language grammar context-sensitive. (I'm unsure about the second part of that statement, but I can think of no obvious theoretical reason to assume that combining a type system with a regular context- free grammar would yield another context-free grammar. Then again, formal languages are not my strong point.) -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Pascal Costanza <[EMAIL PROTECTED]> wrote:
> What about this: You get a type error when the program attempts to
> invoke an operation on values that are not appropriate for this operation.
>
> Examples: adding numbers to strings; determining the string-length of a
> number; applying a function on the wrong number of parameters; applying
> a non-function; accessing an array with out-of-bound indexes; etc.
Hmm. I'm afraid I'm going to be picky here. I think you need to
clarify what is meant by "appropriate". If you mean "the operation will
not complete successfully" as I suspect you do, then we're closer... but
this little snippet of Java (HORRIBLE, DO NOT USE!) confuses the matter
for me:
int i = 0;
try
{
while (true) process(myArray[i++]);
}
catch (IndexOutOfBoundsException e) { }
That's an array index from out of bounds that not only fails to be a
type error, but also fails to be an error at all! (Don't get confused
by Java's having a static type system for other purposes... we are
looking at array indexing here, which Java checks dynamically. I would
have used a dynamically typed language, if I could have written this as
quickly.)
I'm also unsure how your definition above would apply to languages that
do normal order evaluation, in which (at least in my limited brain) it's
nearly impossible to break down a program into sequences of operations
on actual values. I suppose, though, that they do eventually happen
with primitives at the leaves of the derivation tree, so the definition
would still apply.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Rob Warnock <[EMAIL PROTECTED]> wrote:
> Another language which has *neither* latent ("dynamic") nor
> manifest ("static") types is (was?) BLISS[1], in which, like
> assembler, variables are "just" addresses[2], and values are
> "just" a machine word of bits.
I'm unsure that it's correct to describe any language as having no
latent typing, in the sense that's being used in this thread. It might
be more correct to say "so specified latent typing" and/or "no latent
typing beyond what is provided by the execution environment, including
the CPU, virtual memory system, etc." as appropriate. I am aware of no
hardware environment that really accepts all possible values for all
possible operations without the potential of somehow signaling a type
violation.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
David Hopwood <[EMAIL PROTECTED]> wrote: > Typical programming languages have many kinds of semantic error that can occur > at run-time: null references, array index out of bounds, assertion failures, > failed casts, "message not understood", ArrayStoreExceptions in Java, > arithmetic overflow, divide by zero, etc. > > Conventionally, some of these errors are called "type errors" and some are > not. But there seems to be little rhyme or reason to this categorization, as > far as I can see. If in a particular language, both array index bounds errors > and "message not understood" can occur at run-time, then there's no objective > reason to call one a type error and the other not. Both *could* potentially > be caught by a type-based analysis in some cases, and both *are not* caught > by such an analysis in that language. Incidentally, yes! Filtering out the terminology stuff [as hard as this may be to believe on USENET where half the world seems to be trolls, I really was not so aware when I originally posted of how some communities use terminology and where the motivations come from], this was my original point. In the static sense, there is no such thing as a type error; only an error that's caught by a type system. I don't know if the same can be said of dynamic types. Some people here seem to be saying that there is a universal concept of "type error" in dynamic typing, but I've still yet to see a good precise definition (nor a good precise definition of dynamic typing at all). In either case it doesn't make sense, then, to compare how static type systems handle type errors versus how dynamic systems handle type errors. That's akin to asking how comparing how much many courses are offered at a five star restaurant versus how many courses are offered by the local university. (Yes, that's an exaggeration, of course. The word "type" in the static/dynamic typing world at least has a closer to common root.) > A more consistent terminology would reserve "type error" for errors that > occur when a typechecking/inference algorithm fails, or when an explicit > type coercion or typecheck fails. I am concerned as to whether that actually would turn out to have any meaning. If we are considering array length bounds checking by type systems (and just to confuse ourselves, by both static and dynamic type systems), then is the error condition that gets raised by the dynamic system a type error? Certainly, if the system keeps track of the fact that this is an array of length 5, and uses that information to complain when someone tries to treat the array as a different type (such as an array of length >= 7, for example), certainly that's a type error, right? Does the reference to the seventh index constitute an "explicit" type coercion? I don't know. It seems pretty explicit to me, but I suspect some may not agree. The same thing would certainly be a type error in a static system, if indeed the static system solved the array bounds problem at all. While this effort to salvage the term "type error" in dynamic languages is interesting, I fear it will fail. Either we'll all have to admit that "type" in the dynamic sense is a psychological concept with no precise technical definition (as was at least hinted by Anton's post earlier, whether intentionally or not) or someone is going to have to propose a technical meaning that makes sense, independently of what is meant by "type" in a static system. > In the terminology I'm suggesting, the object has no type in this language > (assuming we're talking about a Smalltalk-like language without any type > system > extensions). I suspect you'll see the Smalltalk version of the objections raised in response to my post earlier. In other words, whatever terminology you think is consistent, you'll probably have a tough time convincing Smalltalkers to stop saying "type" if they did before. If you exclude "message not understood" as a type error, then I think you're excluding type errors from Smalltalk entirely, which contradicts the psychological understanding again. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall <[EMAIL PROTECTED]> wrote: > Well, it strikes me that some of what the dynamic camp likes > is the actual *absence* of declared types, or the necessity > of having them. At the very least, requiring types vs. not requiring > types is mutually exclusive. So you're saying, then, that while static typing and dynamic typing are not themselves mutually exclusive, there are people whose concerns run as much in the "not statically typed" direction as in the "dynamically typed" direction? I agree that this is undoubtedly true. That (not statically typed) seems to be what gets all the attention, as a matter of fact. Most programmers in modern languages assume, though, that there will be some kind of safeguard against writing bad code with unpredictable consequences, so in practice "not statically typed" correlates strongly with "dynamically typed". Nevertheless, the existence of languages that are clearly "both" suggests that they should be considered separately to at least some extent. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall <[EMAIL PROTECTED]> wrote: > I think what this highlights is the fact that our existing terminology > is not up to the task of representing all the possible design > choices we could make. Some parts of dynamic vs. static > a mutually exclusive; some parts are orthogonal. Really? I can see that in a strong enough static type system, many dynamic typing features would become unobservable and therefore would be pragmatically excluded from any probable implementations... but I don't see any other kind of mutual exclusion between the two. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
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 programs (e.g. by throwing exceptions as
> appropriate).
So the compiler now attempts to prove theorems about the program, but
once it has done so it uses the results merely to optimize its runtime
behavior and then throws the results away. I'd call that not a
statically typed language, then. The type-checking behavior is actually
rather irrelevant both to the set of valid programs of the language, and
to the language semantics (since the same could be accomplished without
the type checking). It is only relevant to performance. Obviously, the
language probably qualifies as dynamically typed for most common
definitions of that term, but I'm not ready to accept one definition and
claim to understand it, yet, so I'll be cautious about classsifying the
language.
> The compiler might actually refuse to compile type-incorrect programs,
> depending on compiler flags and/or declarations in the code.
Then those compiler flags would cause the compiler to accept a different
language, and that different language would be a statically typed
language (by which I don't mean to exclude the possibility of its also
being dynamically typed).
> Typed ("strongly typed") it is, but is it statically typed or
> dynamically typed?
So my answer is that it's not statically typed in the first case, and is
statically typed in the second case, and it intuitively appears to be
dynamically typed at least in the first, and possibly in the second as
well.
--
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
to prove in the first place, and whether the effort of proving them was worth the additional confidence I have in my software systems. I acknowledge those questions. I believe they are valid. I don't know the answers. As an intuitive judgement call, I tend to think that knowing the correctness of these things is of considerable benefit to software development, because it means that I don't have as much to think about at any one point in time. I can validly make more assumptions about my code and KNOW that they are correct. I don't have to trace as many things back to their original source in a different module of code, or hunt down as much documentation. I also, as a practical matter, get development tools that are more powerful. (Whether it's possible to create the same for a dynamically typed language is a potentially interesting discussion; but as a practical matter, no matter what's possible, I still have better development tools for Java than for JavaScript when I do my job.) In the end, though, I'm just not very interested in them at the moment. For me, as a practical matter, choices of programming language are generally dictated by more practical considerations. I do basically all my professional "work" development in Java, because we have a gigantic existing software system written in Java and no time to rewrite it. On the other hand, I do like proving theorems, which means I am interested in type theory; if that type theory relates to programming, then that's great! That's probably not the thing to say to ensure that my thoughts are relevant to the software development "industry", but it's nevertheless the truth. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Rob Thorpe <[EMAIL PROTECTED]> wrote: > I'm not talking about correctness, I'm talking about typing. > Since you wrote that, I've come to understand that you meant something specific by "property" which I didn't understand at first. From my earlier perspective, it was obvious that correctness was a property of a value. I now realize that you meant a property that's explicitly associated with the value and plays a role in determining the behavior of the language. Sorry for the confusion. > No, that isn't what I said. What I said was: > "A language is latently typed if a value has a property - called it's > type - attached to it, and given it's type it can only represent values > defined by a certain class." No, to answer Andreas' concern, you would only need to say: ... if a value has a property - called it's type - attached to it, and the language semantics guarantees that only values defined by a certain class may have that same property attached. > Easy, any statically typed language is not latently typed. I'm actually not sure I agree with this at all. I believe that reference values in Java may be said to be latently typed. This is the case because each reference value (except null, which may be tested separately) has an explicit property (called its "class", but surely the word doesn't make any difference), such that the language semantics guarantees that only a certain class of values may have that same property, and the property is used to determine behavior of the language in many cases (for example, in the case of type-based polymorphism, or use of Java's instanceof operator). Practically all class-based OO languages are subject to similar consideration, as it turns out. I'm unsure whether to consider explicitly stored array lengths, which are present in most statically typed languages, to be part of a "type" in this sense or not. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
I <[EMAIL PROTECTED]> wrote: > Static type systems detect some bugs at compile time, whereas > dynamic type systems detect type violations at runtime. PS: In order to satisfy the Python group (among others not on the cross- post list), we'd need to include "duck typing," which fits neither of the two definitions above. We'd probably need to modify the definition of dynamic type systems, since most source tend to classify it as a dynamic type system. It's getting rather late, though, and I don't intend to think about how to do that. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
efinition of "type" from programming > > language type theory to eliminate the requirement that they are > > syntactic in nature yields something meaningless. Any concept of > > "type" that is not syntactic is a completely different thing from > > static types. > > 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, though, because I doubt we'd be right here in this conversation if we did. This aspect of being a "completely different thing" is why I objected to Torben's statement of the form: static type systems detect type violations at compile time, whereas dynamic type systems detect type violations at runtime. The problem with that statement is that "type violations" means different things in the first and second half, and that's obscured by the form of the statement. It would perhaps be clearer to say something like: Static type systems detect some bugs at compile time, whereas dynamic type systems detect type violations at runtime. Here's one interesting consequence of the change. It is easy to recognize that static and dynamic type systems are largely orthogonal to each other in the sense above. Java, for example (since that's one of the newsgroups on the distribution list for this thread), restricting the field of view to reference types for simplicity's sake, clearly has both a very well-developed static type system, and a somewhat well- developed dynamic type system. There are dynamic "type" errors that pass the compiler and are caught by the runtime; and there are errors that are caught by the static type system. There is indeed considerable overlap involved, but nevertheless, neither is made redundant. In fact, one way of understanding the headaches of Java 1.5 generics is to note that the two different meanings of "type errors" are no longer in agreement with each other! > We're all rubes here, so don't try to educate us with your > high-falutin' technical terms. That's not my intention. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall <[EMAIL PROTECTED]> wrote: > While I am quite sympathetic to this point, I have to say that > this horse left the barn quite some time ago. I don't think so. Perhaps it's futile to go scouring the world for uses of the phrase "dynamic type" and eliminating them. It's not useless to point out when the term is used in a particularly confusing way, though, as when it's implied that there is some class of "type errors" that is strictly a subset of the class of "errors". Terminology is often confused for historical reasons, but incorrect statements eventually get corrected. > PS. Hi Chris! Hi! Where are you posting from these days? -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
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 typing community has its > own set of > terminology and that's fine. However, we Lisp hackers are not used to > this terminology. > It confuses us. *We* know what we mean by `dynamically typed', and we > suspect *you* do, too. I know what you mean by types in LISP. The phrase "dynamically typed," though, was explicitly introduced as a counterpart to "statically typed" in order to imply (falsely) that the word "typed" has related meanings in those two cases. Nevertheless, I did not really object, since it's long since passed into common usage, until Torben attempted to give what I believe are rather meaningless definitions to those words, in terms of some mythical thing called "type violations" that he seems to believe exist apart from any specific type systems. (Otherwise, how could you define kinds of type systems in terms of when they catch type violations?) > > This cleaner terminology eliminates a lot of confusion. > > Hah! Look at the archives. I'm not sure what you mean here. You would like me to look at the archives of which of the five groups that are part of this conversation? In any case, the confusion I'm referring to pertains to comparison of languages, and it's already been demonstrated once in the half-dozen or so responses to this branch of this thread. > > If types DON'T mean a compile-time method for proving the > > absence of certain program behaviors, then they don't mean anything at > > all. > > Nonsense. Please accept my apologies for not making the context clear. I tried to clarify, in my response to Pascal, that I don't mean that the word "type" can't have any possible meaning except for the one from programming language type theory. I should modify my statement as follows: An attempt to generalize the definition of "type" from programming language type theory to eliminate the requirement that they are syntactic in nature yields something meaningless. Any concept of "type" that is not syntactic is a completely different thing from static types. Basically, I start objecting when someone starts comparing "statically typed" and "dynamically typed" as if they were both varieties of some general concept called "typed". They aren't. Furthermore, these two phrases were invented under the misconception that that are. If you mean something else by types, such as the idea that a value has a tag indicating its range of possible values, then I tend to think it would be less confusing to just say "type" and then clarify the meaning it comes into doubt, rather than adopting language that implies that those types are somehow related to types from type theory. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Costanza <[EMAIL PROTECTED]> wrote: > How does your definition exclude the trivial type system in which the > only typing judgment states that every expression is acceptable? It is not necessary to exclude that trivial type system. Since it is useless, no one will implement it. However, if pressed, I suppose one would have to admit that that definition includes a type system that is just useless. I do, though, prefer Pierce's definition: A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute. (Benjamin Pierce, Types and Programming Languages, MIT Press, pg. 1) Key words include: - tractable: it's not sufficient to just evaluate the program - syntactic: types are tied to the kinds of expressions in the language - certain program behaviors: while perhaps confusing out of context, there is nowhere in the book a specification of which program behaviors may be prevented by type systems and which may not. In context, the word "certain" there is meant to make it clear that type systems should be able to specifically identify which behaviors they prevent, and not that there is some universal set. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Costanza <[EMAIL PROTECTED]> wrote: > Types can be represented at runtime via type tags. You could insist on > using the term "dynamically tagged languages", but this wouldn't change > a lot. Exactly _because_ it doesn't make sense in a statically typed > setting, the term "dynamically typed language" is good enough to > communicate what we are talking about - i.e. not (static) typing. Okay, fair enough. It's certainly possible to use the same sequence of letters to mean two different things in different contexts. The problem arises, then, when Torben writes: : That's not really the difference between static and dynamic typing. : Static typing means that there exist a typing at compile-time that : guarantess against run-time type violations. Dynamic typing means : that such violations are detected at run-time. This is clearly not using the word "type" to mean two different things in different contexts. Rather, it is speaking under the mistaken impression that "static typing" and "dynamic typing" are varieties of some general thing called "typing." In fact, the phrase "dynamically typed" was invented to do precisely that. My argument is not really with LISP programmers talking about types, by which they would mean approximately the same thing Java programmers mean by "class." My point here concerns the confusion that results from the conception that there is this binary distinction (or continuum, or any other simple relationship) between a "statically typed" and a "dynamically typed" language. Torben's (and I don't mean to single out Torben -- the terminology is used quite widely) classification of dynamic versus static type systems depends on the misconception that there is some universal definition to the term "type error" or "type violation" and that the only question is how we address these well-defined things. It's that misconception that I aim to challenge. > No, there is more: There is safe and unsafe code (i.e., code that throws > exceptions or that potentially just does random things). There are also > runtime systems where you have the chance to fix the reason that caused > the exception and continue to run your program. The latter play very > well with dynamic types / type tags. Yes, I was oversimplifying. > What type system catches division by zero? That is, statically? I can define such a type system trivially. To do so, I simply define a type for integers, Z, and a subtype for non-zero integers, Z'. I then define the language such that division is only possible in an expression that looks like << z / z' >>, where z has type Z and z' has type Z'. The language may then contain an expression: z 0? t1 : t2 in which t1 is evaluated in the parent type environment, but t2 is evaluated in the type environment augmented by (z -> Z'), the type of the expression is the intersection type of t1 and t2 evaluated in those type environments, and the evaluation rules are defined as you probably expect. > Would you like to program in such a language? No. Type systems for real programming languages are, of course, a balance between rigor and usability. This particular set of type rules doesn't seem to exhibit a good balance. Perhaps there is a way to achieve it in a way that is more workable, but it's not immediately obvious. As another example, from Pierce's text "Types and Programming Languages", Pierce writes: "Static elimination of array-bounds checking is a long-standing goal for type system designers. In principle, the necessary mechanisms (based on dependent types) are well understood, but packaging them in a form that balances expressive power, predictability and tractability of typechecking, and complexity of program annotations remains a significant challenge." Again, this could quite validly be described as a type error, just like division by zero or ANY other program error... it's just that the type system that solves it doesn't look appealing, so everyone punts the job to runtime checks (or, in some cases, to the CPU's memory protection features and/or the user's ability to fix resulting data corruption). Why aren't these things commonly considered type errors? There is only one reason: there exists no widely used language which solves them with types. (I mean in the programming language type theory sense of "type"; since many languages "tag" arrays with annotations indicating their dimensions, I guess you could say that we do solve them with types in the LISP sense). > Your problem doesn't exist. Just say "types" when you're amongst your > own folks, and "sta
Re: What is Expressiveness in a Computer Language
Rob Thorpe <[EMAIL PROTECTED]> wrote: > A language is latently typed if a value has a property - called it's > type - attached to it, and given it's type it can only represent values > defined by a certain class. I'm assuming you mean "class" in the general sense, rather than in the sense of a specific construct of some subset of OO programming languages. Now I define a class of values called "correct" values. I define these to be those values for which my program will produce acceptable results. Clearly there is a defined class of such values: (1) they are immediately defined by the program's specification for those lines of code that produce output; (2) if they are defined for the values that result from any expression, then they are defined for the values that are used by that expression; and (3) for any value for which correctness is not defined by (1) or (2), we may define its "correct" values as the class of all possible values. Now, by your definition, any language which provides checking of that property of correctness for values is latently typed. Of course, there are no languages that assign this specific class of values; but ANY kind of correctness checking on values that a language does (if it's useful at all) is a subset of the perfect correctness checking system above. Apparently, we should call all such systems "latent type systems". Can you point out a language that is not latently typed? I'm not trying to poke holes in your definition for fun. I am proposing that there is no fundamental distinction between the kinds of problems that are "type problems" and those that are not. Types are not a class of problems; they are a class of solutions. Languages that solve problems in ways that don't assign types to variables are not typed languages, even if those same problems may have been originally solved by type systems. > Untyped and type-free mean something else: they mean no type checking > is done. Hence, they don't exist, and the definitions being used here are rather pointless. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Torben Ægidius Mogensen <[EMAIL PROTECTED]> wrote: > That's not really the difference between static and dynamic typing. > Static typing means that there exist a typing at compile-time that > guarantess against run-time type violations. Dynamic typing means > that such violations are detected at run-time. This is orthogonal to > strong versus weak typing, which is about whether such violations are > detected at all. The archetypal weakly typed language is machine code > -- you can happily load a floating point value from memory, add it to > a string pointer and jump to the resulting value. ML and Scheme are > both strongly typed, but one is statically typed and the other > dynamically typed. 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". If anyone considers "untyped" to be perjorative, as some people apparently do, then I'll note that another common term is "type-free," which is marketing-approved but doesn't carry the misleading connotations of "dynamically typed." We are quickly losing any rational meaning whatsoever to the word "type," and that's quite a shame. By way of extending the point, let me mention that there is no such thing as a universal class of things that are called "run-time type violations". At runtime, there is merely correct code and incorrect code. To the extent that anything is called a "type" at runtime, this is a different usage of the word from the usage by which we may define languages as being statically typed (which means just "typed"). In typed OO languages, this runtime usage is often called the "class", for example, to distinguish it from type. This cleaner terminology eliminates a lot of confusion. For example, it clarifies that there is no binary division between strongly typed languages and weakly typed languages, since the division between a "type error" and any other kind of error is arbitrary, depending only on whether the type system in a particular language happens to catch that error. For example, type systems have been defined to try to catch unit errors in scientific programming, or to catch out-of-bounds array indices... yet these are not commonly called "type errors" only because such systems are not in common use. This also leads us to define something like "language safety" to encapsulate what we previously would have meant by the phrase "strongly dynamically typed language". This also is a more general concept than we had before. Language safety refers to a language having well-defined behavior for as many operations as feasible, so that it's less likely that someone will do something spectacularly bad. Language safety may be achieved either by a type system or by runtime checks. Again, it's not absolute... I'm aware of no language that is completely determinate, at least if it supports any kind of concurrency. This isn't just a matter of preference in terminology. The definitions above (which are, in my experience, used widely by most non-academic language design discussions) actually limit our understanding of language design by pretending that certain delicate trade-offs such as the extent of the type system, or which language behavior is allowed to be non-deterministic or undefined, are etched in stone. This is simply not so. If types DON'T mean a compile-time method for proving the absence of certain program behaviors, then they don't mean anything at all. Pretending that there's a distinction at runtime between "type errors" and "other errors" serves only to confuse things and artificially limit which problems we are willing to concieve as being solvable by types. > Anyway, type inference for statically typed langauges don't make them > any more dynamically typed. Indeed it does not. Unless it weakens the ability of a compiler to prove the absence of certain program behaviors (which type inference does not), it doesn't move anything on the scale toward a type-free language. That being said, though, it is considered a feature of some programming languages that the programmer is asked to repeat type information in a few places. The compiler may not need the information, but for precisely the reason that the information is redundant, the compiler is then able to check the consistency of the programmer in applying the type. I won't get into precisely how useful this is, but it is nevertheless present as an advantage to outweigh the wordiness. -- Chris Smith - Lead Software Developer / Technical Trainer MindIQ Corporation -- http://mail.python.org/mailman/listinfo/python-list
Re: Includeing Python in text files
Diez B. Roggisch wrote: > Paolo Pantaleo wrote: > > >>I am working on this: >> >>I have a text file, containig certain section in the form >>> python code here >>py?> >> >>I parse the text file and substitute the python code with its result >>[redirecting sys.stdin to a StringIO]. It something like php or >>embedded perl. >> >>So my little toy works not bad, but I was wondering if such a feature >>already existed, if yes, can you point me out some links? > > > Its a templating system, and there are a gazillion out there. Some of them > are listed here: > > http://www.cherrypy.org/wiki/ChoosingATemplatingLanguage > > > Diez > > > I'm just getting into programming so this may be a dumb question...but why would you want to do this? What is templating good for? Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: The whitespaceless frontend
> "Stelios" == Stelios Xanthakis <[EMAIL PROTECTED]> writes: Stelios> It had to happen :) http://pyvm32.infogami.com/EPL Stelios> Seriously, this is not so much about the whitespace as Stelios> for the new features, which might interest people who are Stelios> thinking about new features. More specifically, "methods" Stelios> and the "$" operator are really great and seem to solve Stelios> the problem with having to type "self." all the time. Stelios> The new syntax has been tested in core libraries of pyvm. Stelios> Feedback is welcome, but preferably not in c.l.py because Stelios> indentation can be a dangerous topic :) Stelios> Cheers, Stelios> Stelios I submit that this kind of work will make generated code a lot easier. There is this perverse joy I take in writing polyglot code, but I wouldn't want to consider, say, some kind of UML model-driven python code generator--the significant whitespace that's so dandy on the human eye would be un-fun for non-trivial code. Props, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Cheese Shop: some history for the new-comers--Gratuitous self-quote
http://it.slashdot.org/article.pl?sid=05/08/01/0150222 Customer: Well, then, have you got any Venezuelan Beaver Cheese? Owner: Sir, this is a self-respecting establishment. I shall thank you not to imply we should traffic in VB, much less, even mention the foul product. Props, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: linux clipboard?
> "Rene" == Rene Pijlman <[EMAIL PROTECTED]> writes: Rene> [EMAIL PROTECTED]: >> how can i copy text to the linux clipboard? Rene> Linux is an operating system. It doesn't have a Rene> clipboard. The clipboard is provided by desktop frameworks, Rene> such as KDE or Gnome. Rene> -- René Pijlman Actually, Linux is the kernel, and the full system is GNU/Linux, as RMS would hasten to point out. Isn't the clipboard a basic X component? However, for basic text, don't overlook the humble shell facilities like | , > , < , and >> R, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Learning different languages
> "Rich" == Rich <[EMAIL PROTECTED]> writes: Rich> Hi, Rich> (this is a probably a bit OT here, but comp.lang seems Rich> rather desolated, so I'm not sure I would get an answer Rich> there. And right now I'm in the middle of learning Python Rich> anyway so...) Rich> Anyway, my question is: what experience you people have with Rich> working with different languages at the same time? I think it's akin to speaking multiple human languages. I find, in the web context, that multiple languages help to understand where stuff happens. If it's JavaScript, it's happening in the browser. If it's (other scripting language), it's on the web server. If it's SQL, it's on the database server. I realize that there are other configuration possibilities, e.g. JavaScript on the web server. R, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: editor for Python on Linux
> "Sriram" == Sriram Krishnan <[EMAIL PROTECTED]> writes: >> Mladen Adamovic wrote: >> Hi! I wonder which editor or IDE you can recommend me for >> writing Python programs. I tried with jEdit but it isn't >> perfect. >> Check out http://wiki.python.org/moin/PythonEditors. I personally use Emacs Yeah, emacs: yeah. Particularly with the Emacs Code Browser add-on. R, C -- http://mail.python.org/mailman/listinfo/python-list
Re: Activestate python installation
> "mik3" == mik3 <[EMAIL PROTECTED]> writes: mik3> hi this is a question regarding installing Activestate mik3> python whenever i try to install the latest Activestate mik3> Python on WinXP SP2, it gives me error saying "The wizard mik3> was interrupted before Activestate 2.4.2 could be completely mik3> installed. Your system has not been modified ." any mik3> ideas why this is going on? thanks Administrator? Writeable drive? Is there an install log file you could locate? R, C -- http://mail.python.org/mailman/listinfo/python-list
Re: Inserting record with Microsoft Access
> "Frank" == Frank Millman <[EMAIL PROTECTED]> writes: Frank> SELECT @@IDENTITY returns the most recent of all Frank> inserts. If you have a complex transaction which triggers Frank> inserts into other tables, it may not return the one you Frank> want. Frank> This one allows you to specify the tablename, and it will Frank> return the most recent key inserted into that table. Frank> I got this from the built-in help for SQLServer. I cannot Frank> say whether it works for Access as well. Frank> Frank I've used SELECT @@IDENTITY to good effect, but I agree that there is no telling what the scope of the variable holding @@IDENTITY is, and it could turn out to be a kick in the naughty bits. Depending on the criteria, you might effect the INSERT for a parent record, and contiue any child record INSERTs by means of the DLookup() function (Access-only syntactic sugar around nested SELECTs) without ever having to know the key you would have discovered through SELECT @@IDENTITY. R, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: logging module example
One thing that made little sense to me when I was first working on
this is the following variation on the original script:
#--begin test script--
import logging
forest = ["root","trunk","branch","leaf"]
lumber_jack = {forest[0] : logging.DEBUG
,forest[1] : logging.INFO
,forest[2] : logging.WARNING
,forest[3] : logging.ERROR }
log_name= []
for log in forest:
mounty = logging.FileHandler("%s%s.txt" % ("/home/smitty/mddl/",log))
log_name.append(log)
print "Instantiating %s" % ".".join(log_name)
timber = logging.getLogger(".".join(log_name))
#Comment out explit setting of level for logger
#timber.setLevel(lumber_jack[log])
#Commented out totally, called without argument, or called with
# logging.NOTSET all produce same output
#timber.setLevel(logging.NOTSET)
timber.addHandler(mounty)
if lumber_jack[log] == logging.DEBUG:
timber.debug( "%s's a lumberjack, and he's OK." % log)
elif lumber_jack[log] == logging.INFO:
timber.info( "%s's a lumberjack, and he's OK." % log)
elif lumber_jack[log] == logging.WARNING:
timber.warning("%s's a lumberjack, and he's OK." % log)
elif lumber_jack[log] == logging.ERROR:
timber.error( "%s's a lumberjack, and he's OK." % log)
mounty.emit( logging.LogRecord( timber
, 0
, "/mnt/dmz/proj/mddl4/mddl.py"
, 37
, "burp?"
, None
, None ))
#--end test script--
#---
#expected output
#---
$ cat root.txt
root's a lumberjack, and he's OK.
burp?
trunk's a lumberjack, and he's OK.
branch's a lumberjack, and he's OK.
leaf's a lumberjack, and he's OK.
$ cat trunk.txt
trunk's a lumberjack, and he's OK.
burp?
branch's a lumberjack, and he's OK.
leaf's a lumberjack, and he's OK.
$ cat branch.txt
branch's a lumberjack, and he's OK.
burp?
leaf's a lumberjack, and he's OK.
$ cat leaf.txt
leaf's a lumberjack, and he's OK.
burp?
#---
#actual output
#---
$ cat root.txt
burp?
branch's a lumberjack, and he's OK.
leaf's a lumberjack, and he's OK.
$ cat trunk.txt
burp?
branch's a lumberjack, and he's OK.
leaf's a lumberjack, and he's OK.
$ cat branch.txt
branch's a lumberjack, and he's OK.
burp?
leaf's a lumberjack, and he's OK.
$ cat leaf.txt
leaf's a lumberjack, and he's OK.
burp?
#---
At any rate, I see now that I want to use logging.setLevel() to lay
in my own, more descriptive, levels, and then the straight
logging.log() function to do that for me.
Ah, the learning curve.
Best,
Chris
--
http://mail.python.org/mailman/listinfo/python-list
Re: PYTHONDOCS
> "J" == J D Leach <[EMAIL PROTECTED]> writes: J> OK, I'm stupid. I have been unable to discern (even Googled) a J> way to set the PYTHONDOCS variable to point to where the HTML J> files are. What to do? I need to know the process and where J> theses variables are stored. -- J. D. Leach Columbus, Indiana J> USA J> Linux/Open Source Computer using: Mandrakelinux release 10.2 J> (Limited Edition 2005) for i586 kernel 2.6.11-6mdk J, I'm stupider; I can't ATFQ for you. But last night I stayed at a Holiday Inn Express, and can recommend http://projects.edgewall.com/python-sidebar/ Which, assuming you've got connectivity, is teh shiznit. HTH, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: logging module example
>>>>> "Diez" == Diez B Roggisch <[EMAIL PROTECTED]> writes: Diez> Chris Smith schrieb: >> Hola, pythonisas: The documentation for the logging module is >> good, but a bit obscure. In particular, there seems to be a >> lot of action at a distance. The fact that getLogger() can >> actually be a call to Logger.__init__(), which is mentioned in >> para 6.29.1, also bears stressing on 6.29. I grasp _why_ you'd >> implement it that way, but I may not be the only coder who >> feels queasy with the word 'get' being used both to fetch an >> instance and to trigger instantiation. Diez> The reason for this "distance" is simply that you should be Diez> able to get a grip on a logger from wherever you are, Diez> explicitly _without_ first having to instantiate it and Diez> possibly pass it around. Think of this little example: [snip] Diez> So the decoupling makes lots of sense in logging IMHO. Absolutely. The fact that it does eventually make sense, however, doesn't preclude a bout of confusion at the fact that some_lager didn't already exist before pint = logging.getLogger( some_lager ) and that the logging module will merrily brew some_lager on the spot. I submit that the documentation might be improved by including your example on 6.29, gearing the neophyte up for how this (can we agree it operates on slightly different principles than most?) module operates. >> Anyway, after poring over the documentation, unit test, and >> source code, I'd like to show a sample script that will >> eventually be used in my vanity project, with four loggers of >> increasing granularity. I realize there are probably more ways >> to do this (logging seemingly sporting perl-esque flexibility >> ;) so please weigh in with thoughts. Perhaps now I can go back >> and get this to work with the logging.config interface. :) [snip] Diez> That looks as an misunderstanding or somewhat strange usage Diez> of the logging-api. It is _very_ uncommon to have loggers Diez> level depending on _data_. Instead you just invoke Diez> logger.debug(some_data) Diez> and set the level elsewhere. That is a somewhat static Diez> releationship - all forests are supposed to share _one_ Diez> logging instance, with it's current log-level. And you don't Diez> check for the level being DEBUG or whatever. You just log, Diez> and if the level is above (or below, whatever stance you Diez> take) the currently set level for that logger, the message Diez> gets displayed. My use-case is a desire to interpret an input file, and log traces at varying output depth. I used the default labels, just to keep the sample script small. However, I will (once I have grokked that corner of the module more fully) follow your advice there, for I'm really only talking about four densities of debug information. Thank you for this feedback. Diez> All in all it seems that you have some difficulties with the Diez> loggers being a sort of global objects. Keep that in mind Diez> when developing using them. Yep, got to play the tune sloppy a few times before it's tight. Nochmals vielen Dank. :) Chris -- http://mail.python.org/mailman/listinfo/python-list
logging module example
Hola, pythonisas:
The documentation for the logging module is good, but a bit obscure.
In particular, there seems to be a lot of action at a distance.
The fact that getLogger() can actually be a call to Logger.__init__(),
which is mentioned in para 6.29.1, also bears stressing on 6.29. I
grasp _why_ you'd implement it that way, but I may not be the only
coder who feels queasy with the word 'get' being used both to fetch
an instance and to trigger instantiation.
Anyway, after poring over the documentation, unit test, and source code,
I'd like to show a sample script that will eventually be used
in my vanity project, with four loggers of increasing granularity.
I realize there are probably more ways to do this (logging seemingly
sporting perl-esque flexibility ;) so please weigh in with thoughts.
Perhaps now I can go back and get this to work with the
logging.config interface. :)
Best,
Chris
#begin log_test.py--
import logging
#Set up a hierarchy such that we have:
#root - everything, including function arguments
#`trunk - function calls
# `branch - application state
# `leaf - externally visible actions
forest = ["root","trunk","branch","leaf"]
#relate our logger names to levels
lumber_jack = {forest[0] : logging.DEBUG
,forest[1] : logging.INFO
,forest[2] : logging.WARNING
,forest[3] : logging.ERROR }
#Used to build up the log names into a hierarchy
log_name = []
for log in forest:
mounty = logging.FileHandler("%s%s.txt" % ("/home/smitty/mddl/",log))
log_name.append(log)
print "Instantiating %s" % ".".join(log_name)
timber = logging.getLogger(".".join(log_name))
timber.setLevel(lumber_jack[log])
timber.addHandler(mounty)
if lumber_jack[log] == logging.DEBUG:
timber.debug( "%s's a lumberjack, and he's OK." % log)
elif lumber_jack[log] == logging.INFO:
timber.info( "%s's a lumberjack, and he's OK." % log)
elif lumber_jack[log] == logging.WARNING:
timber.warning("%s's a lumberjack, and he's OK." % log)
elif lumber_jack[log] == logging.ERROR:
timber.error( "%s's a lumberjack, and he's OK." % log)
#Force a logging event from the handler for the current logger.
# This hanlder event short-circuits the up-stream propogation
# of the log record, as seen in the file outputs.
mounty.emit( logging.LogRecord( timber
, 0
, "/mnt/dmz/proj/mddl4/mddl.py"
, 37
, "burp?"
, None
, None ))
#end log_test.py--
#
#output:
#
Instantiating root
Instantiating root.trunk
Instantiating root.trunk.branch
Instantiating root.trunk.branch.leaf
#---
#The four files:
#---
$cat root.txt
root's a lumberjack, and he's OK.
burp?
trunk's a lumberjack, and he's OK.
branch's a lumberjack, and he's OK.
leaf's a lumberjack, and he's OK.
$cat trunk.txt
trunk's a lumberjack, and he's OK.
burp?
branch's a lumberjack, and he's OK.
leaf's a lumberjack, and he's OK.
$cat branch.txt
branch's a lumberjack, and he's OK.
burp?
leaf's a lumberjack, and he's OK.
$cat leaf.txt
leaf's a lumberjack, and he's OK.
burp?
--
http://mail.python.org/mailman/listinfo/python-list
Re: - E04 - Leadership! Google, Guido van Rossum, PSF
> "John" == John J Lee <[EMAIL PROTECTED]> writes: John> Guido may or may not realise it, but he seems to have been John> managing people (in some sense of 'managing', anyway) quite John> successfully over the past decade or so. John> John Just you shush! If he hears you, he'll return to being a newt! Chris -- http://mail.python.org/mailman/listinfo/python-list
python bug in this list implementation?
Hi,
I've been working on some multi-dimensional lists and I've encountered some
very strange behaviour in what appears to be simple code, I'm using python
2.4.2 and IDLE. If anyone can tell me why it's behaving so strange please
let me know, any improvements to my general coding style are also
appreciated.
code below:
import sys
import copy
grid = []
oGrid = []
sGrid = []
def createGrid():
f = open(r"...sudoku.txt", "rb") ## see attached for the file.
for line in f:
aLine = line.strip().split(',')
if aLine != [""]:
for i in xrange(len(aLine)):
aLine[i] = int(aLine[i])
grid.append(aLine)
oGrid = copy.deepcopy(grid)
sGrid.append(copy.deepcopy(grid))
def printGrid():
print "original grid:"
for line in oGrid:
print line#why doesn't this print anything?
print "S grid:"
for line in sGrid:
print line #this prints the grid but the formatting is all over the
place.
print "Iteration grid: "
for line in grid:
print line #works fine!
if __name__ == "__main__":
createGrid()
printGrid()
##PRODUCES THE FOLLOWING OUTPUT:
##
##original grid:
##S grid:
##[[0, 0, 0, 1, 5, 0, 0, 7, 0], [1, 0, 6, 0, 0, 0, 8, 2, 0], [3, 0, 0, 8, 6,
0, 0, 4, 0], [9, 0, 0, 4, 0, 0, 5, 6, 7], [0, 0, 4, 7, 0, 8, 3, 0, 0], [7,
3, 2, 0, 1, 6, 0, 0, 4], [0, 4, 0, 0, 8, 1, 0, 0, 9], [0, 1, 7, 0, 0, 0, 2,
0, 8], [0, 5, 0, 0, 3, 7, 0, 0, 0]]
##Iteration grid:
##[0, 0, 0, 1, 5, 0, 0, 7, 0]
##[1, 0, 6, 0, 0, 0, 8, 2, 0]
##[3, 0, 0, 8, 6, 0, 0, 4, 0]
##[9, 0, 0, 4, 0, 0, 5, 6, 7]
##[0, 0, 4, 7, 0, 8, 3, 0, 0]
##[7, 3, 2, 0, 1, 6, 0, 0, 4]
##[0, 4, 0, 0, 8, 1, 0, 0, 9]
##[0, 1, 7, 0, 0, 0, 2, 0, 8]
##[0, 5, 0, 0, 3, 7, 0, 0, 0]
begin 666 sudoku.txt
M,"PP+# L,2PU+# L,"PW+# -"C$L,"PV+# L,"[EMAIL PROTECTED],BPP#0HS+# L,"PX
M+#8L,"PP+#0L, T*#0HY+# L,"PT+# L,"PU+#8L-PT*,"[EMAIL PROTECTED]
M,RPP+# -"Chttp://mail.python.org/mailman/listinfo/python-list
Re: Why and how "there is only one way to do something"?
> "bonono" == bonono <[EMAIL PROTECTED]> writes: bonono> What I don't quite understand is, if it is "obvious", bonono> whether there is a Zen, people would still code it that bonono> way(unless of course they want to hide it from others or bonono> make it difficult to understand on purpose), there won't bonono> be any argument of "which one is the obvious way". And if bonono> there is an argument(or disagreement), which one is the bonono> obvious ? Python seems to strive for consistency in all levels. The 'obvious way' is the one with the greatest stylistic cohesion across the rest of the language. When you delve into a new realm, as I have lately been investigating the logging module, consistency helps lower the learning curve; we're re-cycling as much knowledge as possible. bonono> I think it is more like there is a preferred way, by the bonono> language creator and those share his view. You're right. There is no way to factor out the subjective nature of what becomes orthodoxy. Guido's taste, while perhaps imperfect, still stands out. Props. -Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: What do you use as symbols for Python ?
> "Gary" == Gary Herron <[EMAIL PROTECTED]> writes:
Gary> Erik Max Francis wrote:
>> Pierre Barbier de Reuille wrote: > > >
>>When you need some symbols in your program, what do you use in
>> Python ?
>>>
>>> For example, an object get a state. This state is more
>>> readable if expressed as a symbols, for example "opened",
>>> "closed", "error". Typically, in C or C++, I would use an
>>> enum for that: enum OBJECT_STATE { opened, closed, error
>>> }
>>>
>>>
>>
> OPENED, CLOSED, ERROR = range(3)
>>
>> object.state = OPENED
>>
>>
Gary> Another similar approach that keeps those values together in
Gary> a single namespace is this (my favorite):
Gary> class State: OPENED, CLOSED, ERROR = range(3)
Gary> Then you can refer to the values as State.OPENED
Gary> State.CLOSED State.ERROR
Gary> The extra clarity (and slight wordiness) of the dotted
Gary> notation seems, somehow, quite Pythonic to me.
Gary> Gary Herron
I think Zoran Isailovski has the last word on the topic:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/413486
--
http://mail.python.org/mailman/listinfo/python-list
Re: Needed class whose instances are many test cases
> "Sumit" == Sumit <[EMAIL PROTECTED]> writes: Sumit> I have scinario like I have to Create resource(in Sumit> __init__()) Before Running a set of testcases and then In Sumit> Testcases resources are going to used and then It will Sumit> cleared off after Running the testcases by destructor Sumit> __del__() import unittest import time Sumit> class app_adminfunc(unittest.TestCase): Sumit> def __init__(self, method = 'runTests'): Sumit> unittest.TestCase.__init__(self, method) Sumit> #Resource Creation Sumit> def __del__(self): #--Resource Sumit> Deletion - Sumit>def test01- def test02- ... Sumit> But in this above code Problem is that __init__() called at Sumit> each time when the Testcase is run ,But i want Single time Sumit> run of the Init Prior to run of each tests inside the class Sumit> . Can Anybody help me on this ? The unittest module runs a setUp and tearDown before each test case. If that is too high-frequency, why not just do something like class app_adminfunc(unittest.TestCase): def setUp(self): pass def tearDown(self): pass def allYourTestCase(self): def test01(): pass def test02(): pass since python is so mellow about nesting functions and classes and such. HTH, Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Generic utility class for passing data
> "Gordon" == Gordon Airporte <[EMAIL PROTECTED]> writes: Gordon> I'm wondering if this is might be bad practice. Sometimes Gordon> when I need to pass around several pieces of datum I will Gordon> put them in a tuple, then when I need to use them in a Gordon> receiving function I get them out with subscripts. The Gordon> problem is that the subscript number is completely Gordon> meaningless and I have to remember the order I used. As Gordon> an alternative I was considering using a dummy class like Gordon> this: Gordon> class Dummy: pass Gordon> Then when I need to pass some related data, Python lets me Gordon> do this: Gordon> prefill = Dummy() prefill.foreground = 'blue' Gordon> #"foreground" is made up on the fly prefill.background = Gordon> 'red' prefill.pattern = mypattern return prefill Gordon> Now I can access the data later using meaningful names. Gordon> Is this going to cause problems somehow? Should I rather Gordon> go to the trouble of creating more substantial individual Gordon> classes for every grouping of data I might need to pass Gordon> (with __init__'s and default values and so on)? Should I Gordon> just stick with subscripted groupings because of the Gordon> overhead? May fortune smile on Zoran Isailovski, whose Enum class is exactly what you want: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/413486 -Chris -- http://mail.python.org/mailman/listinfo/python-list
Re: Dealing with Excel
> "Robert" == Robert Hicks <[EMAIL PROTECTED]> writes: Robert> I need to pull data out of Oracle and stuff it into an Robert> Excel spreadsheet. What modules have you used to interface Robert> with Excel and would you recommend it? Robert> Robert For simple enough tasks, I think you can make SQL*plus output HTML, which Excel could suck up directly. For a sripted approach, I would recommend getting an ADODB.Connection object to your Oracle database , opening an ADODB.Recordset against the connection , setting an Excel.Range object to Cell A1 , enumerating your recodset field names into the cells of row 1 , setting the Exel.Range to Cell A2 , using the ridiculously fast CopyFromRecordset method of the Excel.Range to dump the recordset to the sheet. HTH, Chris -- http://mail.python.org/mailman/listinfo/python-list
