Re: What is Expressiveness in a Computer Language
Torben Ægidius Mogensen wrote: > On a similar note, is a statically typed langauge more or less > expressive than a dynamically typed language? Some would say less, as > you can write programs in a dynamically typed language that you can't > compile in a statically typed language (without a lot of encoding), > whereas the converse isn't true. However, I think this is misleading, > as it ignores the feedback issue: It takes longer for the average > programmer to get the program working in the dynamically typed > language. >From the point of view purely of expressiveness I'd say it's rather different. If a language can express constraints of one kind that is an increase in expressiveness. If a language requires constraint to be in one particular way thats a decrease in expressiveness. So I would say languages that can be statically typed and can be dynamically typed are the most expressive. Languages that require static typing or are dynamic but cannot express static typing are less expressive. This meets my experience of what useful in practice too, static typing for everything is painful for writing simple code. Pure dynamic typing is painful when writing complex code because it makes impossible a layer of error checking that could otherwise be useful. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Torben Ægidius Mogensen wrote: > Pascal Costanza <[EMAIL PROTECTED]> writes: > > > Torben Ægidius Mogensen wrote: > > > > > On a similar note, is a statically typed langauge more or less > > > expressive than a dynamically typed language? Some would say less, as > > > you can write programs in a dynamically typed language that you can't > > > compile in a statically typed language (without a lot of encoding), > > > whereas the converse isn't true. > > > > It's important to get the levels right here: A programming language > > with a rich static type system is more expressive at the type level, > > but less expressive at the base level (for some useful notion of > > expressiveness ;). > > > > > However, I think this is misleading, > > > as it ignores the feedback issue: It takes longer for the average > > > programmer to get the program working in the dynamically typed > > > language. > > > > This doesn't seem to capture what I hear from Haskell programmers who > > say that it typically takes quite a while to convince the Haskell > > compiler to accept their programs. (They perceive this to be > > worthwhile because of some benefits wrt correctness they claim to get > > in return.) > > That's the point: Bugs that in dynamically typed languages would > require testing to find are found by the compiler in a statically > typed language. So whil eit may take onger to get a program thatgets > past the compiler, it takes less time to get a program that works. In my experience the opposite is true for many programs. Having to actually know the precise type of every variable while writing the program is not necessary, it's a detail often not relevant to the core problem. The language should be able to take care of itself. In complex routines it can be useful for the programmer to give types and for the compiler to issue errors when they are contradicted. But for most routines it's just an unnecessary chore that the compiler forces on the programmer. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Torben Ægidius Mogensen wrote: > "Rob Thorpe" <[EMAIL PROTECTED]> writes: > > > Torben Ægidius Mogensen wrote: > > > > That's the point: Bugs that in dynamically typed languages would > > > require testing to find are found by the compiler in a statically > > > typed language. So whil eit may take onger to get a program thatgets > > > past the compiler, it takes less time to get a program that works. > > > > In my experience the opposite is true for many programs. > > Having to actually know the precise type of every variable while > > writing the program is not necessary, it's a detail often not relevant > > to the core problem. The language should be able to take care of > > itself. > > > > In complex routines it can be useful for the programmer to give types > > and for the compiler to issue errors when they are contradicted. But > > for most routines it's just an unnecessary chore that the compiler > > forces on the programmer. > > Indeed. So use a language with type inference. Well, for most purposes that's the same as dynamic typing since the compiler doesn't require you to label the type of your variables. I occasionally use CMUCL and SBCL which do type inference, which is useful at improving generated code quality. It also can warn the programmer if they if they reuse a variable in a context implying that it's a different type which is useful. I see type inference as an optimization of dynamic typing rather than a generalization of static typing. But I suppose you can see it that way around. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris Smith wrote: > Torben Ægidius Mogensen <[EMAIL PROTECTED]> wrote: > > That's not really the difference between static and dynamic typing. > > Static typing means that there exist a typing at compile-time that > > guarantess against run-time type violations. Dynamic typing means > > that such violations are detected at run-time. This is orthogonal to > > strong versus weak typing, which is about whether such violations are > > detected at all. The archetypal weakly typed language is machine code > > -- you can happily load a floating point value from memory, add it to > > a string pointer and jump to the resulting value. ML and Scheme are > > both strongly typed, but one is statically typed and the other > > dynamically typed. > > Knowing that it'll cause a lot of strenuous objection, I'll nevertheless > interject my plea not to abuse the word "type" with a phrase like > "dynamically typed". If anyone considers "untyped" to be perjorative, > as some people apparently do, then I'll note that another common term is > "type-free," which is marketing-approved but doesn't carry the > misleading connotations of "dynamically typed." We are quickly losing > any rational meaning whatsoever to the word "type," and that's quite a > shame. 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. 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. Some people use dynamic typing as a word for latent typing, others use it to mean something slightly different. But for most purposes the definition above works for dynamic typing also. Untyped and type-free mean something else: they mean no type checking is done. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris Smith wrote: > Rob Thorpe <[EMAIL PROTECTED]> wrote: > > A language is latently typed if a value has a property - called it's > > type - attached to it, and given it's type it can only represent values > > defined by a certain class. > > I'm assuming you mean "class" in the general sense, rather than in the > sense of a specific construct of some subset of OO programming > languages. Yes. > Now I define a class of values called "correct" values. I define these > to be those values for which my program will produce acceptable results. > Clearly there is a defined class of such values: (1) they are > immediately defined by the program's specification for those lines of > code that produce output; (2) if they are defined for the values that > result from any expression, then they are defined for the values that > are used by that expression; and (3) for any value for which correctness > is not defined by (1) or (2), we may define its "correct" values as the > class of all possible values. I'm not talking about correctness, I'm talking about typing. > Now, by your definition, any language > which provides checking of that property of correctness for values is > latently typed. 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." I said nothing about the values producing correct outputs, or being correct inputs. I only said that they have types. What I mean is that each value in the language is defined by two peice of information, its contents X and its type T. > Of course, there are no languages that assign this > specific class of values; but ANY kind of correctness checking on values > that a language does (if it's useful at all) is a subset of the perfect > correctness checking system above. Apparently, we should call all such > systems "latent type systems". No, I'm speaking about type checking not correctness. > Can you point out a language that is not > latently typed? Easy, any statically typed language is not latently typed. Values have no type associated with them, instead variables have types. If I tell a C program to print out a string but give it a number it will give an error telling me that the types mismatch where the variable the number is held in is used to assign to a variable that must hold a string. Similarly if I have a lisp function that prints out a string it will also fail when given a number, but it will fail at a different point, it will fail when the type of the value is examined and found to be incorrect. > I'm not trying to poke holes in your definition for fun. I am proposing > that there is no fundamental distinction between the kinds of problems > that are "type problems" and those that are not. Types are not a class > of problems; they are a class of solutions. Exactly. Which is why they are only tangentially associated with correctness. Typing is a set of rules put in place to aid correctness, but it is not a system that attempts to create correctness itself. > Languages that solve > problems in ways that don't assign types to variables are not typed > languages, even if those same problems may have been originally solved > by type systems. Well, you can think of things that way. But to the rest of the computing world languages that don't assign types to variables but do assign them to values are latently typed. > > Untyped and type-free mean something else: they mean no type checking > > is done. > > Hence, they don't exist, and the definitions being used here are rather > pointless. No they aren't, types of data exist even if there is no system in place to check them. Ask an assembly programmer whether his programs have string and integers in them and he will probably tell you that they do. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
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"? ??? > > Easy, any statically typed language is not latently typed. Values have > > no type associated with them, instead variables have types. > > A (static) type system assigns types to (all) *expressions*. That's right most of the time yes, I probably should have said expressions. Though I can think of static typed languages where the resulting type of an expression depends on the type of the variable it is being assigned to. > This includes values as well as variables. Well I haven't programmed in any statically typed language where values have types themselves. Normally the language only knows that variable Z is of type Q because it's in a variable of type Q, or as you mention an expression of type Q. There are many things that could be considered more than one type. The integer 45 could be unsigned 45 or signed 45 or even float 45 depending on the variable it's in, but without context it doesn't have a precise type. It does imply the type to some extent though, you could imagine a language where every value has a precise type. So, you've found a hole in my definition. Maybe a better definition would be:- if (variables have types || expressions have types) else if (values have types) else That seems to fit usage, quite well. Even then there are problems. Perl has static types for arrays, hashs and scalars. But scalars themselves can be integers, strings, etc. > Don't confuse type assignment with type annotation (which many > mainstream languages enforce for, but also only allow for, variable > declarations). Point taken. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
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. Compare this to an untyped language where types cannot generally be tested. > >>A (static) type system assigns types to (all) *expressions*. > > > > That's right most of the time yes, I probably should have said > > expressions. Though I can think of static typed languages where the > > resulting type of an expression depends on the type of the variable it > > is being assigned to. > > Yes, but that's no contradiction. A type system does not necessarily > assign *unique* types to individual expressions (consider overloading, > subtyping, polymorphism, etc). That's a fair way of looking at it. > > Well I haven't programmed in any statically typed language where values > > have types themselves. > > 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. 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. > 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Ketil Malde wrote: > "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. Well I haven't been consistent so far :) But I mean the value as the semantics of the program itself sees it. Which mostly means the datum in memory. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Matthias Blume wrote: > "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. You can call them predicates if you like. Most people programming in python, perl, or lisp will call them types though. > > Compare this to an untyped language where types cannot generally be > > tested. > > You mean there are no predicates in untyped languages? Well, no there aren't. That's what defines a language as untyped. Of-course you can make them with your own code, in for example assembler, but that's outside the language. > >> 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. 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. Have a look in a C compiler if you don't believe me. You store 56 in a location in memory then in most compilers all that will be store is 56, nothing more. The compiler relys entirely on the types of the variables to know how to correctly operate on the values. The values themselves have no type information associated with them. > > 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. 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. > >> 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. No it isn't. If I say "4 is a integer" that is a direct statement about 4. If I say "X is and integer and X is 4, therefore 4 is an integer" that is a slightly less direct statement about 4. The difference in directness is only small, and much more indirectness is needed to prove anything useful about a system formally. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Andreas Rossberg wrote: > Rob Thorpe wrote: > >Andreas Rossberg wrote: > >>Rob Thorpe wrote: > >> > >>>>>"A language is latently typed if a value has a property - called it's > >>>>>type - attached to it, and given it's type it can only represent values > >>>>>defined by a certain class." > >>>> > >>>>"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. > > I'm sorry, but I still think that the definition makes little sense. > Obviously, a value simply *is* a value, it does not "represent" one, or > several ones, regardless how you qualify that statement. You've clipped a lot of context. I'll put some back in, I said:- > > 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. > > Compare this to an untyped language where types cannot generally be > > tested. I think this should make it clear. If I have a "xyz" in lisp I know it is a string. If I have "xyz" in an untyped language like assembler it may be anything, two pointers in binary, an integer, a bitfield. There is no data at compile time or runtime to tell what it is, the programmer has to remember. (I'd point out this isn't true of all assemblers, there are some typed assemblers) > >>>Well I haven't programmed in any statically typed language where values > >>>have types themselves. > >> > >>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, > > No, variables are insignificant in this context. You can consider a > language without variables at all (such languages exist, and they can > even be Turing-complete) and still have evaluation, values, and a > non-trivial type system. Hmm. You're right, ML is no-where in my definition since it has no variables. > > But the value itself has no type > > You mean that the type of the value is not represented at runtime? True, > but that's simply because the type system is static. It's not the same > as saying it has no type. Well, is it even represented at compile time? The compiler doesn't know in general what values will exist at runtime, it knows only what types variables have. Sometimes it only has partial knowledge and sometimes the programmer deliberately overrides it. From what knowledge it you could say it know what types values will have. > > 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. > > Nothing in the C spec precludes an implementation from doing just that. True, that would be an interesting implementation. > The problem with C rather is that its semantics is totally > underspecified. In any case, C is about the worst example to use when > discussing type systems. For starters, it is totally unsound - which is > what your example exploits. Yes. Unfortunately it's often necessary to break static type systems. Regarding C the problem is, what should we discuss instead that would be understood in all these newsgroups we're discussing this in. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Darren New wrote: > Rob Thorpe wrote: > > The compiler > > relys entirely on the types of the variables to know how to correctly > > operate on the values. The values themselves have no type information > > associated with them. > > int x = (int) (20.5 / 3); > > What machine code operations does the "/" there invoke? Integer > division, or floating point division? How did the variables involved in > the expression affect that? In that case it knew because it could see at compile time. In general though it doesn't. If I divide x / y it only knows which to use because of types declared for x and y. > >>Casting in C takes values of one type to values of another type. > > > No it doesn't. Casting reinterprets a value of one type as a value of > > another type. > > No it doesn't. > int x = (int) 20.5; > There's no point at which bits from the floating point representation > appear in the variable x. > > int * x = (int *) 0; > There's nothing that indicates all the bits of "x" are zero, and indeed > in some hardware configurations they aren't. I suppose some are conversions and some reinterpretations. What I should have said it that there are cases where cast reinterprets. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Pascal Costanza wrote: > Matthias Blume wrote: > > Pascal Costanza <[EMAIL PROTECTED]> writes: > >> (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. :-) > > This sort of feature is clearly not meant for you. ;-P To be fair though that kind of thing would only really be used while debugging a program. Its no different than adding a new member to a class while in the debugger. There are other places where you might add a slot to an object at runtime, but they would be done in tidier ways. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
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 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
> So, will y'all just switch from using "dynamically typed" to "latently > typed", and stop talking about any real programs in real programming > languages as being "untyped" or "type-free", unless you really are > talking about situations in which human reasoning doesn't come into > play? I think you'll find it'll help to reason more clearly about this > whole issue. I agree with most of what you say except regarding "untyped". In machine language or most assembly the type of a variable is something held only in the mind of the programmer writing it, and nowhere else. In latently typed languages though the programmer can ask what they type of a particular value is. There is a vast difference to writing code in the latter kind of language to writing code in assembly. I would suggest that at least assembly should be referred to as "untyped". -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Matthias Blume wrote: > "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. Well, with a literal yes. But with the value of some variable x at runtime it only know the type because it knows the type of the variable. Similarly the type of values generated by an expression are only known because the type the expression generates is known. > > It knows only their type in that it knows the type of the variable they > > are contained within. > > Would you agree with that? Would you? > >> > 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. >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. Yes. I'm not arguing with that. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Matthias Blume wrote: > "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? Well it's really a matter of perspective isn't it. In some cases it may even be what the programmer intends. >From my perspective I don't expect a large positive number to turn into a negative one just because I've requested that it be signed. The behaviour I would expect is that either the variable being set gets the right number, or an error occurs. I don't care if the reporting is at runtime or compile time, so long as it can be seen. -- Anyway, this is a small point. Does the fact that you only disagreed with me on this point indicate that you agreed with everything else? ... Only joking :) I think you and I have irreconcilable views on this subject. I think we can agree that value mostly have some sort of type in a statically typed language. You may say that they have directly have types, but I can't see how that can be, as far as I can see they have types only indirectly. This is only a minor point though. The issue of typing of values vs variables is not practically meaningless though. The main problem I find with statically typed programs is that much of the world outside the program is not statically typed. Library and API writers in-particular seem to treat static typing carelessly. As a result it's not generally possible to write a program meaningfully inside the static type system, as the type systems designers intended. You're force to break it all over the place with casts etc anyway. And at every place you break it the possibility of error occurs and flow from that place into the rest of the program. So, you end up actually checking the values of variables rather than relying on their types anyway. And this can be difficult because their values have no associated information telling you their types. It's different writing a function deep inside a large program, in this case data can be cleaned up beforehand. And in this case the static typing works are intended and becomes more useful. Anyway, I don't think it would help either of us to continue this sub-thread any more. Feel free to reply to this post, but I might not reply back. Static typing is rather off topic on most of the newsgroups this thread is in anyway, and I suspect the people in them are getting rather sick of it. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
David Hopwood wrote: > Rob Thorpe wrote: > > 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 knows only their type in that it knows the type of the variable they > > are contained within. > > Would you agree with that? > > No. In any language, it may be possible to statically infer that the > value of an expression will belong to a set of values smaller than that > allowed by the expression's type in that language's type system. For > example, all constants have a known value, but most constants have a > type which allows more than one value. > > (This is an essential point, not just nitpicking.) Yes, I agree. That does not apply in general though. In general the value of the variable could be, for example, read from a file, in which case the compiler may know it's type, but not any more. I was talking about the general case. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Rob Thorpe wrote: > Chris Smith wrote: > > Torben Ægidius Mogensen <[EMAIL PROTECTED]> wrote: > > > That's not really the difference between static and dynamic typing. > > > Static typing means that there exist a typing at compile-time that > > > guarantess against run-time type violations. Dynamic typing means > > > that such violations are detected at run-time. This is orthogonal to > > > strong versus weak typing, which is about whether such violations are > > > detected at all. The archetypal weakly typed language is machine code > > > -- you can happily load a floating point value from memory, add it to > > > a string pointer and jump to the resulting value. ML and Scheme are > > > both strongly typed, but one is statically typed and the other > > > dynamically typed. > > > > Knowing that it'll cause a lot of strenuous objection, I'll nevertheless > > interject my plea not to abuse the word "type" with a phrase like > > "dynamically typed". If anyone considers "untyped" to be perjorative, > > as some people apparently do, then I'll note that another common term is > > "type-free," which is marketing-approved but doesn't carry the > > misleading connotations of "dynamically typed." We are quickly losing > > any rational meaning whatsoever to the word "type," and that's quite a > > shame. > > 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. > > 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. > > Some people use dynamic typing as a word for latent typing, others use > it to mean something slightly different. But for most purposes the > definition above works for dynamic typing also. > > Untyped and type-free mean something else: they mean no type checking > is done. Since people have found some holes in this definition I'll have another go:- Firstly, a definition, General expression (gexpr) are variables (mutable or immutable), expressions and the entities functions return. A statically typed language has a parameter associated with each gexpr called it's type. The code may test the type of a gexpr. The language will check if the gexprs of an operator/function have types that match what is required, to some criteria of sufficiency. It will emit an error/warning when they don't. It will do so universally. A latently typed language has a parameter associated with each value called it's type. The code may test the type of a value. The language may check if the gexprs of an operator/function have types that match what is required, to some criteria of sufficiency. It will not necessarily do so universally. An untyped language is one that does not possess either a static or latent type system. In an untyped language gexprs possess no type information, and neither do values. -- These definitions still have problems, they don't say anything about languages that sit between the various categories for example. I don't know where HM type system would come in them. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Vesa Karvonen wrote: > In comp.lang.functional Anton van Straaten <[EMAIL PROTECTED]> wrote: > > Let me add another complex subtlety, then: the above description misses > > an important point, which is that *automated* type checking is not the > > whole story. I.e. that compile time/runtime distinction is a kind of > > red herring. > > I agree. I think that instead of "statically typed" we should say > "typed" and instead of "(dynamically|latently) typed" we should say > "untyped". > > > In a statically-checked language, people tend to confuse automated > > static checking with the existence of types, because they're thinking in > > a strictly formal sense: they're restricting their world view to what > > they see "within" the language. > > That is not unreasonable. You see, you can't have types unless you > have a type system. Types without a type system are like answers > without questions - it just doesn't make any sense. > > > Then they look at programs in a dynamically-checked language, and see > > checks happening at runtime, and they assume that this means that the > > program is "untyped". > > Not in my experience. Either a *language* specifies a type system or > not. There is little room for confusion. Well, at least unless you > equate "typing" with being "well-defined" or "safe" and go to great > lengths to convince yourself that your program has "latent types" even > without specifying a type system. The question is: What do you mean by "type system"? Scheme and Lisp both define how types work in their specifications clearly, others may do too, I don't know. Of-course you may not consider that as a type system if you mean "type system" to mean a static type system. > > It's certainly close enough to say that the *language* is untyped. > > Indeed. Either a language has a type system and is typed or has no > type system and is untyped. I see very little room for confusion > here. In my experience, the people who confuse these things are > people from the dynamic/latent camp who wish to see types everywhere > because they confuse typing with safety or having well-defined > semantics. No. It's because the things that we call latent types we use for the same purpose that programmers of static typed languages use static types for. Statically typed programmers ensure that the value of some expression is of some type by having the compiler check it. Programmers of latently typed languages check, if they think it's important, by asking what the type of the result is. The objection here is that advocates of statically typed language seem to be claiming the "type" as their own word, and asking that others use their definitions of typing, which are really specific to their subjects of interest. This doesn't help advocates of static languages/ latently typed languages, or anyone else. It doesn't help because no-one else is likely to change their use of terms, there's no reason why they would. All that may happen is that users of statically typed languages change the words they use. This would confuse me, for one. I would much rather understand what ML programmers, for example, are saying and that's hard enough as it is. There's also my other objection, if you consider latently typed languages untyped, then what is assembly? -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
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. That's not the same thing. The value of a union in C can be any of a set of specified types. But the program cannot find out which, and the language doesn't know either. With C++ and Java dynamic types the program can test to find the type. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Dr.Ruud wrote: > Rob Thorpe schreef: > > Dr.Ruud: > >> Marshall: > > >>> "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. > > > > That's not the same thing. > > That is your opinion. In the context of this discussion I don't see any > problem to put C's union under "dynamic types". Lets put it like this:- 1. In C++ and Java it is possible to make a variable that can A)Take on many different types and B)Where the programmer can test what the type is. 2. In C it is possible to make a variable that can do 1A but not 1B. This is a statement of fact, not opinion. I call languages that do #1 dynamically typed, in line with common usage. > > The value of a union in C can be any of a > > set of specified types. But the program cannot find out which, and > > the language doesn't know either. > > > > With C++ and Java dynamic types the program can test to find the type. > > When such a test is needed for the program with the union, it has it. What do you mean? There is no way to test the type of the value inside a union in C. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
David Hopwood wrote: > Rob Thorpe wrote: > > Vesa Karvonen wrote: > > > >>In comp.lang.functional Anton van Straaten <[EMAIL PROTECTED]> wrote: > >> > >>>Let me add another complex subtlety, then: the above description misses > >>>an important point, which is that *automated* type checking is not the > >>>whole story. I.e. that compile time/runtime distinction is a kind of > >>>red herring. > >> > >>I agree. I think that instead of "statically typed" we should say > >>"typed" and instead of "(dynamically|latently) typed" we should say > >>"untyped". > [...] > >>>It's certainly close enough to say that the *language* is untyped. > >> > >>Indeed. Either a language has a type system and is typed or has no > >>type system and is untyped. I see very little room for confusion > >>here. In my experience, the people who confuse these things are > >>people from the dynamic/latent camp who wish to see types everywhere > >>because they confuse typing with safety or having well-defined > >>semantics. > > > > No. It's because the things that we call latent types we use for the > > same purpose that programmers of static typed languages use static > > types for. > > > > Statically typed programmers ensure that the value of some expression > > is of some type by having the compiler check it. Programmers of > > latently typed languages check, if they think it's important, by asking > > what the type of the result is. > > > > The objection here is that advocates of statically typed language seem > > to be claiming the "type" as their own word, and asking that others use > > their definitions of typing, which are really specific to their > > subjects of interest. > > As far as I can tell, the people who advocate using "typed" and "untyped" > in this way are people who just want to be able to discuss all languages in > a unified terminological framework, and many of them are specifically not > advocates of statically typed languages. Its easy to create a reasonable framework. My earlier posts show simple ways of looking at it that could be further refined, I'm sure there are others who have already done this. The real objection to this was that latently/dynamically typed languages have a place in it. 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
David Hopwood wrote: > Rob Thorpe wrote: > > David Hopwood wrote: > > > >>As far as I can tell, the people who advocate using "typed" and "untyped" > >>in this way are people who just want to be able to discuss all languages in > >>a unified terminological framework, and many of them are specifically not > >>advocates of statically typed languages. > > > > Its easy to create a reasonable framework. My earlier posts show simple > > ways of looking at it that could be further refined, I'm sure there are > > others who have already done this. > > > > The real objection to this was that latently/dynamically typed > > languages have a place in it. > > You seem to very keen to attribute motives to people that are not apparent > from what they have said. 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. > > 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? Memory safety isn't the whole point, it's only half of it. Typing itself is the point. Regardless of memory safety if you do a calculation in a latently typed langauge, you can find the type of the resulting object. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Dr.Ruud wrote: > Rob Thorpe schreef: > > > I would suggest that at least assembly should be referred to as > > "untyped". > > There are many different languages under the umbrella of "assembly", so > your suggestion is bound to be false. Well yes, it is false, I know of several typed assemblers. But I mentioned that point elsewhere so I didn't repeat it. This thread is huge and I expect no-one will have read it all, so I will be more clear in future. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Andreas Rossberg wrote: > Rob Thorpe wrote: > > > > Its easy to create a reasonable framework. > > Luca Cardelli has given the most convincing one in his seminal tutorial > "Type Systems", where he identifies "typed" and "safe" as two orthogonal > dimensions and gives the following matrix: > >| typed | untyped > ---+---+-- > safe | ML| Lisp > unsafe | C | Assembler > > Now, jargon "dynamically typed" is simply untyped safe, while "weakly > typed" is typed unsafe. Consider a langauge something like BCPL or a fancy assembler, but with not quite a 1:1 mapping with machine langauge. It differs in one key regard: it has a variable declaration command. This command allows the programmer to allocate a block of memory to a variable. If the programmer attempts to index a variable outside the block of memory allocated to it an error will occur. Similarly if the programmer attempts to copy a larger block into a smaller block an error would occur. Such a language would be truly untyped and "safe", that is safe according to many peoples use of the word including, I think, yours. But it differs from latently typed languages like python, perl or lisp. In such a language there is no information about the type the variable stores. The programmer cannot write code to test it, and so can't write functions that issue errors if given arguments of the wrong type. The programmer must use his or her memory to substitute for that facility. As far as I can see this is a significant distinction and warrants a further category for latently typed languages. As a sidenote: the programmer may also create a tagging system to allow the types to be tracked. But this is not the same as saying the language supports types, it is akin to the writing of OO programs in C using structs. -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
[EMAIL PROTECTED] wrote: > Rob Thorpe wrote: > > > > But it differs from latently typed languages like python, perl or lisp. > > In such a language there is no information about the type the variable > > stores. The programmer cannot write code to test it, and so can't > > write functions that issue errors if given arguments of the wrong type. > > The programmer must use his or her memory to substitute for that > > facility. As far as I can see this is a significant distinction and > > warrants a further category for latently typed languages. > > Take one of these languages. You have a variable that is supposed to > store functions from int to int. Can you test that a given function > meets this requirement? The answer is no for python and perl AFAIK. Also no for lisp _aux naturelle_ (you can do it by modifying lisp though of-course, I believe you can make it entirely statically typed if you want). But the analogous criticism could be made of statically typed languages. 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? > You see, IMO the difference is marginal. From my point of view, the > fact that you can do such tests *in some very trivial cases* They are not very trivial for practical programming purposes though, they are important. > in the > languages you mention is an artefact, nothing fundamental. The cases can be far from trivial. In lisp a type specifier can mean something like "argument must be a 10x10 matrix with top corner element larger than 35" You can also, for example, easily make predicates that tell if a value is odd, or a fibonacci number. The system simply extends in different directions. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Mathias Panzenboeck wrote: > Mark Tarver wrote: > > How do you compare Python to Lisp? What specific advantages do you > > think that one has over the other? > > > > Note I'm not a Python person and I have no axes to grind here. This is > > just a question for my general education. > > > > Mark > > > > I do not know much about Lisp. What I know is: > Python is a imperative, object oriented dynamic language with duck typing, Yes, but Python also supports the functional style to some extent. > List is a declarative, > functional dynamic language Lisp is only a functional language in that it support both functional and imperative programming styles. Duck typing is almost identical to latent typing in Lisp. And, Common Lisp at least is object orientated. > -> those two languages have different scopes. Their scope is actually very similar. Learn about lisp and you will soon discover their similarity. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Alex Mizrahi wrote: > (message (Hello 'Kay) > (you :wrote :on '(8 Dec 2006 08:03:18 -0800)) > ( > > KS> http://www.sbcl.org/manual/Handling-of-Types.html#Handling-of-Types > > KS> If you'd read the docs of the tools you admire you might find the > KS> answers yourself. > > SBCL is a COMPILER that explains everything. it's interesting why > INTERPRETER like CLISP is faster. > well, it can be type declarations as well, but maybe something other too.. I agree with your other points. Python allows the programmer to override absolutely anything, including things like addition. This entails extra work. It's also worth mentioning that Clisp is an hugely optimized interpreter. A much work has been put in to making it's bytecode interpreting inner loops as fast as possible. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Juan R. wrote: > Ken Tilton ha escrito: > > You missed it? Google fight: > > > >http://www.googlefight.com/index.php?lang=en_GB&word1=Python&word2=Ruby > > > > Python wins, 74 to 69.3. And there is no Monty Ruby to help. > > > > ken > > Nice animation! > > http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Monty+Ruby It's not fair to pick on him just because you're better at Googlefighting... http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Juan+Gonz%E1lez This thing is strange, I don't understand it at all... http://www.googlefight.com/index.php?lang=en_GB&word1=Ken+Tilton&word2=Robert+Thorpe I find the results dubious. A conspiracy masterminded by Monty Ruby no doubt. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: > Pascal Costanza <[EMAIL PROTECTED]> writes: > Yes; I'd rather go by what the standard says than rely on > implementation-dependent hacks. But in that case what do you call Python? The whole language has no standard - is it an "implementation dependent hack"? Standards are useful, but they are not the beginning and end of programming. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Robert Uhl wrote: > Christophe <[EMAIL PROTECTED]> writes: > > Robert Uhl a écrit : > > > >> The argument from popularity is invalid. French units have overtaken > >> standard units, > > > > Never heard of that French unit thing. Unless you talk about that > > archaic unit system that was in use before the metric system was > > created. > > I use 'French units' instead of the term 'metric system' because the > latter means 'measurement system,' and of course could validly be > applied to _any_ system. A good term to use, if your audience is likely to understand it, is "SI units". The current units used in science and for most measurements are "Systeme International d'unites" Units. The original metric system is not really used anymore, SI is slightly different. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Bruno Desthuilliers wrote: > Mathias Panzenboeck a écrit : > > Rob Thorpe wrote: > > > >>Mathias Panzenboeck wrote: > >> > >>>Mark Tarver wrote: > >>> > >>>>How do you compare Python to Lisp? What specific advantages do you > >>>>think that one has over the other? > >>>> > >>>>Note I'm not a Python person and I have no axes to grind here. This is > >>>>just a question for my general education. > >>>> > >>>>Mark > >>>> > >>> > >>>I do not know much about Lisp. What I know is: > >>>Python is a imperative, object oriented dynamic language with duck typing, > >> > >>Yes, but Python also supports the functional style to some extent. > >> > > > > > > I currently visit a course about functional programming at the university > > of technology vienna: > > python implements only a small subset of things needed to be called a > > functional language (list > > comprehension). > > Python has functions as first-class objects (you can pass functions as > arguments to functions, return functions from functions, and bind > functions to identifiers), and that's the only thing you need to use a > functional approach. Once you can do the above then you can phrase programs entirely in terms of composition of functions, which is what functional programming is about. Getting good performance though is problematic without being able to evaluate parts at compile time. This is why almost all functional languages provide that feature in some form. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Anders J. Munch wrote: > jayessay wrote: > > Please note: GC is not part of CL's definition. It is likely not part > > of any Lisp's definition (for reasons that should be obvious), and for > > the same reasons likely not part of any language's definition. > > Really? So how do you write a portable program in CL, that is to run > for unbounded lengths of time? You can't. The thing about the spec not defining GC is almost a bit of humour. No-one would use an implementation with no GC. The issue with specifying it is: How would you do it? The memory used by a program is an aspect of the language implementation and the system the program is running on, so how can it be defined in a useful way? You could say for example "Storage allocated for an object is released when the object is no longer visible and memory usage is high". But how do you define how high memory usage should be? You could say when memory is almost exhausted, even that is difficult to define. Then you could have the situation where someone creates a lisp compiler than emits FPGA netlists, how do you check something like this? None of this would be in the spirit of the spec, which doesn't even define memory AFAIK. The spec deals entirely in matters of the language and it's appearance to the programmer. For what it's worth I think the C spec is the same, and says nothing about actual memory usage. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Pascal Bourguignon wrote: > "Rob Thorpe" <[EMAIL PROTECTED]> writes: > > Anders J. Munch wrote: > >> jayessay wrote: > >> > Please note: GC is not part of CL's definition. It is likely not part > >> > of any Lisp's definition (for reasons that should be obvious), and for > >> > the same reasons likely not part of any language's definition. > >> > >> Really? So how do you write a portable program in CL, that is to run > >> for unbounded lengths of time? > > > > You can't. > > You can. Just use reversible operations. > > Or use pre-allocated objects. Yes, that means that you implement your > own memory management or garbage collector, but this would be portable. I don't think there is any gaurantee in the spec that says that even doing nothing at all doesn't allocate more memory. AFAIK a conforming implementation could leak a fixed amount of memory per second. -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Anders J. Munch wrote:
> Rob Thorpe wrote:
> > Anders J. Munch wrote:
> >> Really? So how do you write a portable program in CL, that is to
> >> run for unbounded lengths of time?
> >
> > You can't.
> >
> > The thing about the spec not defining GC is almost a bit of humour.
> > No-one would use an implementation with no GC.
> >
> > The issue with specifying it is: How would you do it? The memory
> > used by a program is an aspect of the language implementation and
> > the system the program is running on, so how can it be defined in a
> > useful way?
>
> Let u(t) be the actual memory used by the program at time t.
> Let r(t) be the size of reachable memory at time t.
>
> Require that u(t) is a member of O(t -> max{t'<=t: r(t')})
>
> There. That wasn't so hard, was it?
That's quite a clever definition actually.
But, let's say I have a lisp machine. It has an unusual architecture,
it's made entirely of SRAM cells of ~9bits. Sometimes these cells are
used as storage, sometimes their contents represent logic circuits and
the routing between them is configured to form them into a processor.
Please tell me what reachable memory is ;). (The above processor is
not science fiction, it could easily be done with FPGAs)
I suppose a solution would be:-
If the lisp implementation runs on a fixed processor that has separate
storage then ...
Let u(t) be the actual memory used by the program at time t.
Let r(t) be the size of reachable memory at time t.
...
--
http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Anders J. Munch wrote:
> Rob Thorpe wrote:
> > Anders J. Munch wrote:
> >> Let u(t) be the actual memory used by the program at time t.
> >> Let r(t) be the size of reachable memory at time t.
> >>
> >> Require that u(t) is a member of O(t -> max{t'<=t: r(t')})
> >>
> >> There. That wasn't so hard, was it?
> >
> > That's quite a clever definition actually.
> > But, let's say I have a lisp machine. It has an unusual architecture,
> > it's made entirely of SRAM cells of ~9bits. Sometimes these cells are
> > used as storage, sometimes their contents represent logic circuits and
> > the routing between them is configured to form them into a processor.
> > Please tell me what reachable memory is ;). (The above processor is
> > not science fiction, it could easily be done with FPGAs)
>
> Reachable memory is the set of interpreter objects (conses, closures, scopes,
> atoms and what have you) reachable from from some appropriately defined root
> set. It can be unambiguously defined with respect to a virtual machine, with
> no
> regard to how actual implementations represent these things.
Yes.
> For actual memory use, a simple byte count would do fine. If code and data
> are
> intermingled, just use the combined size of both of them.
Well, in my example the code, the data and the processor are
intermingled. Still you could do it this way. But, what would happen
for example if on a normal machine someone wrote a program that
generated lots of functions that it never used, would it have to be
detected by the GC. This is hard to do. The solution is probably to
define the root set only in terms of data.
> If you're worried about comparing incompatible units, don't be: apples and
> oranges compare just fine under big-Oh.
Yes. Thank you for comprehensively out-arguing me.
I'll give one last reason why it may not be a good thing to define:
reference counting. Some people want to use refcounts, and believe
that under certain circumstances they provide better performance than
GC. I don't know if they're right, I suspect they are for some limited
circumstances. A normal ref-count system can't be gauranteed to have
no memory holes introduced by loops in the data. But, if the
programmer causes no loops to come into being then he/she is safe. An
implementation that used refcounting might not be of much general use,
but for specific purposes, embedded programming for example, it might
be useful.
--
http://mail.python.org/mailman/listinfo/python-list
