Re: multi-core software
Jeff M. mass...@gmail.com writes: On Jun 9, 9:08 pm, Arved Sandstrom dces...@hotmail.com wrote: Jon Harrop wrote: Arved Sandstrom wrote: Jon, I do concurrent programming all the time, as do most of my peers. Way down on the list of why we do it is the reduction of latency. What is higher on the list? Correctness. IMO, that response is a bit of a cop-out. Correctness is _always_ most important, no matter what application you are creating; without it, you don't have a job and the company you work for goes out of business. But, assuming that your program works and does what it's supposed to, I agree with Jon that performance needs to be right near the top of the list of concerns. Why? Performance isn't about looking good as a programmer, or having fun making a function run in 15 cycles instead of 24, or coming up with some neat bit packing scheme so that your app now only uses 20K instead of 200K. Performance is - pure and simple - about one thing only: money. Programmer time is vastly more expensive than CPU time, so the money argument often leads to slow (low performance) solutions as long as they are good enough because developing a faster solution would mean spending more valuable programmer time at a cost that cannot be recovered over the life cycle of the product in question. That being said, there are plenty of situations where performance obviously does matter a great deal -- as you correctly pointed out. (It all depends on the above mentioned product in question and the nature of its life cycle.) Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
. [EMAIL PROTECTED] writes: On Tue, 09 Oct 2007 05:15:49 +, gnuist006 wrote: Again I am depressed to encounter a fundamentally new concept that I was all along unheard of. Its not even in paul graham's book where i learnt part of Lisp. Its in Marc Feeley's video. Can anyone explain: (1) its origin One of the lambda papers, I think. I don't remember which. This is a common misconception. There is very little that originated from the lambda papers. But they did a marvelous job at promoting some of the ideas that existed in the PL community for years. As for the concept of continuations, there is Scott and Strachey's work on denotational semantics, and there is Landin's J operator. (There's probably more that I am forgetting right now.) (6) any good readable references that explain it lucidly ? One of the most lucid explanations of definitional interpreters -- including those that are based on continuation-passing -- are explained in J. Reynolds' famous 1971 Definitional Interpreters for Higher-Order Functions paper. (It has been re-published in 1998 in HOSC.) The paper also explains how to perform defunctionalization, which can be seen as a way to compile (and even hand-compile) higher-order programs. Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: The fundamental concept of continuations
[EMAIL PROTECTED] writes: Matthias, thanks for the reference, but I dont have access to an engineering library. I would appreciate, if you have access to paper/ scanner or electronic copy to help many of us out, you are not just helping me but many will thank you. Given that you seem to be hanging out at the internets, I expect you do know how to use the google... -- http://mail.python.org/mailman/listinfo/python-list
Re: languages with full unicode support
Oliver Bandel [EMAIL PROTECTED] writes: Oliver Bandel wrote: こんいちわ Xah-Lee san ;-) Uhm, I'd guess that Xah is Chinese. Be careful with such things in real life; Koreans might beat you up for this. Stay alive! And the Japanese might beat him up, too. For butchering their language. :-) OK, back to ISO-8859-1 :) no one needs so much symbols, this is enough: äöüÄÖÜß :) There are plenty of people who need such symbols (more people than those who need ß, btw). Matthias PS: It should have been こんにちは. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Costanza [EMAIL PROTECTED] writes: Whether you consider something you cannot do with statically typed languages a bad idea or not is irrelevant. You were asking for things that you cannot do with statically typed languages. The whole point of static type systems is to make sure that there are things that one cannot do. So the fact that there are such things are not an argument per se against static types. [ ... ] Beyond that, I am convinced that the ability to update a running system without the need to shut it down can be an important asset. And I am convinced that updating a running system in the style of, e.g., Erlang, can be statically typed. Note that prohibiting directly self-modifying code does not prevent a program from specifying another program to *replace* it. ...and this creates problems with moving data from one version of a program to the next. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Costanza [EMAIL PROTECTED] writes: And I am convinced that updating a running system in the style of, e.g., Erlang, can be statically typed. Maybe. The interesting question then is whether you can express the kinds of dynamic updates that are relevant in practice. Because a static type system always restricts what kinds of runtime behavior you can express in your language. I am still skeptical, because changing the types at runtime is basically changing the assumptions that the static type checker has used to check the program's types in the first place. That's why I find the Erlang model to be more promising. I am extremely skeptical of code mutation at runtime which would change types, because to me types are approximations of program invariants. So if you do a modification that changes the types, it is rather likely that you did something that also changed the invariants, and existing code relying on those invariants will now break. For example, all the approaches that I have seen in statically typed languages deal with adding to a running program (say, class fields and methods, etc.), but not with changing to, or removing from it. Of course, there are good reasons for that: removing fields or changing their invariants requires that all /deployed/ code which relied on their existence or their invariants must be made aware of this change. This is a semantic problem which happens to reveal itself as a typing problem. By making types dynamic, the problem does not go away but is merely swept under the rug. Note that prohibiting directly self-modifying code does not prevent a program from specifying another program to *replace* it. ...and this creates problems with moving data from one version of a program to the next. 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. ...and the translate the date where necessary approach is essentially triggered by a dynamic type test (if value x is of an old version of type T, update it to reflect the new version of type T [1]). QED. But this test would have to already exist in code that was deployed /before/ the change! How did this code know what to test for, and how did it know how to translate the data? Plus, how do you detect that some piece of data is of an old version of type T? If v has type T and T changes (whatever that might mean), how can you tell that v's type is the old T rather than the new T! Are there two different Ts around now? If so, how can you say that T has changed? The bottom line is that even the concept of changing types at runtime makes little sense. Until someone shows me a /careful/ formalization that actually works, I just can't take it very seriously. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall [EMAIL PROTECTED] writes: 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? Erlang relies on a combination of purity, concurrency, and message passing, where messages can carry higher-order values. Data structures are immutable, and each computational agent is a thread. Most threads consist a loop that explicitly passes state around. It dispatches on some input event, applies a state transformer (which is a pure function), produces some output event (if necessary), and goes back to the beginning of the loop (by tail-calling itself) with the new state. When a code update is necessary, a special event is sent to the thread, passing along the new code to be executed. The old code, upon receiving such an event, ceases to go back to its own loop entry point (by simply not performing the self-tail-call). Instead it tail-calls the new code with the current state. If the new code can live with the same data structures that the old code had, then it can directly proceed to perform real work. If new invariants are to be established, it can first run a translation function on the current state before resuming operation. From what I hear from the Erlang folks that I have talked to, this approach works extremely well in practice. -- http://mail.python.org/mailman/listinfo/python-list
Re: languages with full unicode support
Tin Gherdanarra [EMAIL PROTECTED] writes: Oliver Bandel wrote: こんいちわ Xah-Lee san ;-) Uhm, I'd guess that Xah is Chinese. Be careful with such things in real life; Koreans might beat you up for this. Stay alive! And the Japanese might beat him up, too. For butchering their language. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language [off-topic]
David Hopwood [EMAIL PROTECTED] writes: Matthias Blume wrote: I agree with Bob Harper about safety being language-specific and all that. But, with all due respect, I think his characterization of C is not accurate. [...] AFAIC, C is C-unsafe by Bob's reasoning. Agreed. Of course, C can be made safe quite easily: Define a state undefined that is considered safe and add a transition to undefined wherever necessary. I wouldn't say that was quite easy at all. C99 4 #2: # If a shall or shall not requirement that appears outside of a constraint # is violated, the behavior is undefined. Undefined behavior is otherwise # indicated in this International Standard by the words undefined behavior # *or by the omission of any explicit definition of behavior*. [...] In other words, to fix C to be a safe language (compatible with Standard C89 or C99), you first have to resolve all the ambiguities in the standard where the behaviour is *implicitly* undefined. There are a lot of them. Yes, if you want to make the transition system completely explict, it won't be easy. I was thinking of a catch-all rule that says: transition to undefined unless specified otherwise. (Note that I am not actually advocating this approach to making a language safe. For practical purposes, C is unsafe. (And so is C++.)) -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Gabriel Dos Reis [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] writes:
| think that it is too relevant for the discussion at hand. Moreover,
| Harper talks about a relative concept of C-safety.
Then, I believe you missed the entire point.
First point: safety is a *per-language* property. Each language
comes with its own notion of safety. ML is ML-safe; C is C-safe;
etc. I'm not being facetious; I think this is the core of the
confusion.
Safety is an internal consistency check on the formal definition of
a language. In a sense it is not interesting that a language is
safe, precisely because if it weren't, we'd change the language to
make sure it is! I regard safety as a tool for the language
designer, rather than a criterion with which we can compare
languages.
I agree with Bob Harper about safety being language-specific and all
that. But, with all due respect, I think his characterization of C is
not accurate. In particular, the semantics of C (as specified by the
standard) is *not* just a mapping from memories to memories. Instead,
there are lots of situations that are quite clearly marked in C's
definition as undefined (or whatever the technical term may be). In
other words, C's specified transition system (to the extend that we
can actually call it specified) has lots of places where programs
can get stuck, i.e., where there is no transition to take. Most
actual implementations of C (including Unix) are actually quite
generous by filling in some of the transitions, so that programs that
are officially legal C will run anyway.
Example:
The following program (IIRC) is not legal C, even though I expect it
to run without problem on almost any machine/OS, printing 0 to stdout:
#include stdio.h
int a[] = { 0, 1, 2 };
int main (void)
{
int *p, *q;
p = a;
q = p-1; /** illegal **/
printf(%d\n, q[1]);
return 0;
}
Nevertheless, the line marked with the comment is illegal because it
creates a pointer that is not pointing into a memory object. Still, a
C compiler is not required to reject this program. It is allowed,
though, to make the program behave in unexpected ways. In particular,
you can't really blame the compiler if the program does not print 0,
or if it even crashes.
AFAIC, C is C-unsafe by Bob's reasoning.
---
Of course, C can be made safe quite easily:
Define a state undefined that is considered safe and add a
transition to undefined wherever necessary.
Kind regards,
Matthias
--
http://mail.python.org/mailman/listinfo/python-list
Re: Saying latently-typed language is making a category mistake
David Hopwood [EMAIL PROTECTED] writes: Patricia Shanahan wrote: Vesa Karvonen wrote: ... An example of a form of informal reasoning that (practically) every programmer does daily is termination analysis. There are type systems that guarantee termination, but I think that is fair to say that it is not yet understood how to make a practical general purpose language, whose type system would guarantee termination (or at least I'm not aware of such a language). It should also be clear that termination analysis need not be done informally. Given a program, it may be possible to formally prove that it terminates. To make the halting problem decidable one would have to do one of two things: Depend on memory size limits, or have a language that really is less expressive, at a very deep level, than any of the languages mentioned in the newsgroups header for this message. I don't think Vesa was talking about trying to solve the halting problem. A type system that required termination would indeed significantly restrict language expressiveness -- mainly because many interactive processes are *intended* not to terminate. Most interactive processes are written in such a way that they (effectively) consist of an infinitely repeated application of some function f that maps the current state and the input to the new state and the output. f : state * input - state * output This function f itself has to terminate, i.e., if t has to be guaranteed that after any given input, there will eventually be an output. In most interactive systems the requirements are in fact much stricter: the output should come soon after the input has been received. I am pretty confident that the f for most (if not all) existing interactive systems could be coded in a language that enforces termination. Only the loop that repeatedly applies f would have to be coded in a less restrictive language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying latently-typed language is making a category mistake
Pascal Costanza [EMAIL PROTECTED] writes: Patricia Shanahan wrote: Vesa Karvonen wrote: ... An example of a form of informal reasoning that (practically) every programmer does daily is termination analysis. There are type systems that guarantee termination, but I think that is fair to say that it is not yet understood how to make a practical general purpose language, whose type system would guarantee termination (or at least I'm not aware of such a language). It should also be clear that termination analysis need not be done informally. Given a program, it may be possible to formally prove that it terminates. To make the halting problem decidable one would have to do one of two things: Depend on memory size limits, or have a language that really is less expressive, at a very deep level, than any of the languages mentioned in the newsgroups header for this message. Not quite. See http://en.wikipedia.org/wiki/ACL2 What do you mean not quite? Of course, Patricia is absolutely right. Termination-guaranteeing languages are fundamentally less expressive than Turing-complete languages. ACL2 was not mentioned in the newsgroup header. -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying latently-typed language is making a category mistake
Pascal Costanza [EMAIL PROTECTED] writes: Matthias Blume wrote: Pascal Costanza [EMAIL PROTECTED] writes: Patricia Shanahan wrote: Vesa Karvonen wrote: ... An example of a form of informal reasoning that (practically) every programmer does daily is termination analysis. There are type systems that guarantee termination, but I think that is fair to say that it is not yet understood how to make a practical general purpose language, whose type system would guarantee termination (or at least I'm not aware of such a language). It should also be clear that termination analysis need not be done informally. Given a program, it may be possible to formally prove that it terminates. To make the halting problem decidable one would have to do one of two things: Depend on memory size limits, or have a language that really is less expressive, at a very deep level, than any of the languages mentioned in the newsgroups header for this message. Not quite. See http://en.wikipedia.org/wiki/ACL2 What do you mean not quite? Of course, Patricia is absolutely right. Termination-guaranteeing languages are fundamentally less expressive than Turing-complete languages. ACL2 was not mentioned in the newsgroup header. ACL2 is a subset of Common Lisp, and programs written in ACL2 are executable in Common Lisp. comp.lang.lisp is not only about Common Lisp, but even if it were, ACL2 would fit. So what? Patricia said less expressive, you said subset. Where is the contradiction? Perhaps you could also bring up the subset of Common Lisp where the only legal program has the form: nil Obviously, this is a subset of Common Lisp and, therefore, fits comp.lang.lisp. Right? Yes, if you restrict the language to make it less expressive, you can guarantee termination. Some restrictions that fit the bill already exist. IMHO, it is still wrong to say that Lisp guaratees termination, just because there is a subset of Lisp that does. Matthias PS: I'm not sure if this language guarantees termination, though. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Bourguignon [EMAIL PROTECTED] writes: Moreover, a good proportion of the program and a good number of algorithms don't even need to know the type of the objects they manipulate. For example, sort doesn't need to know what type the objects it sorts are. It only needs to be given a function that is able to compare the objects. Of course, some statically typed languages handle this sort of thing routinely. Only a few primitive functions need specific types. Your sort function from above also has a specific type -- a type which represents the fact that the objects to be sorted must be acceptable input to the comparison function. So basically, you've got a big black box of applicaition code in the middle that doesn't care what type of value they get, and you've got a few input values of a specific type, a few processing functions needing a specific type and returning a specific type, and a few output values that are expected to be of a specific type. At anytime, you may change the type of the input values, and ensure that the needed processing functions will be able to handle this new input type, and the output gets mapped to the expected type. ...or you type-check your black box and make sure that no matter how you will ever change the type of the inputs (in accordance with the interface type of the box) you get a valid program. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Pascal Costanza [EMAIL PROTECTED] writes: Chris Smith wrote: While this effort to salvage the term type error in dynamic languages is interesting, I fear it will fail. Either we'll all have to admit that type in the dynamic sense is a psychological concept with no precise technical definition (as was at least hinted by Anton's post earlier, whether intentionally or not) or someone is going to have to propose a technical meaning that makes sense, independently of what is meant by type in a static system. What about this: You get a type error when the program attempts to invoke an operation on values that are not appropriate for this operation. Examples: adding numbers to strings; determining the string-length of a number; applying a function on the wrong number of parameters; applying a non-function; accessing an array with out-of-bound indexes; etc. Yes, the phrase runtime type error is actually a misnomer. What one usually means by that is a situation where the operational semantics is stuck, i.e., where the program, while not yet arrived at what's considered a result, cannot make any progress because the current configuration does not match any of the rules of the dynamic semantics. The reason why we call this a type error is that such situations are precisely the ones we want to statically rule out using sound static type systems. So it is a type error in the sense that the static semantics was not strong enough to rule it out. Sending a message to an object that does not understand that message is a type error. The message not understood machinery can be seen either as a way to escape from this type error in case it occurs and allow the program to still do something useful, or to actually remove (some) potential type errors. I disagree with this. If the program keeps running in a defined way, then it is not what I would call a type error. It definitely is not an error in the sense I described above. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Bourguignon [EMAIL PROTECTED] writes: Matthias Blume [EMAIL PROTECTED] writes: Pascal Bourguignon [EMAIL PROTECTED] writes: Moreover, a good proportion of the program and a good number of algorithms don't even need to know the type of the objects they manipulate. For example, sort doesn't need to know what type the objects it sorts are. It only needs to be given a function that is able to compare the objects. Of course, some statically typed languages handle this sort of thing routinely. Only a few primitive functions need specific types. Your sort function from above also has a specific type -- a type which represents the fact that the objects to be sorted must be acceptable input to the comparison function. Well, not exactly. What do you mean by not exactly. sort is a higher level function. The type of its arguments is an implicit parameter of the sort function. What do you mean by higher-level? Maybe you meant higher-order or polymorphic? [ rest snipped ] You might want to look up System F. So basically, you've got a big black box of applicaition code in the middle that doesn't care what type of value they get, and you've got a few input values of a specific type, a few processing functions needing a specific type and returning a specific type, and a few output values that are expected to be of a specific type. At anytime, you may change the type of the input values, and ensure that the needed processing functions will be able to handle this new input type, and the output gets mapped to the expected type. ...or you type-check your black box and make sure that no matter how you will ever change the type of the inputs (in accordance with the interface type of the box) you get a valid program. When? When what? -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Rob Thorpe [EMAIL PROTECTED] writes: Matthias Blume wrote: Rob Thorpe [EMAIL PROTECTED] writes: I think we're discussing this at cross-purposes. In a language like C or another statically typed language there is no information passed with values indicating their type. You seem to be confusing does not have a type with no type information is passed at runtime. Have a look in a C compiler if you don't believe me. Believe me, I have. In a C compiler the compiler has no idea what the values are in the program. It is no different from any other compiler, really. If the compiler sees the literal 1 in a context that demands type int, then it knows perfectly well what value that is. It knows only their type in that it knows the type of the variable they are contained within. Would you agree with that? No it doesn't. Casting reinterprets a value of one type as a value of another type. There is a difference. If I cast an unsigned integer 20 to a signed integer in C on the machine I'm using then the result I will get will not make any sense. Which result are you getting? What does it mean to make sense? Well the right one actually, bad example. But, if I cast an unsigned int 25 to signed I get -1794967296. So, why do you think this does not make sense? And, as this example illustrates, casting in C maps values to values. Depending on the types of the source and the target, a cast might change the underlying representation, or it might leave it the same. But it does produce a value, and the result value is usually not the same as the argument value, even if the representation is the same. Matthias -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Rob Thorpe [EMAIL PROTECTED] writes: No it doesn't. Casting reinterprets a value of one type as a value of another type. There is a difference. If I cast an unsigned integer 20 to a signed integer in C on the machine I'm using then the result I will get will not make any sense. Which result are you getting? What does it mean to make sense? Well the right one actually, bad example. But, if I cast an unsigned int 25 to signed I get -1794967296. So, why do you think this does not make sense? Well, it makes sense in terms of the C spec certainly. It does not make sense in that it does not emit an error. Why not? -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
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. 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. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Darren New [EMAIL PROTECTED] writes: [ ... ] As far as I know, LOTOS is the only language that *actually* uses abstract data types - you have to use the equivalent of #include to bring in the integers, for example. Everything else uses informal rules to say how types work. There are *tons* of languages that actually facilitate abstract data types, and some of these languages are actually used by real people. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Costanza [EMAIL PROTECTED] writes: - In a dynamically typed language, you can run programs successfully that are not acceptable by static type systems. This statement is false. For every program that can run successfully to completion there exists a static type system which accepts that program. Moreover, there is at least one static type system that accepts all such programs. What you mean is that for static type systems that are restrictive enough to be useful in practice there always exist programs which (after type erasure in an untyped setting, i.e., by switching to a different language) would run to completion, but which are rejected by the static type system. By the way, the parenthetical remark is important: If a language's definition is based on a static type system, then there are *no* programs in that language which are rejected by its type checker. That's trivially so because strings that do not type-check are simply not considered programs. Here is an example in Common Lisp: ; A class person with no superclasses and with the only field name: (defclass person () (name)) ; A test program: (defun test () (let ((p (make-instance 'person))) (eval (read)) (slot-value p 'address))) (slot-value p 'address) is an attempt to access the field 'address in the object p. In many languages, the notation for this is p.address. Although the class definition for person doesn't mention the field address, the call to (eval (read)) allows the user to change the definition of the class person and update its existing instances. Therefore at runtime, the call to (slot-value p 'adress) has a chance to succeed. I am quite comfortable with the thought that this sort of evil would get rejected by a statically typed language. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
David Squire [EMAIL PROTECTED] writes: Andreas Rossberg wrote: Rob Thorpe wrote: No, that isn't what I said. What I said was: A language is latently typed if a value has a property - called it's type - attached to it, and given it's type it can only represent values defined by a certain class. it [= a value] [...] can [...] represent values? ??? I just quoted, in condensed form, what you said above: namely, that a value represents values - which I find a strange and circular definition. But you left out the most significant part: given it's type it can only represent values *defined by a certain class* (my emphasis). In C-ish notation: unsigned int x; means that x can only represent elements that are integers elements of the set (class) of values [0, MAX_INT]. Negative numbers and non-integer numbers are excluded, as are all sorts of other things. This x is not a value. It is a name of a memory location. You over-condensed. Andreas condensed correctly. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Rob Thorpe [EMAIL PROTECTED] writes: Andreas Rossberg wrote: Rob Thorpe wrote: No, that isn't what I said. What I said was: A language is latently typed if a value has a property - called it's type - attached to it, and given it's type it can only represent values defined by a certain class. it [= a value] [...] can [...] represent values? ??? I just quoted, in condensed form, what you said above: namely, that a value represents values - which I find a strange and circular definition. Yes, but the point is, as the other poster mentioned: values defined by a class. For example, in lisp: xyz is a string, #(1 2 3) is an array, '(1 2 3) is a list, 45 is a fixed-point number. Each item that can be stored has a type, no item can be stored without one. The types can be tested. Most dynamic typed languages are like that. Your types are just predicates. Compare this to an untyped language where types cannot generally be tested. You mean there are no predicates in untyped languages? They all have - the whole purpose of a type system is to ensure that any expression of type T always evaluates to a value of type T. But it only gaurantees this because the variables themselves have a type, the values themselves do not. Of course they do. Most of the time the fact that the variable they are held in has a type infers that the value does too. But the value itself has no type, in a C program for example I can take the value from some variable and recast it in any way I feel and the language cannot correct any errors I make because their is no information in the variable to indicate what type it is. Casting in C takes values of one type to values of another type. So when you look at type systems formally then you certainly have to assign types to values, otherwise you couldn't prove any useful property about those systems (esp. soundness). Yes, but indirectly. No, this is usually done very directly and very explicitly. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
David Squire [EMAIL PROTECTED] writes: Matthias Blume wrote: David Squire [EMAIL PROTECTED] writes: Andreas Rossberg wrote: Rob Thorpe wrote: No, that isn't what I said. What I said was: A language is latently typed if a value has a property - called it's type - attached to it, and given it's type it can only represent values defined by a certain class. it [= a value] [...] can [...] represent values? ??? I just quoted, in condensed form, what you said above: namely, that a value represents values - which I find a strange and circular definition. But you left out the most significant part: given it's type it can only represent values *defined by a certain class* (my emphasis). In C-ish notation: unsigned int x; means that x can only represent elements that are integers elements of the set (class) of values [0, MAX_INT]. Negative numbers and non-integer numbers are excluded, as are all sorts of other things. This x is not a value. It is a name of a memory location. You over-condensed. Andreas condensed correctly. I should have stayed out of this. I had not realised that it had degenerated to point-scoring off someone typing value when it is clear from context that he meant variable. If he really had meant variable then he would have been completely wrong. Bye. Bye. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Rob Thorpe [EMAIL PROTECTED] writes: I think we're discussing this at cross-purposes. In a language like C or another statically typed language there is no information passed with values indicating their type. You seem to be confusing does not have a type with no type information is passed at runtime. Have a look in a C compiler if you don't believe me. Believe me, I have. No it doesn't. Casting reinterprets a value of one type as a value of another type. There is a difference. If I cast an unsigned integer 20 to a signed integer in C on the machine I'm using then the result I will get will not make any sense. Which result are you getting? What does it mean to make sense? -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Joachim Durchholz [EMAIL PROTECTED] writes: Matthias Blume schrieb: Perhaps better: A language is statically typed if its definition includes (or ever better: is based on) a static type system, i.e., a static semantics with typing judgments derivable by typing rules. Usually typing judgmets associate program phrases (expressions) with types given a typing environment. This is defining a single term (statically typed) using three undefined terms (typing judgements, typing rules, typing environment). This was not meant to be a rigorous definition. Also, I'm not going to repeat the textbook definitions for those three standard terms here. Next thing you are going to ask me to define the meaning of the word is... -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
George Neuner gneuner2/@comcast.net writes: I am, however, going to ask what information you think type inference can provide that substitutes for algorithm or data structure exploration. Nobody wants to do such a substitution, of course. In /my/ experience, however, I find that doing algorithm and data structure exploration is greatly aided by a language with static types and type inference. YMMV. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Rob Thorpe [EMAIL PROTECTED] writes: I don't think dynamic typing is that nebulous. I remember this being discussed elsewhere some time ago, I'll post the same reply I did then .. A language is statically typed if a variable 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. By this definition, all languages are statically typed (by making that certain class the set of all values). Moreover, this definition, when read the way you probably wanted it to be read, requires some considerable stretch to accommodate existing static type systems such as F_\omega. Perhaps better: A language is statically typed if its definition includes (or ever better: is based on) a static type system, i.e., a static semantics with typing judgments derivable by typing rules. Usually typing judgmets associate program phrases (expressions) with types given a typing environment. 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. This definition makes little sense. Any given value can obviously only represent one value: itself. Dynamic types are nothing more than sets of values, often given by computable predicates. Untyped and type-free mean something else: they mean no type checking is done. Look up untyped lambda calculus. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Costanza [EMAIL PROTECTED] writes: Matthias Blume wrote: Rob Thorpe [EMAIL PROTECTED] writes: I don't think dynamic typing is that nebulous. I remember this being discussed elsewhere some time ago, I'll post the same reply I did then .. A language is statically typed if a variable 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. By this definition, all languages are statically typed (by making that certain class the set of all values). Moreover, this definition, when read the way you probably wanted it to be read, requires some considerable stretch to accommodate existing static type systems such as F_\omega. Perhaps better: A language is statically typed if its definition includes (or ever better: is based on) a static type system, i.e., a static semantics with typing judgments derivable by typing rules. Usually typing judgmets associate program phrases (expressions) with types given a typing environment. How does your definition exclude the trivial type system in which the only typing judgment states that every expression is acceptable? It does not. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Darren New [EMAIL PROTECTED] writes: Joachim Durchholz wrote: Give a heterogenous list that would to too awkward to live in a statically-typed language. Printf()? Very good statically typed versions of printf exist. See, e.g., Danvy's unparsing combinators. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Darren New [EMAIL PROTECTED] writes: Matthias Blume wrote: Very good statically typed versions of printf exist. See, e.g., Danvy's unparsing combinators. That seems to ignore the fact that the pattern is a string, which means that printf's first argument in Danvy's mechanism has to be a literal. In Danvy's solution, the format argument is not a string. You can't read the printf format from a configuration file (for example) to support separate languages. You don't need to do that if you want to support separate languages. Moreover, reading the format string from external input is a good way of opening your program to security attacks, since ill-formed data on external media are then able to crash you program. It doesn't look like the version of printf that can print its arguments in an order different from the order provided in the argument list is supported either; something like %3$d or some such. I am not familiar with the version of printf you are refering to, but I am sure one could adapt Danvy's solution to support such a thing. Second, what's the type of the argument that printf, sprintf, fprintf, kprintf, etc all pass to the subroutine that actually does the formatting? (Called vprintf, I think?) Obviously, a Danvy-style solution (see, e.g., the one in SML/NJ's library) is not necessarily structured that way. I don't see the problem with typing, though. Matthias -- http://mail.python.org/mailman/listinfo/python-list
