Re: What is Expressiveness in a Computer Language
Andreas Rossberg <[EMAIL PROTECTED]> writes: >> "A language is latently typed if a value has a property - called it's >> type - attached to it, and given it's type it can only represent values >> defined by a certain class." I thought the point was to separate the (bitwise) representation of a value from its interpretation (which is its type). In a static system, the interpretation is derived from context, in a dynamic system values must carry some form of tags specifying which interpretation to use. I think this applies - conceptually, at least - also to expressions? My impression is that dynamic typers tend to include more general properties in their concept of types (div by zero, srqt of negatives, etc). -k -- If I haven't seen further, it is by standing in the footprints of giants -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
"Rob Thorpe" <[EMAIL PROTECTED]> writes: > But it only gaurantees this because the variables themselves have a > type, the values themselves do not. I think statements like this are confusing, because there are different interpretations of what a "value" is. I would say that the integer '4' is a value, and that it has type Integer (for instance). This value is different from 4 the Int16, or 4 the double-precision floating point number. From this viewpoint, all values in statically typed languages have types, but I think you use 'value' to denote the representation of a datum in memory, which is a different thing. -k -- If I haven't seen further, it is by standing in the footprints of giants -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
"Rob Thorpe" <[EMAIL PROTECTED]> writes: >> I think statements like this are confusing, because there are >> different interpretations of what a "value" is. > But I mean the value as the semantics of the program itself sees it. > Which mostly means the datum in memory. I don't agree with that. Generally, a language specifies a virtual machine and doesn't need to concern itself with things like "memory" at all. Although langauges like C tries to, look at all the undefined behavior you get when you make assumptions about memory layout etc. Memory representation is just an artifact of a particular implementation of the language for a particular architecture. -k -- If I haven't seen further, it is by standing in the footprints of giants -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris Smith <[EMAIL PROTECTED]> writes: > I've since abandoned any attempt to be picky about use of the word > "type". That was a mistake on my part. I still think it's legitimate > to object to statements of the form "statically typed languages X, but > dynamically typed languages Y", in which it is implied that Y is > distinct from X. When I used the word "type" above, I was adopting the > working definition of a type from the dynamic sense. Umm...what *is* the definition of a "dynamic type"? In this thread it's been argued from tags and memory representation to (almost?) arbitrary predicates. > 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. Well, if you equate tags with dynamic types: data Universal = Str String | Int Integer | Real Double | List [Universal] ... A pattern match failure can then be seen as a dynamic type error. Another question is how to treat a system (and I think C++'s RTTI qualifies, and probably related languages like Java) where static type information is available at runtime. Does this fit with the term "dynamic typing" with "typing" in the same sense as "static typing"? -k -- If I haven't seen further, it is by standing in the footprints of giants -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris Smith <[EMAIL PROTECTED]> writes:
> Joachim Durchholz <[EMAIL PROTECTED]> wrote:
>> Assume a language that
>> a) defines that a program is "type-correct" iff HM inference establishes
>> that there are no type errors
>> b) compiles a type-incorrect program anyway, with an establishes
>> rigorous semantics for such programs (e.g. by throwing exceptions as
>> appropriate).
> So the compiler now attempts to prove theorems about the program, but
> once it has done so it uses the results merely to optimize its runtime
> behavior and then throws the results away.
Hmm... here's my compiler front end (for Haskell or other languages
that ..er.. define 'undefined'):
while(type error) {
replace an incorrectly typed function with 'undefined'
}
Wouldn't the resulting program still be statically typed?
In practice I prefer to (and do) define troublesome functions as
'undefined' manually during development.
-k
--
If I haven't seen further, it is by standing in the footprints of giants
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Anton van Straaten <[EMAIL PROTECTED]> writes: > But a program as seen by the programmer has types: the programmer > performs (static) type inference when reasoning about the program, and > debugs those inferences when debugging the program, finally ending up > with a program which has a perfectly good type scheme. I'd be tempted to go further, and say that the programmer performs (informally, incompletely, and probably incorrectly ) a proof of correctness, and that type correctness is just a part of general correctness. -k -- If I haven't seen further, it is by standing in the footprints of giants -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
"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?) -k -- If I haven't seen further, it is by standing in the footprints of giants -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
[EMAIL PROTECTED] (Alex Martelli) writes: >> Any time you want an anonymous function (or class, or type, or number) >> it would be because that thing is sufficiently small and simple that the >> best name for it is the code itself. > In the real world, people don't choose anonymous functions only in > these alleged cases where anonymous is best In the real world, people do a lot of things they shouldn't. Any feature can be abused, and poor style is possible in any language. I just checked my code for lambdas, and they are exclusively short half-liners passed as parameters to higher order functions. Naming them would only complicate the code, just like naming (other) intermediate results would. > if anonymous functions are available, they're used in even more > cases where naming would help Perhps, but not necessarily. But how about the converse: if every function must be named, they will be named even where naming them hurts. -k -- If I haven't seen further, it is by standing in the footprints of giants -- http://mail.python.org/mailman/listinfo/python-list
Re: A critic of Guido's blog on Python's lambda
[EMAIL PROTECTED] (Alex Martelli) writes: > But if we can agree to name every function except continuations I'll be > content FWIW, I disagree: A simple example, doubling each entry in a list: map (*2) xs vs. let double x = x*2 in map double xs Here's another example, extracting all lines that contain at least one word: filter (not.null) . map words . lines Note that I'm using the following anonymous functions: not . null filter (not . null) map words filter (not.null) . map words Would it really improve anything if I named these? It seems incredibly pedestrian, along the lines of requiring a comments for every source line: x++; /* increase x by one */ a[x] = ' '; /* insert a space in a at position x */ Sometimes the best documentation is the code itself. Sometimes the best name for a function is the code itself. -k -- If I haven't seen further, it is by standing in the footprints of giants -- http://mail.python.org/mailman/listinfo/python-list
