Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> > Now, I'm not fully up to speed on DBC. The contract specifications,
> > these are specified statically, but checked dynamically, is that
> > right?
>
> That's how it's done in Eiffel, yes.
>
>  > In other words, we can consider contracts in light of
> > inheritance, but the actual verification and checking happens
> > at runtime, yes?
>
> Sure. Though, while DbC gives rules for inheritance (actually subtypes),
> these are irrelevant to the current discussion; DbC-minus-subtyping can
> still be usefully applied.

Yes, subtyping. Of course I meant to say subtyping.

I can certainly see how DbC would be useful without subtyping.
But would there still be a reason to separate preconditions
from postconditions? I've never been clear on the point
of differentiating them (beyond the fact that one's covariant
and the other is contravariant.)


> > Wouldn't it be possible to do them at compile time? (Although
> > this raises decidability issues.)
>
> Exactly, and that's why you'd either uses a restricted assertion
> language (and essentially get something that's somewhere between a type
> system and traditional assertion); or you'd use some inference system
> and try to help it along (not a simple thing either - the components of
> such a system exist, but I'm not aware of any system that was designed
> for the average programmer).

As to the average programmer, I heard this recently on
comp.databases.theory:

"Don't blame me for the fact that competent programming, as I view it
as an intellectual possibility, will be too difficult for "the
average programmer"  -you must not fall into the trap of rejecting
a surgical technique because it is beyond the capabilities of the
barber in his shop around the corner."   -- EWD512


>  > Mightn't it also be possible to
> > leave it up to the programmer whether a given contract
> > was compile-time or runtime?
>
> I'd agree with that, but I'm not sure how well that would hold up in
> practice.

I want to try it and see what it's like.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Darren New schrieb:
> > As far as I understand it, Eiffel compilers don't even make use of
> > postconditions to optimize code or eliminate run-time checks (like null
> > pointer testing).
>
> That's correct.
>
> I think a large part of the reasons why this isn't done is that Eiffel's
> semantics is (a) too complicated (it's an imperative language after
> all), and (b) not formalized, which makes it difficult to assess what
> optimizations are safe and what aren't.

I can see the lack of a formal model being an issue, but is the
imperative bit really all that much of an obstacle? How hard
is it really to deal with assignment? Or does the issue have
more to do with pointers, aliasing, etc.?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
>
> > I can certainly see how DbC would be useful without subtyping.
> > But would there still be a reason to separate preconditions
> > from postconditions? I've never been clear on the point
> > of differentiating them (beyond the fact that one's covariant
> > and the other is contravariant.)
>
> There is indeed.
> The rules about covariance and contravariance are just consequences of
> the notion of having a subtype (albeit important ones when it comes to
> designing concrete interfaces).
>
> For example, if a precondition fails, something is wrong about the
> things that the subroutine assumes about its environment, so it
> shouldn't have been called. This means the error is in the caller, not
> in the subroutine that carries the precondition.
>
> The less important consequence is that this should be reflected in the
> error messages.
>
> The more important consequences apply when integrating software.
> If you have a well-tested library, it makes sense to switch off
> postcondition checking for the library routines, but not their
> precondition checking.
> This applies not just for run-time checking: Ideally, with compile-time
> inference, all postconditions can be inferred from the function's
> preconditions and their code. The results of that inference can easily
> be stored in the precompiled libraries.
> Preconditions, on the other hand, can only be verified by checking all
> places where the functions are called.

Interesting!

So, what exactly separates a precondition from a postcondition
from an invariant? I have always imagined that one writes
assertions on parameters and return values, and those
assertions that only reference parameters were preconditions
and those which also referenced return values were postconditions.
Wouldn't that be easy enough to determine automatically?

And what's an invariant anyway?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> > I can see the lack of a formal model being an issue, but is the
> > imperative bit really all that much of an obstacle? How hard
> > is it really to deal with assignment? Or does the issue have
> > more to do with pointers, aliasing, etc.?
>
> Actually aliasing is *the* hard issue.

Okay, sure. Nice explanation.

But one minor point: you describe this as an issue with "imperative"
languages. But aliasing is a problem associated with pointers,
not with assignment. One can have assignment, or other forms
of destructive update, without pointers; they are not part of the
definition of "imperative." (Likewise, one can have pointers without
assignment, although I'm less clear if the aliasing issue is as
severe.)


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> > Joachim Durchholz wrote:
> >> Marshall schrieb:
> >>> I can see the lack of a formal model being an issue, but is the
> >>> imperative bit really all that much of an obstacle? How hard
> >>> is it really to deal with assignment? Or does the issue have
> >>> more to do with pointers, aliasing, etc.?
> >> Actually aliasing is *the* hard issue.
> >
> > Okay, sure. Nice explanation.
> >
> > But one minor point: you describe this as an issue with "imperative"
> > languages. But aliasing is a problem associated with pointers,
> > not with assignment.
>
> Aliasing is not a problem if the aliased data is immutable.

Okay, sure. But for the problem you describe, both imperativeness
and the presence of pointers is each necessary but not sufficient;
it is the two together that causes the problem. So it strikes
me (again, a very minor point) as inaccurate to describe this as
a problem with imperative languages per se.


>  > One can have assignment, or other forms
> > of destructive update, without pointers; they are not part of the
> > definition of "imperative."
>
> Sure.
> You can have either of destructive updates and pointers without
> incurring aliasing problems. As soon as they are combined, there's trouble.

Right. To me the response to this clear: give up pointers. Imperative
operations are too useful to give up; indeed they are a requirement
for certain problems. Pointers on the other hand add nothing except
efficiency and a lot of confusion. They should be considered an
implementation technique only, hidden behind some pointerless
computational model.

I recognize that this is likely to be a controversial opinion.



> Functional programming languages often drop assignment entirely. (This
> is less inefficient than one would think. If everything is immutable,
> you can freely share data structures and avoid some copying, and you can
> share across abstraction barriers. In programs with mutable values,
> programmers are forced to choose the lesser evil of either copying
> entire data structures or doing a cross-abstraction analysis of who
> updates what elements of what data structure. A concrete example: the
> first thing that Windows does when accepting userland data structures
> is... to copy them; this were unnecessary if the structures were immutable.)

I heartily support immutability as the default, for these and other
reasons.


> Some functional languages restrict assignment so that there can exist at
> most a single reference to any mutable data structure. That way, there's
> still no aliasing problems, but you can still update in place where it's
> really, really necessary.

Are we speaking of uniqueness types now? I haven't read much about
them, but it certainly seems like an intriguing concept.


> I know of no professional language that doesn't have references of some
> kind.

Ah, well. I suppose I could mention prolog or mercury, but then
you used that troublesome word "professional." So I will instead
mention a language which, if one goes by number of search results
on hotjobs.com for "xxx progammer" for different value of xxx, is
more popular than Java and twice as popular as C++. It lacks
pointers (although I understand they are beginning to creep in
in the latest version of the standard.) It also posesses a quite
sophisticated set of facilities for declarative integrity constraints.
Yet for some reason it is typically ignored by language designers.

http://hotjobs.yahoo.com/jobseeker/jobsearch/search_results.html?keywords_all=sql+programmer


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

David Hopwood wrote:
> Marshall wrote:
>
> > Wouldn't it be possible to do them at compile time? (Although
> > this raises decidability issues.)
>
> It is certainly possible to prove statically that some assertions cannot fail.
>
> The ESC/Java 2 (http://secure.ucd.ie/products/opensource/ESCJava2/docs.html)
> tool for JML (http://www.cs.iastate.edu/~leavens/JML/) is one system that does
> this -- although some limitations and usability problems are described in
> <http://secure.ucd.ie/products/opensource/ESCJava2/ESCTools/papers/CASSIS2004.pdf>.

I look forward to reading this. I read a paper on JML a while ago and
found it quite interesting.


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


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Andreas Rossberg wrote:
> Marshall wrote:
> >
> > Okay, sure. But for the problem you describe, both imperativeness
> > and the presence of pointers is each necessary but not sufficient;
> > it is the two together that causes the problem. So it strikes
> > me (again, a very minor point) as inaccurate to describe this as
> > a problem with imperative languages per se.
> >
> > [...]
> >
> > Right. To me the response to this clear: give up pointers. Imperative
> > operations are too useful to give up; indeed they are a requirement
> > for certain problems. Pointers on the other hand add nothing except
> > efficiency and a lot of confusion. They should be considered an
> > implementation technique only, hidden behind some pointerless
> > computational model.
>
> Don't get yourself distracted by the low-level notion of "pointer". The
> problem *really* is mutability and the associated notion of identity,
> which explicit pointers just exhibit on a very low level.
>
> When you have a language with mutable types (e.g. mutable arrays) then
> objects of these types have identity, which is observable through
> assignment. This is regardless of whether identity is an explicit
> concept (like it becomes with pointers and comparison of pointer values,
> i.e. addresses).

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.) Sometimes I think
of this issue as being one with first class variables. An object
with mutable fields is a variable, and if we have pointers or
references or any way to have two different pathways to
that object/those variables, then we run in to the aliasing problem.

However if the mutable types are not first class, then there
is no way to have the aliasing. Thus, if we do not have pointers
or objects or identity but retain mutability, there is no aliasing
problem.


> Consequently, you cannot possibly get rid of aliasing issues without
> getting rid of (unrestricted) mutability. Mutability implies object
> identity implies aliasing problems.

Mutability by itself does not imply identity. I agree that mutability
plus
identity implies aliasing problems, however.


> On the other hand, pointers are totally a futile concept without
> mutability: if everything is immutable, it is useless to distinguish
> between an object and a pointer to it.

Agreed.


> In other words, pointers are essentially just an *aspect* of mutability
> in lower-level languages.

Again, I disagree: it is posible to have mutability without
pointers/identity/objects.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> > Joachim Durchholz wrote:
> >> Marshall schrieb:
> >>> Joachim Durchholz wrote:
> >>>> Marshall schrieb:
> >>>>> I can see the lack of a formal model being an issue, but is the
> >>>>> imperative bit really all that much of an obstacle? How hard
> >>>>> is it really to deal with assignment? Or does the issue have
> >>>>> more to do with pointers, aliasing, etc.?
> >>>> Actually aliasing is *the* hard issue.
> >>> Okay, sure. Nice explanation.
> >>>
> >>> But one minor point: you describe this as an issue with "imperative"
> >>> languages. But aliasing is a problem associated with pointers,
> >>> not with assignment.
> >> Aliasing is not a problem if the aliased data is immutable.
> >
> > Okay, sure. But for the problem you describe, both imperativeness
> > and the presence of pointers is each necessary but not sufficient;
> > it is the two together that causes the problem. So it strikes
> > me (again, a very minor point) as inaccurate to describe this as
> > a problem with imperative languages per se.
>
> Sure.
> It's just that I know that it's viable to give up destructive updates.
> Giving up pointers is a far more massive restriction.

Oddly, I feel the opposite. While it's true there are many domains
for which purely functional programming is a fine choice, there
are some domains for which it is insufficient. Any kind of data
managament, for example, requires that you be able to update
the information.

On the other hand, there is no problem domain for which pointers
are a requirement. I agree they are deucedly convenient, though.


> > Right. To me the response to this clear: give up pointers. Imperative
> > operations are too useful to give up; indeed they are a requirement
> > for certain problems.
>
> I don't know any.
> In some cases, you need an additional level of conceptual indirection -
> instead of *doing* the updates, you write a function that *describes* them.

But then what do you do with that function? Let's say I have an
employee database. John Smith just got hired on 1/1/2006 with
a salary of $10,000. I need to record this fact somewhere. How
do I do that without variables? Current-employees is a variable.
Even if I have the space to keep all historical data, so I'm not
deleting anything, I still have to have a variable for the latest
version of the accumulated data. I can solve this without
pointers, but I can't solve it without variables.


>  > Pointers on the other hand add nothing except
> > efficiency and a lot of confusion. They should be considered an
> > implementation technique only, hidden behind some pointerless
> > computational model.
> >
> > I recognize that this is likely to be a controversial opinion.
>
> Indeed.
>
> In fact "modes" are a way to restrict pointer aliasing.

I should like to learn more about these. I have some vague
perception of the existence of linear logic, but not much
else. However, I also already have an excellent solution
to the pointer aliasing problem, so I'm less motivated.


> > I heartily support immutability as the default, for these and other
> > reasons.
>
> OK, then we're in agreement here.
>
> >> Some functional languages restrict assignment so that there can exist at
> >> most a single reference to any mutable data structure. That way, there's
> >> still no aliasing problems, but you can still update in place where it's
> >> really, really necessary.
> >
> > Are we speaking of uniqueness types now? I haven't read much about
> > them, but it certainly seems like an intriguing concept.
>
> Yup.
> It's called "modes" in some other languages (Mercury or Clean IIRC).

Cool.


> >> I know of no professional language that doesn't have references of some
> >> kind.
> >
> > Ah, well. I suppose I could mention prolog or mercury, but then
> > you used that troublesome word "professional." So I will instead
> > mention a language which, if one goes by number of search results
> > on hotjobs.com for "xxx progammer" for different value of xxx, is
> > more popular than Java and twice as popular as C++. It lacks
> > pointers (although I understand they are beginning to creep in
> > in the latest version of the standard.) It also posesses a quite
> > sophisticated set of facilities for declarative integrity constraints.
> > Yet for some reason it is typically ignored by language designers.
> >
> >

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> > Mutability by itself does not imply identity.
>
> Well, the implication certainly holds from identity to mutability.
> The only definition of identity that I found to hold up for all kinds of
> references (pointers, shared-memory identifiers, URLs etc.) is this:
>
> Two pieces of data are identical if and only if:
> a) they are equal
> b) they stay equal after applying an arbitrary operation to one of them.
>
> This means that for immutable objects, there's no observable difference
> between equality and identity (which I think it just fine).

Agreed on all counts.


> For the implicaton from mutability to identity, I'm not sure whether
> talking about mutation still makes sense without some kind of identity.
> For example, you need to establish that the object after the mutation is
> still "the same" in some sense, and this "the same" concept is exactly
> identity.

Unless we have some specific mechanism to make two named variables
have the same identity, (distinct from having the same value), then
there
is no aliasing. Pointers or references is one such mechanism; lexical
closures over variables is another. (I don't know of any others.)


>  > I agree that mutability
> > plus identity implies aliasing problems, however.
>
> Then we're agreeing about the most important point anyway.

Yes.


> >> In other words, pointers are essentially just an *aspect* of mutability
> >> in lower-level languages.
> >
> > Again, I disagree: it is posible to have mutability without
> > pointers/identity/objects.
> 
> I'm sceptical.
> Any examples?

See next post.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joe Marshall wrote:
> Marshall wrote:
> >
> > Again, I disagree: it is posible to have mutability without
> > pointers/identity/objects.
>
> I think you are wrong, but before I make a complete ass out of myself,
> I have to ask what you mean by `mutability'.  (And
> pointers/identity/objects, for that matter.)

Responding to requests for examples from Joachim, Joe, and Chris

The very simple example is the one Darren New already mentioned.

Consider the following Java fragment:

void foo() {
  int i = 0;
  int j = 0;

  // put any code here you want

  j = 1;
  i = 2;
  // check value of j here. It is still 1, no matter what you filled in
above.
  // The assignment to i cannot be made to affect the value of j.

}


Those two local primitive variables cannot be made to have the same
identity. But you can update them, so this is an example of mutability
without the possibility of identity.

Earlier I also mentioned SQL tables as an example, although SQL
supports *explicit* aliasing via views.


> Alan Bawden discusses the phenomenon of `state' in his Ph.D.
> dissertation "Implementing Distributed Systems Using Linear Naming".
> MIT AI Lab Technical Report AITR-1627. March 1993  He makes a
> persuasive argument that `state' is associated with cycles in naming.

I would like to read that, but my brain generally runs out of gas at
about 21
pages, so it's about an order of magnitude bigger than I can currently
handle. :-( As to "cycles in naming" that's certainly an issue. But it
it
a requirement for state? Back to Java locals, it seems to me they meet
the standard definition of state, despite the lack of cycles.

As to pointers/references, I earlier mentioned the existence of the
reference/dereference operations as being definitional. Note that
one can go to some lengths to obscure them, but they're still there.
For example, Java has the reference and dereference operators;
Java's "." operator is actually C's "->" operator.

I am not so bold/foolish as to attempt a defintion of "object" however.
:-)


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joe Marshall wrote:
> Marshall wrote:
> >
> > Consider the following Java fragment:
> >
> > void foo() {
> >   int i = 0;
> >   int j = 0;
> >
> >   // put any code here you want
> >
> >   j = 1;
> >   i = 2;
> >   // check value of j here. It is still 1, no matter what you filled in
> > above.
> >   // The assignment to i cannot be made to affect the value of j.
> >
> > }
>
> True, but you have hidden the pointers.  Semantically, the identifiers
> i and j refer not to integers but to locations that hold integers.  The
> assignment modifies the location.

What the implementation looks like shouldn't affect how we speak
of the logical model. In the above code, there are no pointers.

By your definition, "pointer" and "variable" are synonyms. That doesn't
seem like a good idea to me. (What if i and j end up in registers?
I have not heard it said that registers have addresses.)


> > Those two local primitive variables cannot be made to have the same
> > identity. But you can update them, so this is an example of mutability
> > without the possibility of identity.
>
> The identity is temporal:  You use the same variable name at two
> different times.  Do you intend for the second `i' to mean the same
> variable as the first `i'?

Okay, so "i" and "i" have the same identity. I suppose you could argue
that the language's namespace is an address-space, and variable names
are addresses. At this point, though, you've made the concept of
identity
so broad that it is now necessarily a property of all languages that
use
named values, whether updatable or not. I think you would also have
to call "3" a void pointer by this scheme.

Clearly there is *some* difference between a language which allows
explicit pointers and thus aliasing and one that doesn't. What term
would you use? First-class variables?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

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


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Chris Smith wrote:
> 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.

I guess it is, now that you mention it.


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

Perhaps it is specifically first-class identity, rather than identity
per se.


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

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.

In our i-and-j example above, suppose there was a constraint
such that i < j. We have to re-check this constraint if we
update either i or j. That's not the same thing as saying
that i and j are aliased.

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. In general, any constraint on two
variables will have to be rechecked upon update
to either.


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

I don't see any aliasing in this example either.

But consider how much worse this problem is if real aliasing
is possible. We have some pointer variable, and initialize
it with the return value from some function. We don't know
anything about what variable is involved. We update through
the pointer. What constraints must we recheck? Apparently
all of them; unless we have perfect alias analysis, we can't
tell what variables are affected by our update.


> 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.)

I'm interested to hear your reply.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

George Neuner wrote:
> On 13 Jul 2006 08:45:49 -0700, "Marshall" <[EMAIL PROTECTED]>
> wrote:
> >
> >On the other hand, there is no problem domain for which pointers
> >are a requirement. I agree they are deucedly convenient, though.
> >
>
> I would argue that pointers/references _are_ a requirement for I/O.  I
> know of no workable method for interpreting raw bits as meaningful
> data other than to overlay a typed template upon them.

I think I know what you mean. I agree that pointers are necessary
for, e.g., device drivers. So I have to weaken my earlier statement.


> Categorically disallowing address manipulation functionally cripples
> the language because an important class of programs (system programs)
> cannot be written.

That's fair, although I could argue how important systems programming
is these days. (And C/C++ are cock-of-the-walk there anyway.)


> Of course, languages can go overboard the other way too.  IMO, C did
> not need to provide address arithmetic at the language level,
> reinterpretable references and array indexing would have sufficed for
> any use.  Modula 3's type safe view is an example of getting it right.
>
> It is quite reasonable to say "I don't write _ so I don't need
> [whatever language feature enables writing it]".  It is important,
> however, to be aware of the limitation and make your choice
> deliberately.

Agreed.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Chris Smith wrote:
> 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.

Yes, I think it's important. We've become so accustomed, in
modern languages, to considering variables as first-class,
that we cannot see any more that many of the problems
attributed to variables (such as aliasing) are actually
problems only with *first-class* variables. The historical
reality that non-first-class variables are associated with
more antique languages (Fortran/pre-OO) makes us shy
away from even considering removing first-class status
from variables. But I think it's an important point in the
design space (although I certainly respect Andreas'
reluctance; to paraphrase, "first class or bust." :-) )

After all, what are the alternatives? Purely-functional
languages remove themselves from a large class of
problems that I consider important: data management.
I have explored the OO path to its bitter end and am
convinced it is not the way. So what is left? Uniqueness
types and logic programming, I suppose. I enjoy logic
programming but it doesn't seem quite right. But notice:
no pointers there! And it doesn't seem to suffer from the
lack. I really don't know enough about uniqueness types
to evaluate them. But again, I already have my proposed
solution: variables but no first-class variables. (And yes,
I'm acutely aware of how problematic that makes
closures. :-()


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

I don't think that will work. We cannot discuss constraints, nor
aliasing, without bringing variables in to the picture. (Aliasing
may exist without variables but it is a non-problem then.)


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

I am not certain what this means.


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

But not all values in all structures, as you do in the presence
of aliasing.


> 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 that they're the same thing. Similar is some ways, yes,
but not the same.

As I said much earlier, the terminology is problematic, and it may
be that we (or just I) simply lack the precision of terms necessary
for the conversation.

 
Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> > What about my example of SQL? Mutation, no pointers, no aliasing.
> > Yet: useful.
>
> Sorry, but SQL does have aliasing.

Well. I suppose we do not have an agreed upon definition
of aliasing, so it is hard to evaluate either way. I would
propose using the same one you used for identity:

if there are two variables and modifying one also modifies
the other, then there is aliasing between them.

I avoided mentioning equality to include, for example,
having an array i that is an alias to a subset of array j.
Please feel free to critque this definition, and/or supply
an alternative.


> E.g. if you have records that have name="John", surname="Doe", the
> statements
>SELECT * FROM persons WHERE name = "John"
> and
>SELECT * FROM persons WHERE name = "Doe"
> are aliases of each other.
>
> The alias is actually in the WHERE clause.

Not by my definition, because there is only one variable here.


> And this *can* get you into
> trouble if you have something that does
>UPDATE ... WHERE name = "John"
> and
>UPDATE ... WHERE surname = "Doe"
> e.g. doing something with the Johns, then updating the names of all
> Does, and finally restoring the Johns (but not recognizing that changing
> the names of all Does might have changed your set of Johns).

The fact that some person might get confused about the
semantics of what they are doing does not indicate aliasing.
It is easy enough to do an analysis of your updates and
understand what will happen; this same analysis is impossible
with two arbitrary pointers, unless one has a whole-program
trace. That strikes me as a significant difference.


> Conceptually, this is just the same as having two different access path
> to the same memory cell. Or accessing the same global variable through a
> call-by-reference parameter and via its global name.

There are similarities, but they are not the same.


> BTW with views, you get not just aliasing but what makes aliasing really
> dangerous. Without views, you can simply survey all the queries that you
> are working with and lexically compare table and field names to see
> whether there's aliasing. With views, the names that you see in a
> lexical scope are not enough to determine aliasing.
> E.g. if you use a view that builds upon the set of Johns but aren't
> aware of that (possibly due to abstraction barriers), and you change the
> name field of all Does, then you're altering the view without a chance
> to locally catch the bug. That's just as bad as with any pointer
> aliasing problem.

It is certainly aliasing, but I would not call it "just as bad." There
are
elaborate declarative constraint mechanisms in place, for example.
And the definition of the view itsef is a declarative, semantic
entity. Whereas a pointer is an opaque, semantics-free address.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Andreas Rossberg wrote:
> Marshall wrote:
> >
> > After all, what are the alternatives? Purely-functional
> > languages remove themselves from a large class of
> > problems that I consider important: data management.
>
> Maybe, but I have yet to see how second-class variables are really more
> adequate in dealing with it.
>
> And note that even with second-class state you can still have aliasing
> issues - you just need mutable arrays and pass around indices. Keys in
> databases are a more general form of the same problem.

So for array a, you would claim that "a[5]" is an alias for
(a part of) "a"? That seems to stretch the idea of aliasing
to me. With these two expressions, it is obvious enough
what is going on; with two arbitrary pointers, it is not.

It seems to me the source of the problem is the opacity
of pointers, but perhaps I am missing something.


> > I have explored the OO path to its bitter end and am
> > convinced it is not the way. So what is left? Uniqueness
> > types and logic programming, I suppose. I enjoy logic
> > programming but it doesn't seem quite right. But notice:
> > no pointers there!  And it doesn't seem to suffer from the
> > lack.
>
> Uh, aliasing all over the place! Actually, I think that logic
> programming, usually based on deep unification, brings by far the worst
> incarnation of aliasing issues to the table.

Hmmm. Can you elaborate just a bit?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> > void foo() {
> >   int i = 0;
> >   int j = 0;
> >   j = 1;
> >   i = 2;
> >   // check value of j here. It is still 1, no matter what you filled
>  >   // in above.
> >   // The assignment to i cannot be made to affect the value of j.
> > }
> >
> > Those two local primitive variables cannot be made to have the same
> > identity.
>
> Sure. To state it more clearly, they cannot be aliases.

Yes.


>  > But you can update them, so this is an example of mutability
> > without the possibility of identity.
>
> You're being a bit sloppy with terminology here. "Identity" in the
> phrase above refers to two entities, in the sense of "i and j cannot be
> identical".
> Identity is actually a property of a single entity, namely that what
> remains constant regardless of what you do with the entity.

It is a fair critque. I'll try to be more precise.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
>
> You can have aliasing without pointers; e.g. arrays are fully sufficient.
> If i = j, then a [i] and a [j] are aliases of the same object.

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.

A further question:

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 am not being facetious; I am trying to understand the limits
of your definition for aliasing.


> (After I observed that, I found it no longer a surprise that array
> optimizations are what Fortran compiler teams sink most time into. The
> aliasing problems are *exactly* the same as those with pointers in C -
> though in practice, the Fortranistas have the advantage that the
> compiler will usually know that a [i] and b [j] cannot be aliases of
> each other, so while they have the same problems, the solutions give the
> Fortranistas more leverage.)

I don't understand this paragraph. On the one hand, it seems you
are saying that C and Fortran are identically burdened with the
troubles caused by aliasing, and then a moment later it seems
you are saying the situation is distinctly better with Fortran.


>  > What term would you use? First-class variables?
>
> I think it's more a quasi-continuous spectrum.
>
> On one side, we have alias-free toy languages (no arrays, no pointers,
> no call-by-reference, just to name the most common sources of aliasing).
>
> SQL is slightly more dangerous: it does have aliases, but they are
> rarely a problem (mostly because views aren't a very common thing, and
> even if they are used, they aren't usually so abstract that they really
> hide the underlying dependencies).
>
> Next are languages with arrays and call-by-reference. "Pascal without
> pointers" would be a candidate.
> Here, aliasing occurs, and it can and does hide behind abstraction
> barriers, but it's not a serious problem unless the software becomes
> *really* large.
>
> The end of the line are languages that use references to mutable data
> everywhere. All OO languages are a typical example of that.

Now with this, it appears you are agreeing that SQL has an advantage
vis-a-vis aliasing compared to OO languages. Yes? If so, we are
agreeing on the part I care about, and the specifics of just what
we call aliasing are not so important to me.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
>
> >> In some cases, you need an additional level of conceptual indirection -
> >> instead of *doing* the updates, you write a function that *describes* them.
> >
> > But then what do you do with that function?
>
> I pass it to an engine that's imperative.
>
> However, that engine doesn't need to do aliasing anymore.
>
> In other words, I'm separating mutability and aliasing, so that they
> can't combine and explode.

This would seem to be identical to what I am proposing.


>  > Let's say I have an
> > employee database. John Smith just got hired on 1/1/2006 with
> > a salary of $10,000. I need to record this fact somewhere. How
> > do I do that without variables? Current-employees is a variable.
> > Even if I have the space to keep all historical data, so I'm not
> > deleting anything, I still have to have a variable for the latest
> > version of the accumulated data. I can solve this without
> > pointers, but I can't solve it without variables.
>
> As I said elsewhere, the record has an identity even though it isn't
> explicit in SQL.

H. What can this mean?

In general, I feel that "records" are not the right conceptual
level to think about.

In any event, I am not sure what you mean by non-explicit
identity. I would say, records in SQL have value, and their
identity is exactly their value. I do not see that they have
any identity outside of their value. We can uniquely identify
any particular record via a key, but a table may have more
than one key, and an update may change the values of one
key but not another. So it is not possible in general to
definitely and uniquely assign a mapping from each record
of a table after an update to each record of the table before
the update, and if you can't do that, then where
is the record identity?

(The situation is even more dire when one considers that
SQL actually uses bag semantics and not set semantics.)


[...]

> > I should like to learn more about these. I have some vague
> > perception of the existence of linear logic, but not much
> > else. However, I also already have an excellent solution
> > to the pointer aliasing problem, so I'm less motivated.
>
> Pointers are just the most obvious form of aliasing. As I said
> elsewhere, there are others: array indexing, by-reference parameters, or
> even WHERE clauses in SQL statements. In fact, anything that selects an
> updatable piece of data from a collection is an alias, and incurs the
> same problems as pointers, though they may come in different disguises.

Okay. At this point, though, the term aliasing has become extremely
general. I believe "i+1+1" is an alias for "i+2" under this definition.
That is so general that I am concerned it has lost its ability to
identify problems specific to pointers.


> >> Actually SQL has references - they are called "primary keys", but they
> >> are references nevertheless.
> >
> > I strongly object; this is quite incorrect. I grant you that from the
> > 50,000 foot level they appear identical, but they are not. To
> > qualify as a reference, there need to be reference and dereference
> > operations on the reference datatype; there is no such operation
> > is SQL.
> >
> > Would you say the relational algebra has references?
>
> Yes.
>
> > Or, consider the classic prolog ancestor query. Let's say we're
> > setting up as follows
> >
> > father(bob, joe).
> > father(joe, john).
> >
> > Is "joe" a reference, here? After all, when we do the ancestor
> > query for john, we'll see his father is joe and then use that to
> > find joe's father. Keys in SQL are isomorphic to joe in the
> > above prolog.
>
> Agreed. They are both references ;-P

Again, by generalizing the term this far, I am concerned with a
loss of precision. If "joe" in the prolog is a references, then
"reference" is just a term for "data" that is being used in a
certain way. The conection with a specfic address space
has been lost in favor of the full domain of the datatype.


> >> (Some SQL dialects also offer synthetic
> >> "ID" fields that are guaranteed to remain stable over the lifetime of a
> >> record.
> >
> > Primary keys are updatable; there is nothing special about them.
>
> Right - I was wrong with identifying keys and identities. In fact the
> identity of an SQL record cannot be directly obtained (unless via those
> ID fields).
> The records still have identities. It's possible to have two WHERE
> clauses that refer to the same record, and i

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> > Joachim Durchholz wrote:
> >> As I said elsewhere, the record has an identity even though it isn't
> >> explicit in SQL.
> >
> > H. What can this mean?
> >
> > In general, I feel that "records" are not the right conceptual
> > level to think about.
>
> They are, when it comes to aliasing of mutable data. I think it's
> justified by the fact that aliased mutable data has a galling tendency
> to break abstraction barriers. (More on this on request.)

I can see how pointers, or other kinds of aliasing
(by my more restricted definition) break abstraction barries;
it is hard to abstract something that can change out from
under you uncontrollably.


> > In any event, I am not sure what you mean by non-explicit
> > identity.
>
> The identity isn't visible from inside SQL. (Unless there's an OID
> facility available, which *is* an explicit identity.)

Agreed about OIDs.


>  > I would say, records in SQL have value, and their
> > identity is exactly their value.
>
> Definitely not. You can have two equal records and update just one of
> them, yielding non-equal records; by my definition (and by intuition),
> this means that the records were equal but not identical.

This sort of thing comes up when one has made the mistake of
not defining any keys on one's table and needs to rectify the
situation. It is in fact considered quite a challenge to do.
My preferred technique for such a situation is to create
a new table with the same columns and SELECT DISTINCT ...
INTO ... then recreate the original table. So that way doesn't
fit your model.

How else might you do it? I suppose there are nonstandard
extensions, such as UPDATE ... LIMIT. And in fact there
might be some yucky thing that made it in to the standard
that will work.

But what you descrbe is certainly *not* possible in the
relational algebra; alas that SQL doesn't hew closer
to it. Would you agree? Would you also agree that
if a language *did* adhere to relation semantics,
then relation elements would *not* have identity?
(Under such a language, one could not have two
equal records, for example.)

[The above paragraph is the part of this post that I
really care about; feel free to ignore the rest if it's naive
or annoying or whatever, but please do respond to this.]


>  > I do not see that they have
> > any identity outside of their value. We can uniquely identify
> > any particular record via a key, but a table may have more
> > than one key, and an update may change the values of one
> > key but not another. So it is not possible in general to
> > definitely and uniquely assign a mapping from each record
> > of a table after an update to each record of the table before
> > the update, and if you can't do that, then where
> > is the record identity?
>
> Such a mapping is indeed possible. Simply extend the table with a new
> column, number the columns consecutively, and identify the records via
> that column.

That doesn't work for me. It is one thing to say that for all
tables T, for all elements e in T, e has identity. It is a different
thing to say that for all tables T, there exists a table T' such
that for all elements e in T', e has identity.


> But even if you don't do that, there's still identity. It is irrelevant
> whether the programs can directly read the value of the identity field;
> the adverse effects happen because updates are in-place. (If every
> update generated a new record, then we'd indeed have no identity.)
>
> > Okay. At this point, though, the term aliasing has become extremely
> > general. I believe "i+1+1" is an alias for "i+2" under this definition.
>
> No, "i+1+1" isn't an alias in itself. It's an expression - to be an
> alias, it would have to be a reference to something.
>
> However, a[i+1+1] is an alias to a[i+2]. Not that this is particularly
> important - 1+1 is replacable by 2 in every context, so this is
> essentially the same as saying "a[i+2] is an alias of a[i+2]", which is
> vacuously true.

To me, the SQL with the where clause is like i+2, not like a[2].
A query is simply an expression that makes mention of a variable.
However I would have to admit that if SQL table elements have
identity, it would be more like the array example.

(The model of SQL I use in my head is one with set semantics,
and I am careful to avoid running in to bag semantics by, for
example, always defining at least one key, and using SELECT
DISTINCT where necessary. But it is true that the strict set
semantics in my head are not the wobbly bag semantics in
the standard.)


> There's another aspect here. If two expressions are

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
>
> > But what you descrbe is certainly *not* possible in the
> > relational algebra; alas that SQL doesn't hew closer
> > to it. Would you agree?
>
> Yup, SQL (particularly its update semantics) aren't relational semantics.
> Still, it's SQL we've been talking about.
>
>  > Would you also agree that
> > if a language *did* adhere to relation semantics,
> > then relation elements would *not* have identity?
> > (Under such a language, one could not have two
> > equal records, for example.)
>
> Any identity that one could define within relational semantics would be
> just equality, so no, it wouldn't be very helpful (unless as part of a
> greater framework).
> However, that's not really a surprise. Aliasing becomes relevant (even
> observable) only when there's updates, and relational algebra doesn't
> have updates.

Good point. Perhaps I should have said "relational algebra +
variables with assignment." It is interesting to consider
assignment vs. the more restricted update operators: insert,
update, delete. I think I see what you mean about the restricted
update operators working on identity.


> >>> Okay. At this point, though, the term aliasing has become extremely
> >>> general. I believe "i+1+1" is an alias for "i+2" under this definition.
> >> No, "i+1+1" isn't an alias in itself. It's an expression - to be an
> >> alias, it would have to be a reference to something.
> >>
> >> However, a[i+1+1] is an alias to a[i+2]. Not that this is particularly
> >> important - 1+1 is replacable by 2 in every context, so this is
> >> essentially the same as saying "a[i+2] is an alias of a[i+2]", which is
> >> vacuously true.
> >
> > To me, the SQL with the where clause is like i+2, not like a[2].
>
> I'd say WHERE is like [i+2]: neither is valid on its own, it's the
> "selector" part of a reference into a table.

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?)


> > However the situation in SQL strikes me as being different.
> > If one is speaking of base tables, and one has two queries,
> > one has everything one needs to know simply looking at
> > the queries. If views are involved, one must further examine
> > the definition of the view.
>
> Sure. Usually, SQL itself is enough abstract that no additional
> abstraction happens; so even if you have aliasing, you usually know
> about it.
> I.e. when compared to what you were saying about Java: "It is possible
> to have multiple references to a single Java mutable object and
> not know it.", the "and not know it" part is usually missing.

Yes!


> The picture changes as soon as the SQL statements get hidden behind
> layers of abstraction, say result sets and prepared query handles.
>
> ... Um... let me also restate the preconditions for aliasing become a
> problem. You need three elements for that:
> 1) Identities that can be stored in multiple places.
> 2) Updates.
> 3) Abstraction (of updatable entities).
>
> Without identities, there cannot be aliasing.
> Without updates, the operation that makes aliasing problematic is excluded.
> Without abstraction, you may have aliasing but can clearly identify it,
> and don't have a problem.

Aha! That description works very well for me.


> I admit that identity cannot be reliably established in SQL. The
> identity of a record isn't available (unless via OID extensions).
> However, it is there and it can have effect.

Yes, I think I see what you mean now. This is in part a consequence
of the restricted update operators.

Thanks,

Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Chris F Clark wrote:
> "Marshall" <[EMAIL PROTECTED]> wrote:
> > In general, I feel that "records" are not the right conceptual
> > level to think about.
>
> 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"?



> > I do not see that they have
> > any identity outside of their value. We can uniquely identify
> > any particular record via a key, but a table may have more
> > than one key, and an update may change the values of one
> > key but not another. So it is not possible in general to
> > definitely and uniquely assign a mapping from each record
> > of a table after an update to each record of the table before
> > the update, and if you can't do that, then where
> > is the record identity?
>
> I don't know if your point of having two keys within one table amkes a
> difference.  If one can uniquely identify a record, then it has
> identity.  The fact that there is another mapping where one may not be
> able to uniquely identify the record is not necessarily relevant.

The issue with two keys is that the keys may not *agree* on the
mapping before vs. after the update.


> > For example, we might ask in C, if we update a[i], will
> > the value of b[j] change? And we can't say, because
> > we don't know if there is aliasing. But in Fortran, we
> > can say that it won't, because they are definitely
> > different variables.
>
> Unfortunately, your statement about FORTRAN is not true, if a and b
> are parameters to a subroutine (or members of a common block, or
> equivalenced, or ...), then an update of a[i] might change b[j].

Ah, common blocks. How that takes me back!

But your point is a good one; I oversimplified.


> Marshall again:
> > Fair enough. I could only remember three, but I was sure someone
> > else could name more. :-)
>
> There actual are some more, but very rare, for example there was call-
> by-text-string, which is sort of like call-by-name, but allows a
> parameter to reach into the calling routine and mess with local
> variables therein.  Most of the rare ones have really terrible
> semantics, and are perhaps best forgotten except to keep future
> implementors from choosing them.  For example, call-by-text-string is
> really easy to implement in a naive interpreter that reparses each
> statement at every invocation, but but it exposes the implementation
> properties so blatantly that writing a different interpretor is nearly
> impossible.
>
> If I recall correctly, there are also some call-by- methods that take
> into account networks and addressing space issues--call-by-reference
> doesn't work if one cannot see the thing being referenced.  Of coruse,
> one must then ask whether one considers "remote-procedure-call" and/or
> message-passing to be the same thing as a local call.
>
> One last nit, Call-by-value is actually call-by-copy-in-copy-out when
> generalized.
>
> There are some principles that one can use to organize the parameter
> passing methods.  However, the space is much richer than people
> commonly know about (and that is actually a good thing, that most
> people aren't aware of the richness, simplicity is good).


Fair enough.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> >
> > Good point. Perhaps I should have said "relational algebra +
> > variables with assignment." It is interesting to consider
> > assignment vs. the more restricted update operators: insert,
> > update, delete.
>
> Actually I see it the other way round: assignment is strictly less
> powerful than DML since it doesn't allow creating or destroying
> variables, while UPDATE does cover assignment to fields.

Oh, my.

Well, for all table variables T, there exists some pair of
values v and v', such that we can transition the value of
T from v to v' via assignment, but not by any single
insert, update or delete. The reverse is not true. I
would consider that a solid demonstration of which
one is more powerful. Further, it is my understanding
that your claim of row identity *depends* on the restricted
nature of DML; if the only mutator operation is assignment,
then there is definitely no record identity.


> (However, it's usually new+assignment+delete vs. INSERT+UPDATE+DELETE,
> at which point there is not much of a difference.)

I am not sure what this means. Delete can be expressed in
terms of assignment. (As can insert and update.) (Assignment
can also be expressed in terms of insert and delete.) I
don't know what "new" would be in a value-semantics, relational
world. So I would say it's assignment vs. INSERT+UPDATE+DELETE,
but perhaps I'm not understanding what you mean.

Assignment by itself is complete. Insert and delete together
are complete.


> >>>>> Okay. At this point, though, the term aliasing has become extremely
> >>>>> general. I believe "i+1+1" is an alias for "i+2" under this definition.
> >>>> No, "i+1+1" isn't an alias in itself. It's an expression - to be an
> >>>> alias, it would have to be a reference to something.
> >>>>
> >>>> However, a[i+1+1] is an alias to a[i+2]. Not that this is particularly
> >>>> important - 1+1 is replacable by 2 in every context, so this is
> >>>> essentially the same as saying "a[i+2] is an alias of a[i+2]", which is
> >>>> vacuously true.
>  >>>
> >>> To me, the SQL with the where clause is like i+2, not like a[2].
> >> I'd say WHERE is like [i+2]: neither is valid on its own, it's the
> >> "selector" part of a reference into a table.
> >
> > Is it possible you're being distracted by the syntax?
>
> I think that's very, very unlikely ;-)

Well, I just thought I'd ask. :-)


>  > 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?
>
> Yes.
>
> Filters are just like array indexing: both select a subset of variables
> from a collection.

I can't agree with this wording. A filter produces a collection
value from a collection value. I don't see how variables
enter in to it. One can filter either a collection constant or
a collection variable; if one speaks of filtering a collection
variable, on is really speaking of filtering the collection value
that the variable currently contains; filtering is not an operation
on the variable as such, the way the "address of" operator is.
Note you can't update the result of a filter.


> In SQL, you select a subset of a table, in a
> programming language, you select a subset of an array.
>
> (The SQL selection mechanism is far more flexible in the kinds of
> filtering you can apply, while array indexing allows filtering just by
> ordinal position. However, the relevant point is that both select things
> that can be updated.)

When you have been saying "select things that can be updated"
I have been assuming you meant that one can derive values
from variables, and that some other operation can update that
variable, causing the expression, if re-evaluated, to produce
a different value. However the phrase also suggests that
you mean that the *result* of the select can *itself* be
updated. Which one do you mean? (Or is there a third
possibility?)


> >> I admit that identity cannot be reliably established in SQL. The
> >> identity of a record isn't available (unless via OID extensions).
> >> However, it is there and it can have effect.
> >
> > Yes, I think I see what you mean now. This is in part a consequence
> > of the restricted update operators.
>
> I don't think so. You can update SQL records any way you want.
> The unavailability of a record identity is due to the fact that, well,
> it's unavailable in standard SQL.

I disagree. The concept of record-identity is quite tenuous, and
depends on specifics of SQL semantics. (In fact I'm not entirely
convinced it's definitely there even in SQL.) It certainly does not
hold in, say, set theory. Set elements do not have identity; they
only have value. If we have a set-semantics language that
supports set variables with assignment, we still do not have
element-identity.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Chris Smith wrote:
> 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.

Exactly.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> > Joachim Durchholz wrote:
> >> Marshall schrieb:
> >>> Good point. Perhaps I should have said "relational algebra +
> >>> variables with assignment." It is interesting to consider
> >>> assignment vs. the more restricted update operators: insert,
> >>> update, delete.
> >> Actually I see it the other way round: assignment is strictly less
> >> powerful than DML since it doesn't allow creating or destroying
> >> variables, while UPDATE does cover assignment to fields.
> >
> > Oh, my.
> >
> > Well, for all table variables T, there exists some pair of
> > values v and v', such that we can transition the value of
> > T from v to v' via assignment, but not by any single
> > insert, update or delete.
>
> I fail to see an example that would support such a claim.

variable T : unary relation of int
T = { 1, 2, 3 };  // initialization
T := { 4, 5 };   // assignment

The above transition of the value of T cannot be be
done by any one single insert, update or delete.
Two would suffice, however. (In fact, any assignement
can be modeled at a full delete followed by an insert
of the new value.)


> On the other hand, UPDATE can assign any value to any field of any
> record,

Yes.

> so it's doing exactly what an assignment does.

No. The variable is the table, not the records. Relations are not
arrays.
Records are not lvalues.


> INSERT/DELETE can
> create resp. destroy records, which is what new and delete operators
> would do.
>
> I must really be missing the point.
>
>  > Further, it is my understanding
> > that your claim of row identity *depends* on the restricted
> > nature of DML; if the only mutator operation is assignment,
> > then there is definitely no record identity.
>
> Again, I fail to connect.
>
> I and others have given aliasing examples that use just SELECT and UPDATE.

Sure, but update's semantics are defined in a per-record way,
which is consistent with record identity. Assignment's isn't.


> >> (However, it's usually new+assignment+delete vs. INSERT+UPDATE+DELETE,
> >> at which point there is not much of a difference.)
> >
> > I am not sure what this means. Delete can be expressed in
> > terms of assignment. (As can insert and update.)
>
> INSERT cannot be expressed in terms of assignment. INSERT creates a new
> record; there's no way that assignment in a language like C can create a
> new data structure!
> The same goes for DELETE.

I was intendind to be discussing a hypothetical relation-based
language,
so while I generally agree with you statement about C, I don't see
how it applies.


>  > (Assignment can also be expressed in terms of insert and delete.)
>
> Agreed.
>
> I also realize that this makes it a bit more difficult to nail down the
> nature of identity in a database.

I would propose that variables have identity, and values do not.
In part this is via the supplied definition of identity, in which, when
you change one thing, if something else changes as well, they
share identity. Since one cannot change values, they necessarily
lack identity.


> It's certainly not storage location:
> if you DELETE a record and then INSERT it with the same values, it may
> be allocated somewhere entirely else, and our intuition would say it's
> not "the same" (i.e. not identical).

Well, it would depend on how our intuition had been primed. If it
was via implementation techniques in low level languages, we
might reach a different conclusion than if our intuition was primed
via logical models and relation theory.


> (In a system with OID, it would
> even be impossible to recreate such a record, since it would have a
> different OID. I'm not sure whether this makes OID systems better or
> worse at preserving identity, but that's just a side track.)

OIDs are something of a kludge, and they break set semantics.


> Since intuition gives me ambivalent results here, I'll go back to my
> semiformal definition (and take the opportunity to make it a bit more
> precise):
> Two path expressions (lvalues, ...) are aliases if and only if the
> referred-to values compare equal, and if they stay equal after applying
> any operation to the referred-to value through either of the path
> expressions.

Alas, this leaves me confused. I don't see how a path expression
(in this case, SELECT ... WHERE) can be an l-value. You cannot
apply imperative operations to the result. (Also I think the use
of equality here is too narrow; it is only necessary to show that
two things both change, not that they change in the same way.)

I was under the impression you agre

Re: What is a type error?

[Marshall]

Chris Smith wrote:
> Marshall <[EMAIL PROTECTED]> wrote:
> > We seem to have slipped back from the hypothetical relation language
> > with only assignement back to SQL.
>
> [...]
> I don't see how such a language (limited to assignment of entire
> relations) is particularly helpful to consider.

I find it useful to consider various language features together and
individually, to see how these features interact. If nothing else,
it furthers my understanding of how languages work.


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


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

No, such a language is entirely useful, since relational assignment
is *more* expressive than insert/update/delete. (How did you get "no
scope"
by the way? And fixed variables? All I said was to change ins/upd/del
to
assignment.)

Also note one could fairly easily write a macro for ins/upd/del if one
had assignement. (See below.)

Now, there are some significant issues with trying to produce a
performant implementation in a distributed environment with strictness.
In fact I will go so far as to say it's impossible. However on a single
machine I don't see any reason to think it would perform any worse,
(although I haven't thought about it deeply.)


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

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.

Given:
variable T : relation of r;
update_fn : r -> r   // takes one record and returns new, updated
record
filter_fn : r -> boolean  // indicator function

insert(T, new_rows) => { T := T union new_rows; }

update(T, update_fn, filter_fn) => {
  transaction {
let Tmp = filter(T, filter_fn);  // select only those rows to
update
T := T minus Tmp;
T := T union update_fn(Tmp);
  }
}

delete(T,filter_fn) => { T := T minus filter(T, filter_fn); }

So we can define insert, update and delete in terms of relational
assignment, relational subtraction, and relational union. Type
checking details omitted.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Chris Smith wrote:
> 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.

At the implementation level, it makes some things harder, however
as a logical model, it is more powerful. While this is very much a real
world issue, it is worth noting that it is a performance issue *merely*
and not a semantic issue.


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

I was under the impression tat Joachim, for example, did not
consider "i+1" as an alias for i.


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

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.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> > Chris Smith wrote:
> >> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
> >> 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.
> >
> > Exactly.
>
> Ah well. I never meant that kind of assignment.

Sorry for the confusion.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Change on file

[Marshall]

You could use ctime to see it by the time.

MD5 it's a most secure way to a file that CAN'T be modified. If you
just want to see if the file has been modified (like to make a cache),
use ctime.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Chris Smith wrote:
>
> 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.

While I am quite sympathetic to this point, I have to say that
this horse left the barn quite some time ago.


Marshall

PS. Hi Chris!

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Chris Smith wrote:
> 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.

That's fair.

One thing that is frustrating to me is that I really want to build
an understanding of what dynamic typing is and what its
advantages are, but it's difficult to have a productive discussion
on the static vs. dynamic topic. Late binding of every function
invocation: how does that work, what are the implications of that,
what does that buy you?

I have come to believe that the two actually represent
very different ways of thinking about programming. Which
goes a long way to explaining why there are such difficulties
communicating. Each side tries to describe to the other how
the tools and systems they use facilitate doing tasks that
don't exist in the other side's mental model.


> > PS. Hi Chris!
>
> Hi!  Where are you posting from these days?

I'm mostly on comp.databases.theory, but I also lurk
on comp.lang.functional, which is an awesome group, and
if you're reading Pierce then you might like it too.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Joe Marshall wrote:
>
> They *do* have a related meaning.  Consider this code fragment:
> (car "a string")
> [...]
> Both `static typing' and `dynamic typing' (in the colloquial sense) are
> strategies to detect this sort of error.

The thing is though, that putting it that way makes it seems as
if the two approaches are doing the same exact thing, but
just at different times: runtime vs. compile time. But they're
not the same thing. Passing the static check at compile
time is universally quantifying the absence of the class
of error; passing the dynamic check at runtime is existentially
quantifying the absence of the error. A further difference is
the fact that in the dynamically typed language, the error is
found during the evaluation of the expression; in a statically
typed language, errors are found without attempting to evaluate
the expression.

I find everything about the differences between static and
dynamic to be frustratingly complex and subtle.

(To be clear, I do know that Joe understands these issues
quite well.)

So I kind of agree with Chris, insofar as I think the terminology
plays a role in obscuring rather than illuminating the differences.

On the other hand I agree with Joe in that:

> I mean that this has been argued time and time again in comp.lang.lisp
> and probably the other groups as well.  You may not like the fact that
> we say that Lisp is dynamically typed, but *we* are not confused by
> this usage.  In fact, we become rather confused when you say `a
> correctly typed program cannot go wrong at runtime' because we've seen
> plenty of runtime errors from code that is `correctly typed'.

Yes; as I said ealier, the horse has left the barn on this one.

The conversation I would *really* like to have is the one where we
discuss what all the differences are, functionally, between the two,
and what the implications of those differences are, without trying
to address which approach is "right" or "better", because those are
dependent on the problem domain anyway, and because I can
make up my own mind just fine about which one I prefer.

The comp.lang.functional and comp.lang.lisp people are probably
two of the smartest groups on usenet. (I do not consider myself
a member of either group.) You wouldn't *think* that conversation
would be *so* hard to have.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Chris Smith wrote:
>
>  When I used the word "type" above, I was adopting the
> working definition of a type from the dynamic sense.  That is, I'm
> considering whether statically typed languages may be considered to also
> have dynamic types, and it's pretty clear to me that they do.

I suppose this statement has to be evaluated on the basis of a
definition of "dynamic types." I don't have a firm definition for
that term, but my working model is runtime type tags. In which
case, I would say that among statically typed languages,
Java does have dynamic types, but C does not. C++ is
somewhere in the middle.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Joachim Durchholz wrote:
>
> Hmm... I think this distinction doesn't cover all cases.
>
> 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).
> The compiler might actually refuse to compile type-incorrect programs,
> depending on compiler flags and/or declarations in the code.
>
> Typed ("strongly typed") it is, but is it statically typed or
> dynamically typed?

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. Maybe
we have reached the point where trying to cram everything
in two one of two possible ways of doing things isn't going
to cut it any more.

Could it be that the US two-party system has influenced our
thinking?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Joachim Durchholz wrote:
>
> On a semantic level, the tag is always there - it's the type (and
> definitely part of an axiomatic definition of the language).
> Tag elimination is "just" an optimization.

I see what you're saying, but the distinction is a bit fine for me.
If the language has no possible mechanism to observe the
it-was-only-eliminated-as-an-optimization tag, in what sense
is it "always there?" E.g. The 'C' programming language.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

David Hopwood wrote:
>
> Oh, but it *does* make sense to talk about dynamic tagging in a statically
> typed language.
>
> That's part of what makes the term "dynamically typed" harmful: it implies
> a dichotomy between "dynamically typed" and "statically typed" languages,
> when in fact dynamic tagging and static typing are (mostly) independent
> features.

That's really coming home to me in this thread: the terminology is *so*
bad. I have noticed this previously in the differences between
structural
and nominal typing; many typing issues associated with this distinction
are falsely labeled as a static-vs-dynamic issues, since so many
statically
type languages are nominally typed.

We need entirely new, finer grained terminology.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Nice post! One question:

Anton van Straaten wrote:
>
> 3.  A really natural term to refer to types which programmers reason
> about, even if they are not statically checked, is "latent types".  It
> captures the situation very well intuitively, and it has plenty of
> precedent -- e.g. it's mentioned in the Scheme reports, R5RS and its
> predecessors, going back at least a decade or so (haven't dug to check
> when it first appeared).

Can you be more explicit about what "latent types" means?
I'm sorry to say it's not at all natural or intuitive to me.
Are you referring to the types in the programmers head,
or the ones at runtime, or what?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Torben Ægidius Mogensen wrote:
>
> That's not true.  ML has variables in the mathematical sense of
> variables -- symbols that can be associated with different values at
> different times.  What it doesn't have is mutable variables (though it
> can get the effect of those by having variables be immutable
> references to mutable memory locations).

While we're on the topic of terminology, here's a pet peeve of
mine: "immutable variable."

immutable = can't change
vary-able = can change

Clearly a contradiction in terms.

If you have a named value that cannot be updated, it makes
no sense to call it "variable" since it isn't *able* to *vary.*
Let's call it a named constant.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Andreas Rossberg wrote:
> Chris Uppal wrote:
> >
> > I have never been very happy with relating type to sets of values (objects,
> > whatever).
>
> Indeed, this view is much too narrow. In particular, it cannot explain
> abstract types, which is *the* central aspect of decent type systems.

What prohibits us from describing an abstract type as a set of values?


> There were papers observing this as early as 1970.

References?


> (There are also theoretic problems with the types-as-sets view, because
> sufficiently rich type systems can no longer be given direct models in
> standard set theory. For example, first-class polymorphism would run
> afoul the axiom of foundation.)

There is no reason why we must limit ourselves to "standard set theory"
any more than we have to limit ourselves to standard type theory.
Both are progressing, and set theory seems to me to be a good
choice for a foundation. What else would you use?

(Agree with the rest.)


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Dr.Ruud wrote:
> Marshall schreef:
>
> > "dynamic types." I don't have a firm definition for
> > that term, but my working model is runtime type tags. In which
> > case, I would say that among statically typed languages,
> > Java does have dynamic types, but C does not. C++ is
> > somewhere in the middle.
>
> C has union.

But it does not have tagged unions, so my point is unaffected.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Matthias Blume wrote:
> "Marshall" <[EMAIL PROTECTED]> writes:
>
> > Torben Ægidius Mogensen wrote:
> >>
> >> That's not true.  ML has variables in the mathematical sense of
> >> variables -- symbols that can be associated with different values at
> >> different times.  What it doesn't have is mutable variables (though it
> >> can get the effect of those by having variables be immutable
> >> references to mutable memory locations).
> >
> > While we're on the topic of terminology, here's a pet peeve of
> > mine: "immutable variable."
> >
> > immutable = can't change
> > vary-able = can change
> >
> > Clearly a contradiction in terms.
>
> No, it is not a contradiction.  See the mathematical usage of the word
> "variable".

I am not saying that this kind of terminology isn't common; what
I'm saying is that it isn't good. And I think I gave a pretty clear
and solid definition of the two words, and those definitions are
decidedly contradictory.


> Immutable variables can stand for different values at
> different times, even without mutation involved, usually because they
> are bound by some construct such as lambda.

Well, that's a good point actually. Parameters are variable
no matter how you look at it. I was speaking more in terms
of locals.


> > If you have a named value that cannot be updated, it makes
> > no sense to call it "variable" since it isn't *able* to *vary.*
>
> Mutation is not the only way for an expression to evaluate to
> different values over time.

I suppose the difficulty arises from the difference
between the connotation of "mutate" in a PLT context, which is
support for destructive assignment, and the meaning of the word
in the larger context.

Anyway, I don't see how your sentence above contradicts
my sentence. We do not use the term "update" to describe
the process of binding values to parameters upon function
invocation. (Am I wrong?)


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Chris Smith wrote:
> 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.

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.

But again, my dynamic kung fu is very weak, so I may not know
what I'm talking about when I represent the dynamic side.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Rob Warnock wrote:
> Marshall <[EMAIL PROTECTED]> wrote:
> >
> > Can you be more explicit about what "latent types" means?
> > I'm sorry to say it's not at all natural or intuitive to me.
> > Are you referring to the types in the programmers head,
> > or the ones at runtime, or what?
>
> Here's what the Scheme Standard has to say:
>
> http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-4.html
> 1.1  Semantics
> ...
> Scheme has latent as opposed to manifest types. Types are assoc-
> iated with values (also called objects) rather than with variables.
> (Some authors refer to languages with latent types as weakly typed
> or dynamically typed languages.) Other languages with latent types
> are APL, Snobol, and other dialects of Lisp. Languages with manifest
> types (sometimes referred to as strongly typed or statically typed
> languages) include Algol 60, Pascal, and C.
>
> To me, the word "latent" means that when handed a value of unknown type
> at runtime, I can look at it or perform TYPE-OF on it or TYPECASE or
> something and thereby discover its actual type at the moment[1], whereas
> "manifest" means that types[2] are lexically apparent in the code.

Hmmm. If I read the R5RS text correctly, it is simply doing the
either/or thing that often happens with "static/dynamic" only
using different terms. I don't see any difference between
"latent" and "dynamic." Also, this phrase "types associated with
values instead of variables" that I'm starting to see a lot is
beginning to freak me out: the implication is that other languages
have types associated with variables and not values, which
doesn't describe anything I can think of.

In your followup paragraph, you've contrasted runtime type
introspection, vs. explicit type declarations, which seem
orthorgonal to me. (Not that you said they weren't.)


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Pascal Costanza wrote:
>
> A statically type language requires you to think about two models of
> your program at the same time: the static type model and the dynamic
> behavioral model. A static type system ensures that these two
> _different_ (that's important!) perspectives are always in sync. This is
> especially valuable in settings where you know your domain well and want
> to rely on feedback by your compiler that you haven't made any mistakes
> in encoding your knowledge. (A static type system based on type
> inferencing doesn't essentially change the requirement to think in two
> models at the same time.)
>
> A dynamically typed language is especially well suited when you don't
> (yet) have a good idea about your domain and you want to use programming
> especially to explore that domain. Some static typing advocates claim
> that static typing is still suitable for exploring domains because of
> the compiler's feedback about the preliminary encoding of your
> incomplete knowledge, but the disadvantages are a) that you still have
> to think about two models at the same time when you don't even have
> _one_ model ready and b) that you cannot just run your incomplete
> program to see what it does as part of your exploration.
>
> A statically typed language with a dynamic type treats dynamic typing as
> the exception, not as the general approach, so this doesn't help a lot
> in the second setting (or so it seems to me).
>
> A language like Common Lisp treats static typing as the exception, so
> you can write a program without static types / type checks, but later on
> add type declarations as soon as you get a better understanding of your
> domain. Common Lisp implementations like CMUCL or SBCL even include
> static type inference to aid you here, which gives you warnings but
> still allows you to run a program even in the presence of static type
> errors. I guess the feedback you get from such a system is probably not
> "strong" enough to be appreciated by static typing advocates in the
> first setting (where you have a good understanding of your domain).

I am sceptical of the idea that when programming in a dynamically
typed language one doesn't have to think about both models as well.
I don't have a good model of the mental process of working
in a dynamically typed language, but how could that be the case?
(I'm not asking rhetorically.) Do you then run your program over
and over, mechanically correcting the code each time you discover
a type error? In other words, if you're not thinking of the type model,
are you using the runtime behavior of the program as an assistant,
the way I use the static analysis of the program as an assistant?

I don't accept the idea about pairing the appropriateness of each
system according to whether one is doing exploratory programming.
I do exploratory programming all the time, and I use the static type
system as an aide in doing so. Rather I think this is just another
manifestation of the differences in the mental processes between
static typed programmers and dynamic type programmers, which
we are beginning to glimpse but which is still mostly unknown.

Oh, and I also want to say that of all the cross-posted mega threads
on static vs. dynamic typing, this is the best one ever. Most info;
least flames. Yay us!


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Andreas Rossberg wrote:
> Marshall wrote:
> >
> > What prohibits us from describing an abstract type as a set of values?
>
> If you identify an abstract type with the set of underlying values then
> it is equivalent to the underlying representation type, i.e. there is no
> abstraction.

I don't follow. Are you saying that a set cannot be described
intentionally? How is "the set of all objects that implement the
Foo interface" not sufficiently abstract? Is it possible you are
mixing in implementation concerns?


> >>There were papers observing this as early as 1970.
> >
> > References?
>
> This is 1973, actually, but most relevant:
>
>James Morris
>Types Are Not Sets.
>Proc. 1st ACM Symposium on Principles of Programming Languages, 1973

Okay. Since this paper is in the ACM walled garden, I'll have to
wait until next week to get a look at it. But thanks for the reference.


> >>(There are also theoretic problems with the types-as-sets view, because
> >>sufficiently rich type systems can no longer be given direct models in
> >>standard set theory. For example, first-class polymorphism would run
> >>afoul the axiom of foundation.)
> >
> > There is no reason why we must limit ourselves to "standard set theory"
> > any more than we have to limit ourselves to standard type theory.
> > Both are progressing, and set theory seems to me to be a good
> > choice for a foundation. What else would you use?
>
> I'm no expert here, but Category Theory is a preferred choice in many
> areas of PLT.

Fair enough.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Pascal Costanza wrote:
>
> Consider a simple expression like 'a + b': In a dynamically typed
> language, all I need to have in mind is that the program will attempt to
> add two numbers. In a statically typed language, I additionally need to
> know that there must a guarantee that a and b will always hold numbers.

I still don't really see the difference.

I would not expect that the dynamic programmer will be
thinking that this code will have two numbers most of the
time but sometimes not, and fail. I would expect that in both
static and dynamic, the thought is that that code is adding
two numbers, with the difference being the static context
gives one a proof that this is so. In this simple example,
the static case is better, but this is not free, and the cost
of the static case is evident elsewhere, but maybe not
illuminated by this example.

This thread's exploration of the mindset of the two kinds
of programmers is difficult. It is actually quite difficult,
(possibly impossible) to reconstruct mental states
though introspection. Nonetheless I don't see any
other way to proceed. Pair programming?


> My goal is not to convince anyone, my goal is to illustrate for those
> who are interested in getting a possibly different perspective.

Yes, and thank you for doing so.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Marshall wrote:
>
> In this simple example,
> the static case is better, but this is not free, and the cost
> of the static case is evident elsewhere, but maybe not
> illuminated by this example.

Ugh, please forgive my ham-fisted use of the word "better."
Let me try again:

In this simple example, the static case is provides you with
a guarantee of type safety, but this is not free, and the
cost of the static case may be evident elsewhere, even
if not illuminated by this example.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Joe Marshall wrote:
>
> That's the important point:  I want to run broken code.

I want to make sure I understand. I can think of several things
you might mean by this. It could be:
1) I want to run my program, even though I know parts of it
are broken, because I think there are parts that are not broken
and I want to try them out.
2) I want to run my program, even though it is broken, and I
want to run right up to a broken part and trap there, so I can
use the runtime facilities of the language to inspect what's
going on.


> I want to run
> as much of the working fragments as I can, and I want a `safety net' to
> prevent me from performing undefined operations, but I want the safety
> net to catch me at the *last* possible moment.

This statement is interesting, because the conventional wisdom (at
least as I'm used to hearing it) is that it is best to catch bugs
at the *first* possible moment. But I think maybe we're talking
about different continua here. The last last last possible moment
is after the software has shipped to the customer, and I'm pretty
sure that's not what you mean. I think maybe you mean something
more like 2) above.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> > immutable = can't change
> > vary-able = can change
> >
> > Clearly a contradiction in terms.
>
> Not in mathematics.

So stipulated.

However, it *is* a contradiction in English. Now, we often redefine
or narrow terms for technical fields. However, when we find
ourselves in a situation where we've inverted the English
meaning with the technical meaning, or ended up with a
contradiction, it ought to give us pause.


> The understanding there is that a "variable" varies - not over time, but
> according to the whim of the usage. (E.g. if a function is displayed in
> a graph, the parameter varies along the X axis. If it's used within a
> term, the parameter varies depending on how it's used. Etc.)
>
> Similarly for computer programs.
> Of course, if values are immutable, the value associated with a
> parameter name cannot vary within the same invocation - but it can still
> vary from one invocation to the next.

Again, stipulated. In fact I conceded this was a good point when it
was first mentioned. However, we generally refer to parameters
to functions as "parameters"-- you did it yourself above.

What we generally (in programming) call variables are locals
and globals. If the languages supports an update operation
on those variables, then calling them variables makes sense.
But "variable" has become such a catch-all term that we call

  public static final int FOO = 7;

a variable, even though it can never, ever vary.

That doesn't make any sense.

If we care about precision in our terminology, we ought to
distinguish among parameters, named values that support
destructive update, named values that don't support
destructive update, and possibly other things.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Timo Stamm wrote:
>
> This is actually one of the most interesting threads I have read in a
> long time. If you ignore the evangelism, there is a lot if high-quality
> information and first-hand experience you couldn't find in a dozen books.

Hear hear! This is an *excellent* thread. The evangelism is at
rock-bottom
and the open exploration of other people's way of thinking is at what
looks to me like an all-time high.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Anton van Straaten wrote:
> Marshall wrote:
> > Can you be more explicit about what "latent types" means?
> > I'm sorry to say it's not at all natural or intuitive to me.
> > Are you referring to the types in the programmers head,
> > or the ones at runtime, or what?
>
> Sorry, that was a huge omission.  (What I get for posting at 3:30am.)

Thanks for the excellent followup.


> The short answer is that I'm most directly referring to "the types in
> the programmer's head".

In the database theory world, we speak of three levels: conceptual,
logical, physical. In a dbms, these might roughly be compared to
business entities described in a requirements doc, (or in the
business owners' heads), the (logical) schema encoded in the
dbms, and the b-tree indicies the dbms uses for performance.

So when you say "latent types", I think "conceptual types."

The thing about this is, both the Lisp and the Haskell programmers
are using conceptual types (as best I can tell.) And also, the
conceptual/latent types are not actually a property of the
program; they are a property of the programmer's mental
model of the program.

It seems we have languages:
with or without static analysis
with or without runtime type information (RTTI or "tags")
with or without (runtime) safety
with or without explicit type annotations
with or without type inference

Wow. And I don't think that's a complete list, either.

I would be happy to abandon "strong/weak" as terminology
because I can't pin those terms down. (It's not clear what
they would add anyway.)


> A more complete informal summary is as follows:
>
> Languages with latent type systems typically don't include type
> declarations in the source code of programs.  The "static" type scheme
> of a given program in such a language is thus latent, in the English
> dictionary sense of the word, of something that is present but
> undeveloped.  Terms in the program may be considered as having static
> types, and it is possible to infer those types, but it isn't necessarily
> easy to do so automatically, and there are usually many possible static
> type schemes that can be assigned to a given program.
>
> Programmers infer and reason about these latent types while they're
> writing or reading programs.  Latent types become manifest when a
> programmer reasons about them, or documents them e.g. in comments.

Uh, oh, a new term, "manifest." Should I worry about that?


> (As has already been noted, this definition may seem at odds with the
> definition given in the Scheme report, R5RS, but I'll address that in a
> separate post.)
>
> There's a close connection between latent types in the sense I've
> described, and the "tagged values" present at runtime.  However, as type
> theorists will tell you, the tags used to tag values at runtime, as e.g.
> a number or a string or a FooBar object, are not the same thing as the
> sort of types which statically-typed languages have.
>
> A simple example of the distinction can be seen in the type of a
> function.  Using Javascript as a lingua franca:
>
>function timestwo(x) { return x * 2 }
>
> In a statically-typed language, the type of a function like this might
> be something like "number -> number", which tells us three things: that
> timestwo is a function; that it accepts a number argument; and that it
> returns a number result.
>
> But if we ask Javascript what it thinks the type of timestwo is, by
> evaluating "typeof timestwo", it returns "function".  That's because the
> value bound to timestwo has a tag associated with it which says, in
> effect, "this value is a function".

Well, darn. It strikes me that that's just a decision the language
designers
made, *not* to record complete RTTI. (Is it going to be claimed that
there is an *advantage* to having only incomplete RTTI? It is a
serious question.)


> But "function" is not a useful type.  Why not?  Because if all you know
> is that timestwo is a function, then you have no idea what an expression
> like "timestwo(foo)" means.  You couldn't write working programs, or
> read them, if all you knew about functions was that they were functions.
>   As a type, "function" is incomplete.

Yes, function is a parameterized type, and they've left out the
parameter values.


> By my definition, though, the latent type of timestwo is "number ->
> number".  Any programmer looking at the function can figure out that
> this is its type, and programmers do exactly that when reasoning about a
> program.

Gotcha.


> (Aside: technically, you can pass

Re: What is Expressiveness in a Computer Language

[Marshall]

Rob Thorpe wrote:
> David Hopwood wrote:
>
> The term "dynamically typed" is well used and understood.  The term
> untyped is generally associated with languages that as you put it "have
> no memory safety", it is a pejorative term.  "Latently typed" is not
> well used unfortunately, but more descriptive.
>
> Most of the arguments above describe a static type system then follow
> by saying that this is what "type system" should mean, and finishing by
> saying everything else should be considered untyped. This seems to me
> to be an effort to associate dynamically typed languages with this
> perjorative term.

I can believe that someone, somewhere out there might have done
this, but I can't recall ever having seen it. In any event, the
standard
term for memory safety is "safety", not "untyped." Further, anyone
who was interested in actually understanding the issues woudn't
be doing what you describe.

And if you did find someone who was actively doing this I would
say "never attribute to malice what can adequately be explained
by stupidity."


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Andreas Rossberg wrote:
> Marshall wrote:
> >
> > What we generally (in programming) call variables are locals
> > and globals. If the languages supports an update operation
> > on those variables, then calling them variables makes sense.
> > But "variable" has become such a catch-all term that we call
> >
> >   public static final int FOO = 7;
> >
> > a variable, even though it can never, ever vary.
> >
> > That doesn't make any sense.
>
> It does, because it is only a degenerate case. In general, you can have
> something like
>
>void f(int x)
>{
>   const int foo = x+1;
>   //...
>}
>
> Now, foo is still immutable, it is a local, but it clearly also varies.

So what then is to be the definition of "variable" if it includes
things that can never vary, because they are only a degenerate
case? Shall it be simply a named value?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Pascal Costanza wrote:
> Marshall wrote:
> > Pascal Costanza wrote:
> >> Consider a simple expression like 'a + b': In a dynamically typed
> >> language, all I need to have in mind is that the program will attempt to
> >> add two numbers. In a statically typed language, I additionally need to
> >> know that there must a guarantee that a and b will always hold numbers.
> >
> > I still don't really see the difference.
> >
> > I would not expect that the dynamic programmer will be
> > thinking that this code will have two numbers most of the
> > time but sometimes not, and fail. I would expect that in both
> > static and dynamic, the thought is that that code is adding
> > two numbers, with the difference being the static context
> > gives one a proof that this is so.
>
> There is a third option: it may be that at the point where I am writing
> this code, I simply don't bother yet whether a and b will always be
> numbers. In case something other than numbers pop up, I can then
> make a decision how to proceed from there.

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?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Chris Uppal wrote:
>
> But, as a sort of half-way, semi-formal, example: consider the type 
> environment
> in a Java runtime.  The JVM does formal type-checking of classfiles as it 
> loads
> them.  In most ways that checking is static -- it's treating the bytecode as
> program text and doing a static analysis on it before allowing it to run (and
> rejecting what it can't prove to be acceptable by its criteria).  However, it
> isn't /entirely/ static because the collection of classes varies at runtime in
> a (potentially) highly dynamic way.  So it can't really examine the "whole"
> text of the program -- indeed there is no such thing.  So it ends up with a
> hybrid static/dynamic type system -- it records any assumptions it had to make
> in order to find a proof of the acceptability of the new code, and if 
> (sometime
> in the future) another class is proposed which violates those assumptions, 
> then
> that second class is rejected.

I have to object to the term "hybrid".

Java has a static type system.
Java has runtime tags and tag checks.

The two are distinct, and neither one is less than complete, so
I don't think "hybrid" captures the situation well.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Chris Uppal wrote:
>  /Given/ a set of operations which I want to forbid,
> I would like to say that a "dynamic type system" which prevents them executing
> is doing very much the same job as a static type system which stops the code
> compiling.

There are similarities, (classifying values into categories, and
checking
whether functions are sensibly invoked according these categories)
and there are differences (in the difference between existential
quantification of success vs. universal quantification of success.)
They are certainly not identical. (I'm not sure if by "very much the
same" you meant identical or not.)


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

Sometimes the things you want to check are emergent properties
of a progam rather than local properties. I don't see how runtime
checks can do anything with these properties, at least not without
a formal framework. An example is deadlock freedom. There
exist type systems that can prove code free of deadlock or
race conditions. How woud you write a runtime check for that?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Chris Uppal wrote:
> David Hopwood wrote:
>
> > > But some of the advocates of statically
> > > typed languages wish to lump these languages together with assembly
> > > language a "untyped" in an attempt to label them as unsafe.
> >
> > A common term for languages which have defined behaviour at run-time is
> > "memory safe". For example, "Smalltalk is untyped and memory safe."
> > That's not too objectionable, is it?
>
> I find it too weak, as if to say: "well, ok, it can't actually corrupt memory
> as such, but the program logic is still apt go all over the shop"...

It is impossible to evaluate your claim without a specific definition
of "go all over the shop." If it means subject to Method Not
Understood,
then we would have to say that Smalltalk can in fact go all over
the shop. If it means subject to memory corruption, then it can't.

In any event, the denotation is quite clear: Smalltalk does not
formally assign types to expressions during a static analysis
phase, and Smalltalk is not subject to memory corruption.

I have a problem with the whole line of reasoning that goes
"someone might think term x means something bad, so we
can't use it." It's unfalsifiable. It also optimizes for malicious
use of the terms. Both are bad properties to have as design
principles, at least in this context.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Andreas Rossberg wrote:
>
> ... And the reason is that "type" has a
> well-established use in theory. It is not just my "assumption", it is
> established practice since 80 or so years.

Wouldn't it be fair to say it goes back a least to
Principia Mathematica, 1910?


> So far, this discussion has
> not revealed the existence of any formal work that would provide a
> theory of "dynamic types" in the sense it is used to characterise
> "dynamically typed" languages.

Indeed, the idea I am starting to get is that much of what is going
on in the dynamic/latent/untyped/whatever world is simply informal,
conceptual-level static analysis. The use of the runtime system
is a formal assistant to this informal analysis. In other words,
formal existential quantification is used as hint to help do
informal universal quantification.

Now, given that explanation, the formal analysis looks better.
But that's not the whole story. We also have the fact that
the informal analysis gets to run on the human brain, while
the static analysis has to run on a lousy microprocessor
with many orders of magnitude less processing power.
We have the fact that the formal static analysis is of
limited power. We have the fact that historically,
static languages have forbidden the use of the formal
existential method preferred by the DT crowd until
*after* the static analysis has passed, thus defeating
their purpose. And probably still more things that I
don't appreciate yet. So I'll now throw around some
terms (in an attempt to look smart :-) and say,
late binding, impredicativity.


Marshal

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Joe Marshall wrote:
> Marshall wrote:
> > Joe Marshall wrote:
> > >
> > > That's the important point:  I want to run broken code.
> >
> > I want to make sure I understand. I can think of several things
> > you might mean by this. It could be:
> > 1) I want to run my program, even though I know parts of it
> > are broken, because I think there are parts that are not broken
> > and I want to try them out.
>
> I think I mean a little of each of these.
>
> Nearly *every* program I have ever used is buggy, so this is actually a
> normal state of affairs even when I'm not debugging or developing.

That makes some sense to me.

It seems quite reasonable, as a language feature, to be
able to say to the computer: I know there are a few type
errors; just run this damn program as best you can.


> > 2) I want to run my program, even though it is broken, and I
> > want to run right up to a broken part and trap there, so I can
> > use the runtime facilities of the language to inspect what's
> > going on.
>
> I do this quite often.  Sometimes I'll develop `in the debugger'.  I'll
> change some piece of code and run the program until it traps.  Then,
> without exiting the debugger, I'll fix the immediate problem and
> restart the program at the point it trapped.  This technique takes a
> bit of practice, but if you are working on something that's complex and
> has a lot of state, it saves a lot of time because you don't have to
> reconstruct the state every time you make a change.

Wow, interesting.

(I say the following only to point out differing strategies of
development, not to say one or the other is right or bad or
whatever.)

I occasionally find myself doing the above, and when I do,
I take it as a sign that I've screwed up. I find that process
excruciating, and I do everything I can to avoid it. Over the
years, I've gotten more and more adept at trying to turn
as many bugs as possible into type errors, so I don't have
to run the debugger.

Now, there might be an argument to be made that if I had
been using a dynamic language, the process wouldn't be
so bad, and I woudn't dislike it so much. But mabe:

As a strawman: suppose there are two broad categories
of mental strategies for thinking about bugs, and people
fall naturally into one way or the other, the way there
are morning people and night people. One group is
drawn to the static analysis, one group hates it.
One group hates working in the debugger, one group
is able to use that tool very effectively and elegantly.

Anyway, it's a thought.


> > > I want to run
> > > as much of the working fragments as I can, and I want a `safety net' to
> > > prevent me from performing undefined operations, but I want the safety
> > > net to catch me at the *last* possible moment.
> >
> > This statement is interesting, because the conventional wisdom (at
> > least as I'm used to hearing it) is that it is best to catch bugs
> > at the *first* possible moment. But I think maybe we're talking
> > about different continua here. The last last last possible moment
> > is after the software has shipped to the customer, and I'm pretty
> > sure that's not what you mean. I think maybe you mean something
> > more like 2) above.
>
> It is often the case that the proximate cause of a bug is nowhere near
> where the fix needs to be applied.  This is especially true with the
> really hard bugs.  A static type system will tell me that there (may)
> exist a path through the code that results in an error, but the runtime
> check that fails will provide a witness.

Ah, the witness! I see the witness idea as supporting my thesis
that some people are using formal existential reasoning as a
tool for informal universal reasoning.

Very interesting. I want to again emphasize that I am not
interested in labelling one or the other of these approaches
as better or worse; rather, I want to understand both of
them, particularly to see if it is possible to have a single
language that incorporate both approaches.

This is not to say that I don't find one approach more appealing
than the other; rather it is to assert that I can tell the difference
between my personal preference and Truth. (Sometimes.)


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Joe Marshall wrote:
> Marshall wrote:
> > Timo Stamm wrote:
> > >
> > > This is actually one of the most interesting threads I have read in a
> > > long time. If you ignore the evangelism, there is a lot if high-quality
> > > information and first-hand experience you couldn't find in a dozen books.
> >
> > Hear hear! This is an *excellent* thread. The evangelism is at
> > rock-bottom
> > and the open exploration of other people's way of thinking is at what
> > looks to me like an all-time high.
>
> What are you, some sort of neo-static pseudo-relational
> object-disoriented fascist?

I prefer to think in terms of "object orientatedness."

But you're close. I'd say rather that I'm a quasi-theoretical,
neo-relational, crypto-logical fascist. But definitely fascist.

Once after a lengthy debate with a schemer, he
dubbed me (good naturedly) "Il Duce." Heh.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Saying "latently-typed language" is making a category mistake

[Marshall]

Chris Uppal wrote:
> Pascal Costanza wrote:
>
> > Sorry, obviously I was far from being clear. ACL2 is not
> > Turing-complete. All iterations must be expressed in terms of
> > well-founded recursion.
>
> How expressive does that end up being for real problems ?   I mean obviously 
> in
> some sense it's crippling, but how much of a restiction would that be for
> non-accademic programming.  Could I write an accountancy package in it, or an
> adventure games, or a webserver, with not too much more difficulty than in a
> similar language without that one aspect to its type system ?
>
> Hmm, come to think of it those all hae endless loops at the outer level, with
> the body of the loop being an event handler, so maybe only the handler should
> be required to guaranteed to terminate.

An example of a non-Turing-complete language (at least the core
language; the standard is getting huge) with guaranteed termination,
that is used everywhere and quite useful, is SQL.

I wouldn't want to write an accounting package in it; its abstraction
facilities are too weak. But the language is much more powerful
than it is usually given credit for.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Darren New wrote:
> Marshall wrote:
> > I can't see how you'd call + on a and b if you think they might
> > not be numbers.
>
> Now substitute "<" for "+" and see if you can make the same argument. :-)

If your point is about overloading, then I don't see how it affects my
point. My point was, I don't see why you'd be writing code using
operators that you thought might not be applicable to the operands.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Chris Smith wrote:
> 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.]

Sure. This is what abstract algebra is all about; group theory is
just an example. In particular, much of Stepanov's life work
has been developing abstract algebra within the framework
of a static type system.

http://www.stepanovpapers.com/
In particular, see the paper "Greatest Common Measure, the
Last 2500 Years."


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

Exactly.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Chris Smith wrote:
> 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?

In the same way that a mule is less than a complete horse.

It is a small point, and probably not worth much attention.
In fact, I was probably just being fussy in the first place.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Rob Thorpe wrote:
>
> Can I make a type in C that can only have values between 1 and 10?
> How about a variable that can only hold odd numbers, or, to make it
> more difficult, say fibonacci numbers?

Well, of course you can't in *C*; you can barely zip you pants with C.
But I believe you can do the above in C++, can't you?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Chris Uppal wrote:
> Marshall wrote:
>
> [me:]
> > > But, as a sort of half-way, semi-formal, example: consider the type
> > > environment in a Java runtime.  The JVM does formal type-checking of
> > > classfiles as it loads them.  In most ways that checking is static --
> > > it's treating the bytecode as program text and doing a static analysis
> > > on it before allowing it to run (and rejecting what it can't prove to
> > > be acceptable by its criteria).  However, it isn't /entirely/ static
> > > because the collection of classes varies at runtime in a (potentially)
> > > highly dynamic way.  So it can't really examine the "whole" text of the
> > > program -- indeed there is no such thing.  So it ends up with a hybrid
> > > static/dynamic type system -- it records any assumptions it had to make
> > > in order to find a proof of the acceptability of the new code, and if
> > > (sometime in the future) another class is proposed which violates those
> > > assumptions, then that second class is rejected.
> >
> > I have to object to the term "hybrid".
> >
> > Java has a static type system.
> > Java has runtime tags and tag checks.
>
> It has both, agreed, but that isn't the full story.  I think I explained what 
> I
> meant, and why I feel the term is justified as well as I can in the second 
> half
> of the paragraph you quoted.  I doubt if I can do better.
>
> Maybe you are thinking that I mean that /because/ the JVM does verification,
> etc, at "runtime" the system is hybrid ?
>
> Anyway that is /not/ what I mean.  I'm (for these purposes) completely
> uninterested in the static checking done by the Java to bytecode translator,
> javac.  I'm interested in what happens to the high-level, statically typed, 
> OO,
> language called "java bytecode" when the JVM sees it.  That language has a
> strict static type system which the JVM is required to check.  That's a
> /static/ check in my book -- it happens before the purportedly correct code is
> accepted, rather than while that code is running.
>
> I am also completely uninterested (for these immediate purposes) in the run
> time checking that the JVM does (the stuff that results in
> NoSuchMethodException, and the like).  In the wider context of the thread, I 
> do
> want to call that kind of thing (dynamic) type checking -- but those checks 
> are
> not why I call the JVMs type system hybrid either.
>
> Oh well, having got that far, I may as well take another stab at "hybrid".
> Since the JVM is running a static type system without access to the whole text
> of the program, there are some things that it is expected to check which it
> can't.   So it records preconditions on classes which might subsequently be
> loaded.  Those are added to the static checks on future classes, but -- as far
> as the original class is concerned -- those checks happen dynamically.  So 
> part
> of the static type checking which is supposed to happen, has been postponed to
> a dynamic check.  It's that, and /only/ that which I meant by "hybrid".

That's fair, I guess. I wouldn't use the terms you do, but maybe that
doesn't matter very much assuming we understand each other
at this point.



Marshal

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Dr.Ruud wrote:
> Marshall schreef:
> > Rob Thorpe:
>
> >> Can I make a type in C that can only have values between 1 and 10?
> >> How about a variable that can only hold odd numbers, or, to make it
> >> more difficult, say fibonacci numbers?
> >
> > Well, of course you can't in *C*; you can barely zip you pants with C.
> > But I believe you can do the above in C++, can't you?
>
> You can write self-modifying code in C, so I don't see how you can not
> do that in C.
> ;)

I stand corrected: if one is using C and writing self-modifying
code, then one *can* zip one's pants.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Anton van Straaten wrote:
>
> But beyond that, there's an issue here about the definition of "the
> language".  When programming in a latently-typed language, a lot of
> action goes on outside the language - reasoning about static properties
> of programs that are not captured by the semantics of the language.
>
> This means that there's a sense in which the language that the
> programmer programs in is not the same language that has a formal
> semantic definition.  As I mentioned in another post, programmers are
> essentially mentally programming in a richer language - a language which
> has informal (static) types - but the code they write down elides this
> type information, or else puts it in comments.
>
> We have to accept, then, that the formal semantic definitions of
> dynamically-checked languages are incomplete in some important ways.
> Referring to those semantic definitions as "the language", as though
> that's all there is to the language in a broader sense, is misleading.
>
> In this context, the term "latently-typed language" refers to the
> language that a programmer experiences, not to the subset of that
> language which is all that we're typically able to formally define.

That is starting to get a bit too mystical for my tastes.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Saying "latently-typed language" is making a category mistake

[Marshall]

David Hopwood wrote:
>
> A type system that required an annotation on all subprograms that do not
> provably terminate, OTOH, would not impact expressiveness at all, and would
> be very useful.

Interesting. I have always imagined doing this by allowing an
annotation on all subprograms that *do* provably terminate. If
you go the other way, you have to annotate every function that
uses general recursion (or iteration if you swing that way) and that
seems like it might be burdensome. Further, it imposes the
annotation requirement even where the programer might not
care about it, which the reverse does not do.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Saying "latently-typed language" is making a category mistake

[Marshall]

Gabriel Dos Reis wrote:
> "Marshall" <[EMAIL PROTECTED]> writes:
>
> | David Hopwood wrote:
> | >
> | > A type system that required an annotation on all subprograms that do not
> | > provably terminate, OTOH, would not impact expressiveness at all, and 
> would
> | > be very useful.
> |
> | Interesting. I have always imagined doing this by allowing an
> | annotation on all subprograms that *do* provably terminate. If
> | you go the other way, you have to annotate every function that
> | uses general recursion (or iteration if you swing that way) and that
> | seems like it might be burdensome. Further, it imposes the
> | annotation requirement even where the programer might not
> | care about it, which the reverse does not do.
>
> simple things should stay simple.  Recursions that provably terminate
> are among the simplest ones.  Annotations in those cases could be
> allowed, but not required.  Otherwise the system might become very
> irritating to program with.

Yes, exactly my point.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Chris F Clark wrote:
>
> I'm particularly interested if something unsound (and perhaps
> ambiguous) could be called a type system.  I definitely consider such
> things type systems.

I don't understand. You are saying you prefer to investigate the
unsound over the sound?


> However, I like my definitions very general and
> vague.  Your writing suggests the opposite preference.

Again, I cannot understand this. In a technical realm, vagueness
is the opposite of understanding. To me, it sounds like you are
saying that you prefer not to understand the field you work in.


> To me if
> something works in an analogous way to how a known type system, I tend
> to consider it a "type system".  That probably isn't going to be at
> all satisfactory to someone wanting a more rigorous definition.

Analogies are one thing; definitions are another.


> Of
> course, to my mind, the rigorous definitions are just an attempt to
> capture something that is already known informally and put it on a
> more rational foundation.

If something is informal and non-rational, it cannot be said to
be "known." At best, it could be called "suspected." Even if you
think something which turns out to be true, we could not say
that you "knew" it unless your reasons for your thoughts were
valid.

I flipped a coin to see who would win the election; it came
up "Bush". Therefore I *knew* who was going to win the
election before it happened. See the probem?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Joachim Durchholz wrote:
> Anton van Straaten schrieb:
> >> It seems we have languages:
> >> with or without static analysis
> >> with or without runtime type information (RTTI or "tags")
> >> with or without (runtime) safety
> >> with or without explicit type annotations
> >> with or without type inference
> >>
> >> Wow. And I don't think that's a complete list, either.
> >
> > Yup.
>
> What else?
> (Genuinely curious.)

I left off a big one: nominal vs. structural

Also: has subtyping polymorphism or not, has parametric polymorphism or
not.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Chris F Clark wrote:
> Chris F Clark (I) wrote:
>
> > I'm particularly interested if something unsound (and perhaps
> > ambiguous) could be called a type system.  I definitely consider such
> > things type systems.
>
> "Marshall" <[EMAIL PROTECTED]> wrote:
>
> > I don't understand. You are saying you prefer to investigate the
> > unsound over the sound?
> ...
> > Again, I cannot understand this. In a technical realm, vagueness
> > is the opposite of understanding.
>
> At the risk of injecting too much irrelevant philosophy into the
> discussion, I will with great trepdiation reply.

I agree this is OT, but I'm not sure about the source of trepidation.


> First in the abstrtact: No, understanding is approximating.

Agreed.


> The world is inherently vague.

Our understanding of the world is vague. The world itself is
not at all vague.


> We make false symbolic models of the world which
> are consistent, but at some level they do not reflect reality,

Yes...

> because reality isn't consistent.

What?!


> Only by abtracting away the inherent
> infinite amout of subtlety present in the real universe can we come to
> comprehensible models.

Sure. (Although I object to "infinite.")


> Those models can be consistent, but they are
> not the universe.  The models in their consistency, prove things which
> are not true about the real universe.

Sure, sure, sure. None of these is a reaon to prefer the unsound
over the sound.


> Now in the concrete: In my work productivity is ultimately important.
> Therefore, we live by the 80-20 rule in numerous variations.  One of
> ths things we do to achieve productivity is simplify things.  In fact,
> we are more interested in an unsound simplification that is right 80%
> of the time, but takes only 20% of the effort to compute, than a
> completely sound (100% right) model which takes 100% of the time to
> compute (which is 5 times as long).  We are playing the probabilities.

What you are describing is using a precise mathematical function
to approximate a different precise mathematical function. This
argues for the value of approximation functions, which I do not
dispute. But this does not in any way support the idea of vague
trumping precise, informal trumping formal, or unsoundness as
an end in itself.


> It's not that we don't respect the sound underpining, the model which
> is consistent and establishes certain truths.  However, what we want
> is the rule of thumb which is far simpler and approximates the sound
> model with reasonable accuracy.  In particular, we accept two types of
> unsoundness in the model.  One, we accept a model which gives wrong
> answers which are detectable.  We code tests to catch those cases, and
> use a different model to get the right answer.  Two, we accept a model
> which gets the right answer only when over-provisioned.  for example,
> if we know a loop will occassionaly not converge in the n-steps that
> it theoretically should, we will run the loop for n+m steps until the
> approximation also converges--even if that requires allocating m extra
> copies of some small element than are theoretically necessary.  A
> small waste of a small resource, is ok if it saves a waste of a more
> critical resource--the most critical resource of all being our project
> timeliness.

Υes, I'm quite familiar with modelling, abstraction, approximation,
etc. However nothing about those endevours suggests to me
that unsoundness is any kind of goal.


> Marshall's last point:
>
> > I flipped a coin to see who would win the election; it came
> > up "Bush". Therefore I *knew* who was going to win the
> > election before it happened. See the probem?
>
> Flipping one coin to determine an election is not playing the
> probabilities correctly.  You need a plausible explanation for why the
> coin should predict the right answer and a track record of it being
> correct.  If you had a coin that had correctly predicted the previous
> 42 presidencies and you had an explanation why the coin was right,
> then it would be credible and I would be willing to wager that it
> could also predict that the coin could tell us who the 44th president
> would be.  One flip and no explanation is not sufficient.  (And to the
> abstract point, to me that is all knowledge is, some convincing amount
> of examples and a plausible explanation--anyone who thinks they have
> more is appealing to a "knowledge" of the universe that I don't
> accept.)

I used a coin toss; I could also have used a psycic hotline. There
is an explanation for why those things work, but the explanation
is unsound.


> Look at where that got Russell and Whitehead.

Universal acclaim, such that their names will be praised for
centuries to come?


> I'm just trying to be "honest" about that fact and find ways to
> compensate for my own failures.

Limitation != failure.


Marshal

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Termination and type systems

[Marshall]

David Hopwood wrote:
> Marshall wrote:
> > David Hopwood wrote:
> >
> >>A type system that required an annotation on all subprograms that do not
> >>provably terminate, OTOH, would not impact expressiveness at all, and would
> >>be very useful.
> >
> > Interesting. I have always imagined doing this by allowing an
> > annotation on all subprograms that *do* provably terminate. If
> > you go the other way, you have to annotate every function that
> > uses general recursion (or iteration if you swing that way) and that
> > seems like it might be burdensome.
>
> Not at all. Almost all subprograms provably terminate (with a fairly
> easy proof), even if they use general recursion or iteration.

Well, um, hmmm. If a subprogram uses recursion, and it is not
structural recursion, then I don't know how to go about proving
it terminates. Are the proof-termination techniques I don't
know about?

If we can specify a total order on the domain or some
subcomponents of the domain, and show that recursive
calls are always invoked with arguments less than (by
the order) those of the parent call, (and the domain is
well founded) then we have a termination proof.

(If we don't use recursion at all, and we only invoke
proven-terminating functions, same thing; actually
this is a degenerate case of the above.)

For iteration? Okay, a bounded for-loop is probably easy,
but a while loop? What about a function that calculates
the next prime number larger than its argument? Do we
have to embed a proof of an infinity of primes somehow?
That seems burdensome.


> If it were not the case that almost all functions provably terminate,
> then the whole idea would be hopeless.

I agree!


> If a subprogram F calls G, then
> in order to prove that F terminates, we probably have to prove that G
> terminates. Consider a program where only half of all subprograms are
> annotated as provably terminating. In that case, we would be faced with
> very many cases where the proof cannot be discharged, because an
> annotated subprogram calls an unannotated one.

Right, and you'd have to be applying the non-terminating annotation
all over the place.



> If, on the other hand, more than, say, 95% of subprograms provably
> terminate, then it is much more likely that we (or the inference
> mechanism) can easily discharge any particular proof involving more
> than one subprogram. So provably terminating should be the default,
> and other cases should be annotated.

Well, I can still imagine that the programmer doesn't care to have
non-termination examined for every part of his code. In which case,
he would still be required to add annotations even when he doesn't
care about a particular subprograms lack of a termination proof.

The pay-for-it-only-if-you-want-it approach has some benefits.
On the other hand, if it really is as common and easy as you
propose, then annotating only when no proof is available is
perhaps feasible.

I'm still a bit sceptical, though.


> I do not know how well such a type system would work in practice; it may
> be that typical programs would involve too many non-trivial proofs. This
> is something that would have to be tried out in a research language.

Yeah.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Pascal Costanza wrote:
>
> Consider division by zero: appropriate arguments for division are
> numbers, including the zero.

A bold assertion!

The general question is, what do we do about partial functions?


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

This is an implementation artifact, and hence not relevant to our
understanding of the issue.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

George Neuner wrote:
>
> 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.  All it knows is
> that a floating point value is being truncated and the stupid
> programmer wants to stick the result into some type too narrow to
> represent the range of possible values.
>
> Like I said to Ben, I haven't seen any _practical_ static type system
> that can deal with things like this.  Writing a generic function is
> impossible under the circumstances, and writing a separate function
> for each narrow type is ridiculous and a maintenance nightmare even if
> they can share the bulk of the code.

This is the partial function question again, in a different guise.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Chris F Clark 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.  I expect that some
> programs have type signatures that exceed the expressibility of any
> static system (that is Turing complete).  Therefore, we need something
> that "computes" the appropriate type at run-time, because we need full
> Turing power to compute it.  To me such a system is a "dynamic type
> system".  I think dynamic tags are a good approximation, because they
> only compute what type the expression has this time.

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.

Frankly, if the *only* issue between static and dynamic was
the static checking of the types, then static typing woud
unquestionably be superior. But that's not the only issue.
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.)

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.


> Perhaps, there is no such beast.  Or, perhaps I just can't formulate
> it.  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.

The C++ type system is Turing complete, although in practical terms
it limits how much processing power it will spend on types at
compile time.


> If you allow Turing Complete type systems, then I would say no--every
> bug can be reforumlated as a type error.  If you require your type
> system to be less powerful, then some bugs must escape it.

I don't think so. Even with a Turing complete type system, a program's
runtime behavior is still something different from its static behavior.
(This is the other side of the "types are not tags" issue--not only
is it the case that there are things static types can do that tags
can't, it is also the case that there are things tags can do that
static types can't.)


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Ketil Malde wrote:
> "Marshall" <[EMAIL PROTECTED]> writes:
>
> > 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 keep hearing this, but I guess I fail to understand it.  How
> "partly-wrong" do you require the program to be?
>
> During development, I frequently sprinkle my (Haskell) program with
> 'undefined' and 'error "implement later"' - which then lets me run the
> implemented parts until execution hits one of the 'undefined's.
>
> The "cost" of static typing for running an incomplete program is thus
> simply that I have to name entities I refer to.  I'd argue that this
> is good practice anyway, since it's easy to see what remains to be
> done. (Python doesn't seem to, but presumably a serious dynamically
> typed system would warn about references to entities not in scope?)

I'll give you my understanding of it, but bear in mind that I only
program
in statically typed languages, and I in fact do exactly what you
decribe
above: stub out unimplemented methods.

The issue is that, while stubbing out things may not be expensive,
it is not free either. There is some mental switching cost to being
in a state where one writes some code, wants to execute it, but
can't, because of type system constraints that are globally applicable
but not locally applicable to the task at hand, or to the specific
subprogram one is working on right at that moment.

Since I'm very used to doing it, it doesn't seem like an issue to
me, but programmers in dynamical languages complain bitterly
about this. It is my feeling that programming languages should
try to be inclusive, and since this feature is easily enough
accomodated, (as a 'lenient' switch to execution) it ought
to be.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

David Hopwood wrote:
> Marshall wrote:
> > The real question is, are there some programs that we
> > can't write *at all* in a statically typed language, because
> > they'll *never* be typable?
>
> In a statically typed language that has a "dynamic" type, all
> dynamically typed programs are straightforwardly expressible.

So, how does this "dynamic" type work? It can't simply be
the "any" type, because that type has no/few functions defined
on it. It strikes me that *when* exactly binding happens will
matter. In a statically typed language, it may be that all
binding occurs at compile time, and in a dynamic language,
it may be that all binding occurs at runtime. So you might
have to change the binding mechanism as well. Does the
"dynamic" type allow this?

 
Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

David Hopwood wrote:
> Marshall wrote:
> > David Hopwood wrote:
> >>Marshall wrote:
> >>
> >>>The real question is, are there some programs that we
> >>>can't write *at all* in a statically typed language, because
> >>>they'll *never* be typable?
> >>
> >>In a statically typed language that has a "dynamic" type, all
> >>dynamically typed programs are straightforwardly expressible.
> >
> > So, how does this "dynamic" type work?
>
> <http://citeseer.ist.psu.edu/abadi89dynamic.html>
>
> > It can't simply be the "any" type, because that type has no/few
> > functions defined on it.
>
> It isn't. From the abstract of the above paper:
>
>   [...] even in statically typed languages, there is often the need to
>   deal with data whose type cannot be determined at compile time. To handle
>   such situations safely, we propose to add a type Dynamic whose values are
>   pairs of a value v and a type tag T where v has the type denoted by T.
>   Instances of Dynamic are built with an explicit tagging construct and
>   inspected with a type safe typecase construct.

Well, all this says is that the type "dynamic" is a way to explicitly
indicate the inclusion of rtti. But that doesn't address my objection;
if a typesafe typecase construct is required, it's not like using
a dynamic language. They don't require typecase to inspect values
before one can, say, invoke a function.


> "Gradual typing" as described in
> <http://www.cs.rice.edu/~jgs3847/pubs/pubs/2006/siek06:_gradual.pdf> is
> another alternative. The difference between gradual typing and a
> "dynamic" type is one of convenience rather than expressiveness --
> gradual typing does not require explicit tagging and typecase constructs.

Perhaps this is the one I should read; it sounds closer to what I'm
talking about.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Joe Marshall wrote:
> Marshall wrote:
> >
> > Yes, an important question (IMHO the *more* important question
> > than the terminology) is what *programs* do we give up if we
> > wish to use static typing? I have never been able to pin this
> > one down at all.
>
> It would depend on the type system, naturally.

Naturally!


> It isn't clear to me which programs we would have to give up, either.
> I don't have much experience in sophisticated typed languages.  It is
> rather easy to find programs that baffle an unsophisticated typed
> language (C, C++, Java, etc.).

C and Java, certainly, but I'm wary these days about making
any statement about limitations on C++'s type system, for it is
subtle and quick to anger.


> Looking back in comp.lang.lisp, I see these examples:
>
> (defun noisy-apply (f arglist)
>   (format t "I am now about to apply ~s to ~s" f arglist)
>   (apply f arglist))
>
> (defun blackhole (argument)
>   (declare (ignore argument))
>   #'blackhole)
>
> But wait a sec.  It seems that these were examples I invented in
> response to the same question from you!

Ah, how well I remember that thread, and how little I got from it.

My memories of that thread are
1) the troll who claimed that Java was unable to read two numbers from
standard input and add them together.
2) The fact that all the smart people agreed the blackhole
function indicated something profound.
3) The fact that I didn't understand the black hole function.

The noisy-apply function I think I understand; it's generic on the
entire arglist. In fact, if I read it correctly, it's even generic
on the *arity* of the function, which is actually pretty impressive.
True? This is an issue I've been wrestling with in my own type
system investigations: how to address genericity across arity.

Does noisy-apply get invoked the same way as other functions?
That would be cool.

As to the black hole function, could you explain it a bit? I apologize
for my lisp-ignorance. I am sure there is a world of significance
in the # ' on the third line, but I have no idea what it is.


> > > If you allow Turing Complete type systems, then I would say no--every
> > > bug can be reforumlated as a type error.  If you require your type
> > > system to be less powerful, then some bugs must escape it.
> >
> > I don't think so. Even with a Turing complete type system, a program's
> > runtime behavior is still something different from its static behavior.
> > (This is the other side of the "types are not tags" issue--not only
> > is it the case that there are things static types can do that tags
> > can't, it is also the case that there are things tags can do that
> > static types can't.)
>
> I agree.  The point of static checking is to *not* run the program.  If
> the type system gets too complicated, it may be a de-facto interpreter.

Aha! A lightbulb just want off.

Consider that a program is a function parameterized on its input.
Static
analysis is exactly the field of what we can say about a program
without
know the values of its parameters.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is Expressiveness in a Computer Language

[Marshall]

Matthias Blume wrote:
>
> How does this "create" such a problem?  The problem is there in either
> approach.  In fact, I believe that the best chance we have of
> addressing the problem is by adopting the "replace the code" model
> along with a "translate the data where necessary at the time of
> replacement".  Translating the data, i.e., re-establishing the
> invariants expected by the updated/replaced code, seems much harder
> (to me) in the case of self-modifying code.  Erlang got this one
> right.

Pardon my ignorance, but what is the Erlang solution to this problem?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Chris Smith wrote:
>
> [...] static typing does ... doesn't imply any constraints on the kind
> of behavioral property that's being checked; but only on the way that
> the check occurs.

Nice post.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

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!

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.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Chris Smith schrieb:
> > 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: [...] (c) invent some kind of generic
> > constraint language so that constraints like this could be expressed
> > without exposing field names. [...] Choice (c), though, looks a
> > little daunting.
>
> That's not too difficult.
> Start with boolean expressions.
> If you need to check everything statically, add enough constraints that
> they become decidable.

I'm not sure I understand. Could you elaborate?


> For the type language, you also need to add primitives for type
> checking, and if the language is stateful, you'll also want primitives
> for accessing earlier states (most notably at function entry).

Again I'm not entirely clear what this means. Are you talking
about pre/post conditions, or are you talking about having the
constraint language itself be something other than functional?


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Chris Smith wrote:
> 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.

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?


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

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. (The "exposing
the interface" issue is a non-issue, because we're exposing some
interface or another no matter what.) The issue is controlling the
values, and that is better handled with a declarative constraint
language. The specific value in the fields aren't known until
runtime.

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?


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

There's some significant questions in my mind about how much of
a constraint language would be static and how much would be
runtime checks. Over time, I'm starting to feel like it should be
mostly runtime, and only occasionally moving into compile time
at specific programmer request. The decidability issue comes up.

Anyone else?


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

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.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

David Hopwood wrote:
> Jürgen Exner wrote:
> > David Hopwood wrote:
> > [...]
> >
> > There is no such error message listed in 'perldoc perldiag'.
> > Please quote the actual text of your error message and include the program
> > that produced this error.
> > Then people here in CLPM may be able to assist you.
>
> Yes, I'm well aware that most of this thread has been off-topic for c.l.p.m,
> but it is no less off-topic for the other groups (except possibly 
> c.l.functional),
> and I can't trim the Newsgroups line down to nothing.
>
> Don't you have a newsreader that can mark whole threads that you don't want
> to read?

Sure, or he could just skip over it. Or he could make a simple
request, such as "please trim comp.lang.whatever because it's
off-topic here." But he hasn't done any of these, choosing instead
to drop in with his occasional pointless snarky comments.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

Joachim Durchholz wrote:
> Marshall schrieb:
> > Joachim Durchholz wrote:
> >> Chris Smith schrieb:
> >>> 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: [...] (c) invent some kind of generic
> >>> constraint language so that constraints like this could be expressed
> >>> without exposing field names. [...] Choice (c), though, looks a
> >>> little daunting.
> >> That's not too difficult.
> >> Start with boolean expressions.
> >> If you need to check everything statically, add enough constraints that
> >> they become decidable.
> >
> > I'm not sure I understand. Could you elaborate?
>
> Preconditions/postconditions can express anything you want, and they are
> an absolutely natural extensions of what's commonly called a type
> (actually the more powerful type systems have quite a broad overlap with
> assertions).
> I'd essentially want to have an assertion language, with primitives for
> type expressions.

Now, I'm not fully up to speed on DBC. The contract specifications,
these are specified statically, but checked dynamically, is that
right? In other words, we can consider contracts in light of
inheritance, but the actual verification and checking happens
at runtime, yes?

Wouldn't it be possible to do them at compile time? (Although
this raises decidability issues.) Mightn't it also be possible to
leave it up to the programmer whether a given contract
was compile-time or runtime?

I've been wondering about this for a while.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What is a type error?

[Marshall]

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.


Marshall

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Secure Postgres access

[Marshall]

Can't you limit SSH tunneling access to the IP and/or MAC that you want
to access ? It's simplest than any other solution.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Python for IPSA (Power flow analysis)

[Robert Marshall]

On Tue, May 28 2013, Debbie  wrote:

> Hi there, I am new to Python, and wondering if you could help me with
> python based coding for the IPSA (Power system analysis software). I
> have a electrical distribution network with generators, buses and
> loads, on which I am performing the load flow analysis every 1 hour
> for a period of 1 year.
>
> The code to perform instantaneous load/power flow analysis is given
> below. I need to modify it such that I can perform this load flow
> analysis every 1 hour for a period of 1 year. Please help.
>
> from ipsa import *
>
> ipsasys = IscInterface()
> net = ipsasys.ReadFile("refinery.iif")
> bok = net.DoLoadFlow();
> if bok:
> busbars = net.GetBusbars()
...
> for bus in busbars.itervalues():
> name = bus.GetName()
..
> else:
> print "Load Flow failed!"
>

I think Dave's suggestions are useful, a few years ago I was one of the
developers for the IPSA python API, I'm not sure how things have moved
on since then but you need somewhere to incorporate some time modelling
- at the moment I'm not sure how and if that was done. In any case I
doubt if the simulation would give rigourous results over a simulation
period of that length

Is what you really have  a set of iif files with current voltages over a
set of periods within that year, if so you need to iterate though those,
loading each one and doing individual load flows.

IPSA has a linkedin discussion group and current IPSA developers will I
think respond to you there (if you have an account)

Robert
-- 
La grenouille songe..dans son château d'eau
Links and things http://rmstar.blogspot.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Ideal way to separate GUI and logic?

[Owen Marshall]

On 2013-07-16, fronag...@gmail.com  wrote:
> On Tuesday, July 16, 2013 1:06:30 AM UTC+8, asim...@gmail.com wrote:
>> fron...@gmail.com wrote:
>>
>> > So as a general idea, I should at the very least separate the GUI
>> > from the program logic by defining the logic as a function,
>> > correct? And the next level of separation is to define the logic as
>> > a class in one or more separate files, and then import it to the
>> > file with the GUI, correct?
>>
>> >
>>
>> > My next question is, to what degree should I 'slice' my logic into
>> > functions? How small or how large should one function be, as a rule
>> > of thumb?
>>
>>
>>
>> The way I do this is to write unit tests against the class and the
>> functions (take a look at the unittest module). The functions methods
>> (take a look at the unittest module). Each function should contain
>> the smallest bit of testable logic.
>>
>>
>>
>> Another way to think about this is that each function should contain
>> the smallest piece of logic that you can describe as one action.
>>
>>
>>
>> -
>>
>> Asim Jalis
>
> Again, thanks for all the responses. I'm curious, though, what exactly
> is the rationale for making functions so small? (I've heard that the
> function calling of Python has relatively high overhead?)

Small functions are _always_ encouraged for every language. This is best
practice for everything, not just Python. Has nothing to do with
overhead.

--
-owen
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: UTF-EBCDIC encoding?

[Owen Marshall]

On 2013-07-12, Joel Goldstick  wrote:
> --047d7bdc8be492d67804e154c580 Content-Type: text/plain; charset=UTF-8
>
> On Fri, Jul 12, 2013 at 2:11 PM, Wayne Werner 
> wrote:
>
>> Is anyone aware of a UTF-EBCDIC[1] decoder?
>>
>> While Python does have a few EBCDIC dialects in the codecs, it does
>> not have the (relatively new?) UTF-EBCDIC one.
>>
>> Additionally, if anyone is aware of a Python tool that can unpack a
>> mainframe PDS file, that would also be worthwhile.
>>
>>
>> Thanks, Wayne
>>
>> [1]:
>> https://en.wikipedia.org/wiki/**UTF-EBCDIC
>> --
>> http://mail.python.org/**mailman/listinfo/python-list
>>
>
>
> I can't help you.  I'm astonished.  Trying to imagine the work
> environment where this technology would be necessary
>

Ask any poor shmuck who has ever had to consume files created by the
government -- especially stuff from the Social Security Administration
-- and they'll tell horror stories about EBCDIC.

Typically I've seen ``iconv'' used for this task, so I'd love to see a
native solution...

--
-owen
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What does it take to implement a chat system in Python (Not asking for code just advice before I start my little project)

[Owen Marshall]

On 2013-07-18, Grant Edwards  wrote:
> On 2013-07-18, Serhiy Storchaka  wrote:
>> 18.07.13 20:04, Terry Reedy ??():
>>> On 7/18/2013 3:29 AM, Aseem Bansal wrote:
 About reading comp.lang.python can you suggest how to read it and
 reply?
>>>
>>> To read this list as a newsgroup use news.gmane.org. The difference
>>> between the mailing list interface and newsgroup interface is that the
>>> latter automatically segregates messages by group and only downloads the
>>> messages you want to read. Gmane is also a better way to search the
>>> archive.
>>
>> Also newsgroup interface allow you reply to messages that have already
>> been posted before your subscription.
>
> Indeed.  I read about 20 mailing lists by pointing a newsreader (I use
> slrn) at gmane.org.  I find it to take far less effort than actualling
> having all of those messages actually sent to me.  For _some_ of the
> gmane groups/lists you will actually have to subscribe to the mailing
> list in question if you want to be allowed to post messages -- but in
> your account settings for that mailing list server you can turn off
> delivery, so that it doesn't actually send you any of the postings.
>
> I really can't recommend gmane.org highly enough.
>
> [I don't actually read the python list using gmane.org, since I've
> read it from a Usenet news server via the group comp.lang.python since
> long before I discovered gmane.org.]
>

Huh - I (foolishly) didn't realize gmane actually had NNTP, I've always
used it to search mailing lists. If the list dumped to usenet (much like
c.l.python) I'd post through sunsite.dk, which is a very nice usenet
provider. But that still meant several annoying mailing list
subscriptions.

... man, I'm really glad I read your post :-)

--
  -owen
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: What does it take to implement a chat system in Python (Not asking for code just advice before I start my little project)

[Owen Marshall]

On 2013-07-18, Michael Torrie  wrote:
> On 07/18/2013 12:19 PM, Owen Marshall wrote:
>> Huh - I (foolishly) didn't realize gmane actually had NNTP, I've always
>> used it to search mailing lists. If the list dumped to usenet (much like
>> c.l.python) I'd post through sunsite.dk, which is a very nice usenet
>> provider. But that still meant several annoying mailing list
>> subscriptions.
>>
>> ... man, I'm really glad I read your post :-)
>
> I'm a bit confused.  This list *is* c.l.python (I happen to read via
> e-mail through the mailing list).  So you can reach it from sunsite.dk
> can you not?

Doesn't surprise me, I was confusing ;-)

What I was saying was that my workflow used to be this:

For maliing lists that dump to a newsgroup (c.l.python) I'd post to the
group via usenet (sunsite.dk)

For mailing lists that _do not_ have a direct newsgroup gateway (flask,
etc.) I'd have to subscribe and read them in my mail client.


So I used to think gmane was just a way of reading a bunch of mailing
lists. *But now* I know it is much more - it's an NNTP <==> mail gateway
that also has a web viewer.

Now I can point my slrn to news.gmane.net and see the flask mailing
list, ruby-talk, ... -- which I much prefer to using email.


Again, perfectly obvious stuff had I actually _read_ the gmane FAQ. But
who has time for that ;-)

--
  -owen
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: OT: Text editors

[Robert Marshall]

On Sun, 29 Jul 2012, python.l...@tim.thechases.com wrote:

> On 07/29/12 05:28, Mark Lawrence wrote:
>> On 29/07/2012 06:08, Ben Finney wrote:
>>> Tim Chase  writes:
>>> Learn one of Emacs or Vim well, and you won't need to worry
>>> about text editors again.
>> 
>> Point taken, snag being I've never used any nix box in anger.
>> This thread reminds of the good 'ole days when I were a lad using
>> TPU on VMS. Have we got any VMS aficionados here?
> 
> Though I'm personally far more vitriolic about VMS vs $OS (had a few
> souring experiences with VMS in college) than I am regarding Vim vs.
> Emacs, you can get Vim for at least OpenVMS:
> 
> http://www.vim.org/download.php#others
> 
> I presume sources compile fairly well on other flavors of VMS if
> needed, and I'd expect Emacs can do likewise[1]
> 

I used to use tpu (used to have piles of tpu macros..) and I first got used
to emacs by using its tpu mode - I see that still exists so you can use
emacs and pretend it is really tpu!

Robert
-- 
La grenouille songe..dans son château d'eau
Links and things http://rmstar.blogspot.com/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [pyxl] xlrd 0.8.0 released!

[Brent Marshall]

My compliments to John and Chris and to any others who contributed to the 
new xlsx capability. This is a most welcome development. Thank you.

Brent
-- 
http://mail.python.org/mailman/listinfo/python-list

OT: Code Examples

[Fred Marshall]

I'm interested in developing Python-based programs, including an 
engineering app. ... re-writing from Fortran and C versions.  One of the 
objectives would to be make reasonable use of the available structure 
(objects, etc.).  So, I'd like to read a couple of good, simple 
scientific-oriented programs that do that kind of thing.


Looking for links, etc.

Fred
--
http://mail.python.org/mailman/listinfo/python-list

Re: OT: Code Examples

[Fred Marshall]

On 2/28/2011 8:14 AM, n00m wrote:

On Feb 28, 6:03 pm, Fred Marshall
wrote:



The best place for you to start: http://numpy.scipy.org/

Numpy manual: http://www.tramy.us/numpybook.pdf


OK Thanks!

Fred

--
http://mail.python.org/mailman/listinfo/python-list