Re: Perl-Python-a-Day: Sorting
Ulrich Hobelmann wrote: > Xah Lee wrote: > >> To sort a list in Python, use the “sort” method. For example: >> >> li=[1,9,2,3]; >> li.sort(); >> print li; > > Likewise in Common Lisp. In Scheme there are probably packages for that > as well. My apologies for not being very fluent anymore. > > CL-USER> (setf list (sort '(1 9 2 3) #'<)); input > (1 2 3 9); output Careful. Common Lisp's sort function is specified to be destructive, so you shouldn't use it on literal constants. So don't say (sort '(1 9 2 3) ...), say (sort (list 1 9 2 3) ...), etc. Pascal -- OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol see http://p-cos.net/oopsla05-tutorial.html for more details -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-likeness
Marcin 'Qrczak' Kowalczyk wrote: [EMAIL PROTECTED] (Thomas A. Russ) writes: (defun addn (n) #'(lambda (x) (+ x n))) The same as def addn(n): def fn(x): return n + x return fn Is this really equivalent? What happens if you call addn more than once with different parameters. Will you get different functions that you can use simultaneously? Yes. It also behaves correctly when a variable it refers to is later mutated. BTW, the fact that a closure refers to a variable itself rather to its current value can be used to check the true attitude of languages with respect to functional programming, by observing how they understand their basic loops :-) None of the examples you show close over values. The difference is in whether the loop constructs use one binding for their control variable or create new bindings in each iteration: (loop for i below 10 collect (lambda (x) (setq i x)) into setters collect (lambda () i) into getters finally (print (funcall (elt getters 0))) (funcall (elt setters 4) 42) (print (funcall (elt getters 9 => 10 => 42 If this difference matters to you, just be more explicit. Pascal -- http://mail.python.org/mailman/listinfo/python-list
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. 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.) Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Neelakantan Krishnaswami wrote: > In article <[EMAIL PROTECTED]>, Pascal Costanza wrote: >> 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 ;). > > This doesn't seem obviously the case to me. If you have static > information about your program, the compiler can use this information > to automate a lot of grunt work away. > > Haskell's system of typeclasses work this way. If you tell the > compiler how to print integers, and how to print lists, then when you > call a print function on a list of list of integers, then the compiler > will automatically figure out the right print function using your base > definitions. This yields an increase in Felleisen-expressiveness over > a dynamically typed language, because you would need to globally > restructure your program to achieve a similar effect. > > More dramatic are the "polytypic" programming languages, which let you > automate even more by letting you write generic map, fold, and print > functions which work at every type. Yes, but these decisions are taken at compile time, without running the program. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Torben Ægidius Mogensen wrote: > Raffael Cavallaro <[EMAIL PROTECTED]'espam-s'il-vous-plait-mac.com> writes: > >> On 2006-06-14 16:36:52 -0400, Pascal Bourguignon <[EMAIL PROTECTED]> said: >> >>> In lisp, all lists are homogenous: lists of T. >> CL-USER 123 > (loop for elt in (list #\c 1 2.0d0 (/ 2 3)) collect >> (type-of elt)) >> (CHARACTER FIXNUM DOUBLE-FLOAT RATIO) >> >> i.e., "heterogenous" in the common lisp sense: having different >> dynamic types, not in the H-M sense in which all lisp values are of >> the single union type T. > > What's the difference? Dynamically types values _are_ all members of > a single tagged union type. Yes, but that's mostly a meaningless statement in a dynamically typed language. In a dynamically typed language, you typically don't care about the static types. > The main difference is that the tages > aren't always visible and that there are only a fixed, predefined > number of them. Depending on the language, the number of "tags" is not fixed. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- 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. Yes. However, unfortunately statically typed languages also reject programs that don't have such bugs. It's a tradeoff whether you want to spend time to deal with them or not. > So whil eit may take onger to get a program thatgets > past the compiler, it takes less time to get a program that works. That's incorrect. See http://haskell.org/papers/NSWC/jfp.ps - especially Figure 3. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- 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: > >>> So while it may take longer to get a program that gets >>> past the compiler, it takes less time to get a program that works. >> That's incorrect. See http://haskell.org/papers/NSWC/jfp.ps - >> especially Figure 3. > > There are many other differences between these languages than static > vs. dynamic types, and some of these differences are likely to be more > significant. What you need to test is langauges with similar features > and syntax, except one is statically typed and the other dynamically > typed. > > And since these languages would be quite similar, you can use the same > test persons: First let one half solve a problem in the statically > typed language and the other half the same problem in the dynamically > typed language, then swap for the next problem. If you let a dozen > persons each solve half a dozen problems, half in the statically typed > language and half in the dynamically typed language (using different > splits for each problem), you might get a useful figure. ...and until then claims about the influence of static type systems on the speed with which you can implement working programs are purely guesswork. That's the only point I need to make to show that your original unqualified statement, namely that it takes less time to get a program that works, is incorrect. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- 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. The words "untyped" or "type-free" only make sense in a purely statically typed setting. In a dynamically typed setting, they are meaningless, in the sense that there are _of course_ types that the runtime system respects. Types can be represented at runtime via type tags. You could insist on using the term "dynamically tagged languages", but this wouldn't change a lot. Exactly _because_ it doesn't make sense in a statically typed setting, the term "dynamically typed language" is good enough to communicate what we are talking about - i.e. not (static) typing. > By way of extending the point, let me mention that there is no such > thing as a universal class of things that are called "run-time type > violations". At runtime, there is merely correct code and incorrect > code. No, there is more: There is safe and unsafe code (i.e., code that throws exceptions or that potentially just does random things). There are also runtime systems where you have the chance to fix the reason that caused the exception and continue to run your program. The latter play very well with dynamic types / type tags. > To the extent that anything is called a "type" at runtime, this > is a different usage of the word from the usage by which we may define > languages as being statically typed (which means just "typed"). In > typed OO languages, this runtime usage is often called the "class", for > example, to distinguish it from type. What type of person are you to tell other people what terminology to use? ;) Ha! Here I used "type" in just another sense of the word. ;) It is important to know the context in which you are discussing things. For example, "we" Common Lispers use the term "type" as defined in http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_t.htm . You cannot possibly argue that "our" use of the word "type" is incorrect because in "our" context, when we talk about Common Lisp, the use of the word "type" better be consistent with that definition. (You can say that you don't like the definition, that it is unsound, or whatever, but that doesn't change anything here.) > This cleaner terminology eliminates a lot of confusion. For example, it > clarifies that there is no binary division between strongly typed > languages and weakly typed languages, since the division between a "type > error" and any other kind of error is arbitrary, depending only on > whether the type system in a particular language happens to catch that > error. For example, type systems have been defined to try to catch unit > errors in scientific programming, or to catch out-of-bounds array > indices... yet these are not commonly called "type errors" only because > such systems are not in common use. What type system catches division by zero? That is, statically? Would you like to program in such a language? > This isn't just a matter of preference in terminology. The definitions > above (which are, in my experience, used widely by most non-academic > language design discussions) actually limit our understanding of > language design by pretending that certain delicate trade-offs such as > the extent of the type system, or which language behavior is allowed to > be non-deterministic or undefined, are etched in stone. This is simply > not so. If types DON'T mean a compile-time method for proving the > absence of certain program behaviors, then they don't mean anything at > all. Pretending that there's a distinction at runtime between "type > errors" and "other errors" serves only to confuse things and > artificially limit which problems we are willing to concieve as being > solvable by types. Your problem doesn't exist. Just say "types" when you're a
Re: What is Expressiveness in a Computer Language
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?
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Chris Smith wrote: > Pascal Costanza <[EMAIL PROTECTED]> wrote: >> Types can be represented at runtime via type tags. You could insist on >> using the term "dynamically tagged languages", but this wouldn't change >> a lot. Exactly _because_ it doesn't make sense in a statically typed >> setting, the term "dynamically typed language" is good enough to >> communicate what we are talking about - i.e. not (static) typing. > > Okay, fair enough. It's certainly possible to use the same sequence of > letters to mean two different things in different contexts. The problem > arises, then, when Torben writes: > > : That's not really the difference between static and dynamic typing. > : Static typing means that there exist a typing at compile-time that > : guarantess against run-time type violations. Dynamic typing means > : that such violations are detected at run-time. > > This is clearly not using the word "type" to mean two different things > in different contexts. Rather, it is speaking under the mistaken > impression that "static typing" and "dynamic typing" are varieties of > some general thing called "typing." In fact, the phrase "dynamically > typed" was invented to do precisely that. My argument is not really > with LISP programmers talking about types, by which they would mean > approximately the same thing Java programmers mean by "class." My point > here concerns the confusion that results from the conception that there > is this binary distinction (or continuum, or any other simple > relationship) between a "statically typed" and a "dynamically typed" > language. There is an overlap in the sense that some static type systems cover only types as sets of values whose correct use could as well be checked dynamically. Yes, it's correct that more advanced static type systems can provide more semantics than that (and vice versa). Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall wrote: > The conversation I would *really* like to have is the one where we > discuss what all the differences are, functionally, between the two, > and what the implications of those differences are, without trying > to address which approach is "right" or "better", because those are > dependent on the problem domain anyway, and because I can > make up my own mind just fine about which one I prefer. My current take on this is that static typing and dynamic typing are incompatible, at least in their "extreme" variants. The simplest examples I have found are this: - In a statically typed language, you can have variables that contain only first-class functions at runtime that are guaranteed to have a specific return type. Other values are rejected, and the rejection happens at compile time. In dynamically typed languages, this is impossible because you can never be sure about the types of return values - you cannot predict the future. This can at best be approximated. - In a dynamically typed language, you can run programs successfully that are not acceptable by static type systems. 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. (Even without the call to (eval (read)), in Common Lisp the call to (slot-value p 'address) would raise an exception which gives the user a chance to fix things and continue from the point in the control flow where the exception was raised.) I cannot imagine a static type system which has a chance to predict that this program can successfully run without essentially accepting all kinds of programs. At least, development environments for languages like Smalltalk, Common Lisp, Java, etc., make use of such program updates to improve edit-compile-test cycles. However, it is also possible (and done in practice) to use such program updates to minimize downtimes when adding new features to deployed systems. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Matthias Blume wrote: > 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. The example I have given is more important than this statement. > 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. No, that's not what I mean. >> 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. :-) This sort of feature is clearly not meant for you. ;-P Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Rob Thorpe wrote: > 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. Yes, but the question remains how a static type system can deal with this kind of updates. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
David Hopwood wrote: > Pascal Costanza wrote: >> Rob Thorpe wrote: >>> 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. >> Yes, but the question remains how a static type system can deal with >> this kind of updates. > > It's not difficult in principle: > > - for each class [*], define a function which converts an 'old' value of >that class to a 'new' value (the ability to do this is necessary anyway >to support some kinds of upgrade). A default conversion function may be >autogenerated if the class definition has changed only in minor ways. Yep, this is more or less exactly how CLOS does it. (The conversion function is called update-instance-for-redefined-class, and you can provide your own methods on it.) > - typecheck the new program and the conversion functions, using the old >type definitions for the argument of each conversion function, and the >new type definitions for its result. The problem here is: The program is already executing, so this typecheck isn't performed at compile-time, in the strict sense of the word (i.e., before the program is deployed). It may still be a syntactic analysis, but you don't get the kind of guarantees anymore that you typically expect from a static type checker _before_ the program is started in the first place. (It's really important to understand that the idea is to use this for deployed programs - albeit hopefully in a more structured fashion - and not only for debugging. The example I have given is an extreme one that you would probably not use as such in a "real-world" setting, but it shows that there is a boundary beyond which static type systems cannot be used in a meaningful way anymore, at least as far as I can tell.) > - have the debugger apply the conversions to all values, and then resume >the program. In CLOS, this conversion is defined as part of the language proper, but this is mostly because Common Lisp doesn't make a sharp distinction between debugging capabilities and "regular" language features. (I think it's a good thing that there is no strong barrier against having debugging capabilities in a deployed program.) > [*] or nearest equivalent in a non-OO language. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Joachim Durchholz wrote: > Pascal Costanza schrieb: >> (It's really important to understand that the idea is to use this for >> deployed programs - albeit hopefully in a more structured fashion - >> and not only for debugging. The example I have given is an extreme one >> that you would probably not use as such in a "real-world" setting, but >> it shows that there is a boundary beyond which static type systems >> cannot be used in a meaningful way anymore, at least as far as I can >> tell.) > > As soon as the running program can be updated, the distinction between > "static" (compile time) and "dynamic" (run time) blurs. > You can still erect a definition for such a case, but it needs to refer > to the update process, and hence becomes language-specific. In other > words, language-independent definitions of dynamic and static typing > won't give any meaningful results for such languages. > > I'd say it makes more sense to talk about what advantages of static vs. > dynamic typing can be applied in such a situation. > E.g. one interesting topic would be the change in trade-offs: making > sure that a type error cannot occur becomes much more difficult > (particularly if the set of available types can change during an > update), so static typing starts to lose some of its appeal; OTOH a good > type system can give you a lot of guarantees even in such a situation, > even if it might have to revert to the occasional run-time type check, > so static checking still has its merits. I am not opposed to this view. The two examples I have given for things that are impossible in static vs. dynamic type systems were intentionally extreme to make the point that you have to make a choice, that you cannot just blindly throw (instances of) both approaches together. Static type systems potentially change the semantics of a language in ways that cannot be captured by dynamically typed languages anymore, and vice versa. There is, of course, room for research on performing static type checks in a running system, for example immediately after or before a software update is applied, or maybe even on separate type checking on software increments such that guarantees for their composition can be derived. However, I am not aware of a lot of work in that area, maybe because the static typing community is too focused on compile-time issues. Personally, I also don't think that's the most interesting issue in that area, but that's of course only a subjective opinion. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
David Hopwood wrote: > Marshall wrote: >> Chris Smith wrote: >>> Marshall <[EMAIL PROTECTED]> wrote: >>> I think what this highlights is the fact that our existing terminology is not up to the task of representing all the possible design choices we could make. Some parts of dynamic vs. static a mutually exclusive; some parts are orthogonal. >>> Really? I can see that in a strong enough static type system, many >>> dynamic typing features would become unobservable and therefore would be >>> pragmatically excluded from any probable implementations... but I don't >>> see any other kind of mutual exclusion between the two. >> Well, it strikes me that some of what the dynamic camp likes >> is the actual *absence* of declared types, or the necessity >> of having them. > > So why aren't they happy with something like, say, Alice ML, which is > statically typed, but has a "dynamic" type and type inference? I mean > this as a serious question. Note: I haven't yet worked with such a language, but here is my take anyway. A statically type language requires you to think about two models of your program at the same time: the static type model and the dynamic behavioral model. A static type system ensures that these two _different_ (that's important!) perspectives are always in sync. This is especially valuable in settings where you know your domain well and want to rely on feedback by your compiler that you haven't made any mistakes in encoding your knowledge. (A static type system based on type inferencing doesn't essentially change the requirement to think in two models at the same time.) A dynamically typed language is especially well suited when you don't (yet) have a good idea about your domain and you want to use programming especially to explore that domain. Some static typing advocates claim that static typing is still suitable for exploring domains because of the compiler's feedback about the preliminary encoding of your incomplete knowledge, but the disadvantages are a) that you still have to think about two models at the same time when you don't even have _one_ model ready and b) that you cannot just run your incomplete program to see what it does as part of your exploration. A statically typed language with a dynamic type treats dynamic typing as the exception, not as the general approach, so this doesn't help a lot in the second setting (or so it seems to me). A language like Common Lisp treats static typing as the exception, so you can write a program without static types / type checks, but later on add type declarations as soon as you get a better understanding of your domain. Common Lisp implementations like CMUCL or SBCL even include static type inference to aid you here, which gives you warnings but still allows you to run a program even in the presence of static type errors. I guess the feedback you get from such a system is probably not "strong" enough to be appreciated by static typing advocates in the first setting (where you have a good understanding of your domain). Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
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. >> In the terminology I'm suggesting, the object has no type in this language >> (assuming we're talking about a Smalltalk-like language without any type >> system >> extensions). > > I suspect you'll see the Smalltalk version of the objections raised in > response to my post earlier. In other words, whatever terminology you > think is consistent, you'll probably have a tough time convincing > Smalltalkers to stop saying "type" if they did before. If you exclude > "message not understood" as a type error, then I think you're excluding > type errors from Smalltalk entirely, which contradicts the psychological > understanding again. 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. Which view you take probably depends on what your concrete implementation of "message not understood" does. For example, if it simply forwards the message to another object that is known to be able to respond to it, then you remove a potential type error; however, if it pops up a dialog box to ask the user how to continue from here, it is still a type error, but just gives you a way to deal with it at runtime. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
[EMAIL PROTECTED] wrote: > > A statically type language requires you to think about two models of > >> your program at the same time: the static type model and the dynamic >> behavioral model. A static type system ensures that these two >> _different_ (that's important!) perspectives are always in sync. > > I have trouble understanding your use of the wording "Model of a > program". > If it is a system that behaves according to the rules of your program > then > statements about your program should consider *all* possible models. > If it is a formal system that makes statements about properties of your > program > than the static type system is a simplified model that is suitable for > automatic > analysis and your runtime model is in most cases nonexistent. > Can you give a definition of a "model of a program"? Can you explain > why > Lisp doesn't have two (SBCL does do a lot of typechecking and gives > type errors)? I wasn't talking about models that the language implementation may or may not have, but the models that I as a programmer must have in order to convince the compiler to let me program run. Consider a simple expression like 'a + b': In a dynamically typed language, all I need to have in mind is that the program will attempt to add two numbers. In a statically typed language, I additionally need to know that there must a guarantee that a and b will always hold numbers. In a trivial example like this, this doesn't hurt a lot, but can be problematic as soon as the program size grows. >> This is >> especially valuable in settings where you know your domain well and want >> to rely on feedback by your compiler that you haven't made any mistakes >> in encoding your knowledge. (A static type system based on type >> inferencing doesn't essentially change the requirement to think in two >> models at the same time.) > > It is also valuable when you don't know your domain very well and you > want to rely on feedback by your compiler that you haven't made any > mistakes in encoding your limited knowledge I have more or less used exactly the same words in the paragraph that followed the one you cited from my previous posting, and I have already given a reply there. >> A dynamically typed language is especially well suited when you don't >> (yet) have a good idea about your domain and you want to use programming >> especially to explore that domain. our domain). > > In the sense that you can start writing code without the compiler > pointing out > all but the most glaring holes in your program, I agree. I don't know what language environments you are used to, but the Common Lisp compilers I use always point out the most glaring holes in my programs. But maybe I just have trouble understanding your use of the wording "most glaring holes". Can you give a definition of "most glaring holes"? ;) > Most of your > arguments > aren't very convincing and the thruth is that I have seem lisp > programmers using > the debugger to find out that you can't add a number and a hastable. > The static view > was not there and the dynamic view must have been too complicated so > they had > nothing to think about. We have all seen less-than-average programmers who would fail in all kinds of languages. What they do is typically not very illuminating. My goal is not to convince anyone, my goal is to illustrate for those who are interested in getting a possibly different perspective. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Andreas Rossberg wrote: > Pascal Costanza wrote: >> >> Consider a simple expression like 'a + b': In a dynamically typed >> language, all I need to have in mind is that the program will attempt >> to add two numbers. In a statically typed language, I additionally >> need to know that there must a guarantee that a and b will always hold >> numbers. > > I'm confused. Are you telling that you just write a+b in your programs > without trying to ensure that a and b are in fact numbers?? Basically, yes. Note that this is a simplistic example. Consider, instead, sending a message to an object, or calling a generic function, without ensuring that there will be applicable methods for all possible cases. When I get a "message not understood" exception, I can then decide whether that kind of object shouldn't be a receiver in the first place, or else whether I should define an appropriate method. I don't want to be forced to decide this upfront, because either I don't want to be bothered, or maybe I simply can't because I don't understand the domain well enough yet, or maybe I want to keep a hook to be able to update the program appropriately while it is running. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Matthias Blume wrote: > 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. If your view of a running program is that it is a "closed" system, then you're right. However, maybe there are several layers involved, so what appears to be a well-defined behavior from the outside may still be regarded as a type error internally. A very obvious example of this is when you run a program in a debugger. There are two levels involved here: the program signals a type error, but that doesn't mean that the system as a whole is stuck. Instead, the debugger takes over and offers ways to deal with the type error. The very same program run without debugging support would indeed simply be stuck in the same situation. So to rephrase: It depends on whether you use the "message not understood" machinery as a way to provide well-defined behavior for the base level, or rather as a means to deal with an otherwise unanticipated situation. In the former case it extends the language to remove certain type errors, in the latter case it provides a kind of debugging facility (and it indeed may be a good idea to deploy programs with debugging facilities, and not only use debugging tools at development time). This is actually related to the notion of reflection, as coined by Brian C. Smith. In a reflective architecture, you distinguish between various interpreters, each of which interprets the program at the next level. A debugger is a program that runs at a different level than a base program that it debugs. However, the reflective system as a whole is "just" a single program seen from the outside (with one interpreter that runs the whole reflective tower). This distinction between the internal and the external view of a reflective system was already made by Brian Smith. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Chris Smith wrote: > Pascal Costanza <[EMAIL PROTECTED]> wrote: >> What about this: You get a type error when the program attempts to >> invoke an operation on values that are not appropriate for this operation. >> >> Examples: adding numbers to strings; determining the string-length of a >> number; applying a function on the wrong number of parameters; applying >> a non-function; accessing an array with out-of-bound indexes; etc. > > Hmm. I'm afraid I'm going to be picky here. I think you need to > clarify what is meant by "appropriate". No, I cannot be a lot clearer here. What operations are appropriate for what values largely depends on the intentions of a programmer. Adding a number to a string is inappropriate, no matter how a program behaves when this actually occurs (whether it continues to execute the operation blindly, throws a continuable exception, or just gets stuck). > If you mean "the operation will > not complete successfully" as I suspect you do, then we're closer... No, we're not. You're giving a purely technical definition here, that may or may not relate to the programmer's (or "designer's") understanding of the domain. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall wrote: > I am sceptical of the idea that when programming in a dynamically > typed language one doesn't have to think about both models as well. > I don't have a good model of the mental process of working > in a dynamically typed language, but how could that be the case? > (I'm not asking rhetorically.) Do you then run your program over > and over, mechanically correcting the code each time you discover > a type error? In other words, if you're not thinking of the type model, > are you using the runtime behavior of the program as an assistant, > the way I use the static analysis of the program as an assistant? Yes. > I don't accept the idea about pairing the appropriateness of each > system according to whether one is doing exploratory programming. > I do exploratory programming all the time, and I use the static type > system as an aide in doing so. Rather I think this is just another > manifestation of the differences in the mental processes between > static typed programmers and dynamic type programmers, which > we are beginning to glimpse but which is still mostly unknown. Probably. > Oh, and I also want to say that of all the cross-posted mega threads > on static vs. dynamic typing, this is the best one ever. Most info; > least flames. Yay us! Yay! :) Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall wrote: > Pascal Costanza wrote: >> Consider a simple expression like 'a + b': In a dynamically typed >> language, all I need to have in mind is that the program will attempt to >> add two numbers. In a statically typed language, I additionally need to >> know that there must a guarantee that a and b will always hold numbers. > > I still don't really see the difference. > > I would not expect that the dynamic programmer will be > thinking that this code will have two numbers most of the > time but sometimes not, and fail. I would expect that in both > static and dynamic, the thought is that that code is adding > two numbers, with the difference being the static context > gives one a proof that this is so. There is a third option: it may be that at the point where I am writing this code, I simply don't bother yet whether a and b will always be numbers. In case something other than numbers pop up, I can then make a decision how to proceed from there. > In this simple example, > the static case is better, but this is not free, and the cost > of the static case is evident elsewhere, but maybe not > illuminated by this example. Yes, maybe the example is not the best one. This kind of example, however, occurs quite often when programming in an object-oriented style, where you don't know yet what objects will and will not respond to a message / generic function. Even in the example above, it could be that you can give an appropriate definition for + for objects other than numbers. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall wrote: > Joe Marshall wrote: >> That's the important point: I want to run broken code. > > I want to make sure I understand. I can think of several things > you might mean by this. It could be: > 1) I want to run my program, even though I know parts of it > are broken, because I think there are parts that are not broken > and I want to try them out. > 2) I want to run my program, even though it is broken, and I > want to run right up to a broken part and trap there, so I can > use the runtime facilities of the language to inspect what's > going on. > > >> I want to run >> as much of the working fragments as I can, and I want a `safety net' to >> prevent me from performing undefined operations, but I want the safety >> net to catch me at the *last* possible moment. > > This statement is interesting, because the conventional wisdom (at > least as I'm used to hearing it) is that it is best to catch bugs > at the *first* possible moment. But I think maybe we're talking > about different continua here. The last last last possible moment > is after the software has shipped to the customer, and I'm pretty > sure that's not what you mean. I think maybe you mean something > more like 2) above. Nowadays, we have more options wrt what it means to "ship" code. It could be that your program simply runs as a (web) service to which you have access even after the customer has started to use the program. See http://www.paulgraham.com/road.html for a good essay on this idea. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying "latently-typed language" is making a category mistake
Vesa Karvonen wrote: > In comp.lang.functional Anton van Straaten <[EMAIL PROTECTED]> wrote: > [...] >> I reject this comparison. There's much more to it than that. The point >> is that the reasoning which programmers perform when working with an >> program in a latently-typed language bears many close similiarities to >> the purpose and behavior of type systems. > >> This isn't an attempt to jump on any bandwagons, it's an attempt to >> characterize what is actually happening in real programs and with real >> programmers. I'm relating that activity to type systems because that is >> what it most closely relates to. > [...] > > I think that we're finally getting to the bottom of things. While reading > your reponses something became very clear to me: latent-typing and latent- > types are not a property of languages. Latent-typing, also known as > informal reasoning, is something that all programmers do as a normal part > of programming. To say that a language is latently-typed is to make a > category mistake, because latent-typing is not a property of languages. I disagree with you and agree with Anton. Here, it is helpful to understand the history of Scheme a bit: parts of its design are a reaction to what Schemers perceived as having failed in Common Lisp (and other previous Lisp dialects). One particularly illuminating example is the treatment of nil in Common Lisp. That value is a very strange beast in Common Lisp because it stands for several concepts at the same time: most importantly the empty list and the boolean false value. Its type is also "interesting": it is both a list and a symbol at the same time. It is also "interesting" that its quoted value is equivalent to the value nil itself. This means that the following two forms are equivalent: (if nil 42 4711) (if 'nil 42 4711) Both forms evaluate to 4711. It's also the case that taking the car or cdr (first or rest) of nil doesn't give you an error, but simply returns nil as well. The advantage of this design is that it allows you to express a lot of code in a very compact way. See http://www.apl.jhu.edu/~hall/lisp/Scheme-Ballad.text for a nice illustration. The disadvantage is that it is mostly impossible to have a typed view of nil, at least one that clearly disambiguates all the cases. There are also other examples where Common Lisp conflates different types, and sometimes only for special cases. [1] Now compare this with the Scheme specification, especially this section: http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-6.html#%25_sec_3.2 This clearly deviates strongly from Common Lisp (and other Lisp dialects). The emphasis here is on a clear separation of all the types specified in the Scheme standard, without any exception. This is exactly what makes it straightforward in Scheme to have a latently typed view of programs, in the sense that Anton describes. So latent typing is a property that can at least be enabled / supported by a programming language, so it is reasonable to talk about this as a property of some dynamically typed languages. Pascal [1] Yet Common Lisp allows you to write beautiful code, more often than not especially _because_ of these "weird" conflations, but that's a different topic. -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying "latently-typed language" is making a category mistake
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 Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying "latently-typed language" is making a category mistake
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. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying "latently-typed language" is making a category mistake
Patricia Shanahan wrote: > Pascal Costanza wrote: >> 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. > > To prove Turing-completeness of ACL2 from Turing-completeness of Common > Lisp you would need to run the reduction the other way round, showing > that any Common Lisp program can be converted to, or emulated by, an > ACL2 program. Sorry, obviously I was far from being clear. ACL2 is not Turing-complete. All iterations must be expressed in terms of well-founded recursion. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Saying "latently-typed language" is making a category mistake
Chris Uppal wrote: > Pascal Costanza wrote: > >> Sorry, obviously I was far from being clear. ACL2 is not >> Turing-complete. All iterations must be expressed in terms of >> well-founded recursion. > > How expressive does that end up being for real problems ? I mean obviously > in > some sense it's crippling, but how much of a restiction would that be for > non-accademic programming. I don't know your definition of "real problem" ;), but ACL2 is definitely used in industrial settings. See http://www.cs.utexas.edu/users/moore/publications/how-to-prove-thms/intro-to-acl2.pdf Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall wrote: > Anton van Straaten wrote: >> But beyond that, there's an issue here about the definition of "the >> language". When programming in a latently-typed language, a lot of >> action goes on outside the language - reasoning about static properties >> of programs that are not captured by the semantics of the language. >> >> This means that there's a sense in which the language that the >> programmer programs in is not the same language that has a formal >> semantic definition. As I mentioned in another post, programmers are >> essentially mentally programming in a richer language - a language which >> has informal (static) types - but the code they write down elides this >> type information, or else puts it in comments. >> >> We have to accept, then, that the formal semantic definitions of >> dynamically-checked languages are incomplete in some important ways. >> Referring to those semantic definitions as "the language", as though >> that's all there is to the language in a broader sense, is misleading. >> >> In this context, the term "latently-typed language" refers to the >> language that a programmer experiences, not to the subset of that >> language which is all that we're typically able to formally define. > > That is starting to get a bit too mystical for my tastes. To paraphrase Abelson & Sussman: Programs must be written for people to read, and only incidentally for compilers to check their types. ;) Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Joachim Durchholz wrote: > Andreas Rossberg schrieb: >> >> 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. > > Here's a matrix how most people that I know would fill in with terminology: > > | Statically | Not | > | typed| statically | > | | typed | >-+--+-+ >typesafe | "strongly| Dynamically | > | typed" | typed | > | (ML, Pascal) | (Lisp) | >-+--+-+ >not | (no common | "untyped" | >typesafe | terminology) | | > | (C) | (Assembly) | >-+--+-+ > > (Terms in quotes are challenged on a regular basis, or rarely if ever > applied.) > > With the above terminology, it becomes clear that the opposite if > "(statically) typed" isn't "statically untyped", but "not statically > typed". "Statically typed" and "dynamically typed" aren't even > opposites, they just don't overlap. > > Another observation: type safeness is more of a spectrum than a clearcut > distinction. Even ML and Pascal have ways to circumvent the type system, > and even C is typesafe unless you use unsafe constructs. > IOW from a type-theoretic point of view, there is no real difference > between their typesafe and not typesafe languages in the "statically > typed" column; the difference is in the amount of unsafe construct usage > in practial programs. It's also relevant how straightforward it is to distinguish between safe and unsafe code, how explicit you have to be when you use unsafe code, how likely it is that you accidentally use unsafe code without being aware of it, what the generally accepted conventions in a language community are, etc. pp. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
David Hopwood wrote:
> Pascal Costanza wrote:
>> 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.
>
> This makes essentially all run-time errors (including assertion failures,
> etc.) "type errors". It is neither consistent with, nor any improvement
> on, the existing vaguely defined usage.
Nope. This is again a matter of getting the levels right.
Consider division by zero: appropriate arguments for division are
numbers, including the zero. The dynamic type check will typically not
check whether the second argument is zero, but will count on the fact
that the processor will raise an exception one level deeper.
This is maybe better understandable in user-level code. Consider the
following class definition:
class Person {
String name;
int age;
void buyPorn() {
if (< this.age 18) throw new AgeRestrictionException();
...
}
}
The message p.buyPorn() is a perfectly valid message send and will pass
both static and dynamic type tests (given p is of type Person in the
static case). However, you will still get a runtime error.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Chris Smith wrote:
> Pascal Costanza <[EMAIL PROTECTED]> wrote:
>> Consider division by zero: appropriate arguments for division are
>> numbers, including the zero. The dynamic type check will typically not
>> check whether the second argument is zero, but will count on the fact
>> that the processor will raise an exception one level deeper.
>
> Of course zero is not appropriate as a second argument to the division
> operator! I can't possibly see how you could claim that it is. The
> only reasonable statement worth making is that there doesn't exist a
> type system in widespread use that is capable of checking this.
...and this is typically not even checked at the stage where type tags
are checked in dynamically-typed languages. Hence, it is not a type
error. (A type error is always what you define to be a type error within
a given type system, right?)
Note, this example was in response to David's reply that my definition
turns every runtime error into a type error. That's not the case, and
that's all I want to say.
>> This is maybe better understandable in user-level code. Consider the
>> following class definition:
>>
>> class Person {
>>String name;
>>int age;
>>
>>void buyPorn() {
>> if (< this.age 18) throw new AgeRestrictionException();
>> ...
>>}
>> }
>>
>> The message p.buyPorn() is a perfectly valid message send and will pass
>> both static and dynamic type tests (given p is of type Person in the
>> static case).
>
> It appears you've written the code above to assume that the type system
> can't cerify that age >= 18... otherwise, the if statement would not
> make sense.
Right.
> It also looks like Java, in which the type system is indeed
> not powerfule enough to do that check statically.
Right.
> However, it sounds as
> if you're claiming that it wouldn't be possible for the type system to
> do this?
No. I only need an example where a certain error is not a type error in
_some_ language. I don't need to make a universal claim here.
> If so, that's not correct. If such a thing were checked at
> compile-time by a static type check, then failing to actually provide
> that guarantee would be a type error, and the compiler would tell you
> so.
That's fine, but not relevant in this specific subplot.
Pascal
--
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
--
http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Chris Smith wrote: > Pascal Costanza <[EMAIL PROTECTED]> wrote: >> Chris Smith wrote: >>> Of course zero is not appropriate as a second argument to the division >>> operator! I can't possibly see how you could claim that it is. The >>> only reasonable statement worth making is that there doesn't exist a >>> type system in widespread use that is capable of checking this. >> ...and this is typically not even checked at the stage where type tags >> are checked in dynamically-typed languages. Hence, it is not a type >> error. (A type error is always what you define to be a type error within >> a given type system, right?) > > Sure, it's not a type error for that language. > >> Note, this example was in response to David's reply that my definition >> turns every runtime error into a type error. That's not the case, and >> that's all I want to say. > > But your definition does do that. Your definition of a type error was > when a program attempts to invoke an operation on values that are not > appropriate for this operation. In my definition, I didn't say who or what decides what values are appropriate for operations. > Clearly, in this example, the program > is invoking an operation (division) on values that are not appropriate > (zero for the second argument). Hence, if your definition really is a > definition, then this must qualify. Here, you are asking more from dynamic type systems than any existing type system provides. The definition of what is considered to be a type error and what not is always part of the specification of a type system. >>> However, it sounds as >>> if you're claiming that it wouldn't be possible for the type system to >>> do this? >> No. I only need an example where a certain error is not a type error in >> _some_ language. I don't need to make a universal claim here. > > Definitions are understood to be statements of the form "if and only > if". They assert that /everything/ that fits the definition is > describable by the word, and /everything/ that doesn't is not > describable by the word. If that's not what you meant, then we are > still in search of a definition. > > If you want to make a statement instead of the sort you've implied > above... namely that a type error is *any* error that's raised by a type > system, then that's fine. It certainly brings us closer to static > types. Now, though, the task is to define a type system without making > a circular reference to types. You've already rejected the statement > that all runtime errors are type errors, because you specifically reject > the division by zero case as a type error for most languages. What is > that distinction? I don't need such a distinction. I can just define what is covered by a type system and what is not. All type systems work that way. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is a type error?
Chris Smith wrote: > Pascal Costanza <[EMAIL PROTECTED]> wrote: >>> Clearly, in this example, the program >>> is invoking an operation (division) on values that are not appropriate >>> (zero for the second argument). Hence, if your definition really is a >>> definition, then this must qualify. >> Here, you are asking more from dynamic type systems than any existing >> type system provides. The definition of what is considered to be a type >> error and what not is always part of the specification of a type system. > > No, I'm not. Were we to follow this path of definition, it would not > require that dynamic type systems catch ALL type errors; only that they > catch some. Not that it matters, though. I am analyzing the logical > consequences of your own definition. If those logical consequences were > impossible to fulfill, that would be an even more convincing reason to > find a new definition. Concepts of fairness don't enter into the > equation. Yes it does. All static type systems define only a strict subset of all possible errors to be covered, and leave others as runtime errors. The same holds for dynamic type systems. >>> If you want to make a statement instead of the sort you've implied >>> above... namely that a type error is *any* error that's raised by a type >>> system, then that's fine. It certainly brings us closer to static >>> types. Now, though, the task is to define a type system without making >>> a circular reference to types. You've already rejected the statement >>> that all runtime errors are type errors, because you specifically reject >>> the division by zero case as a type error for most languages. What is >>> that distinction? >> I don't need such a distinction. I can just define what is covered by a >> type system and what is not. All type systems work that way. > > You've got to define something... or, I suppose, just go on using words > without definitions. You claimed to give a definition, though. > > I have been led by others to believe that the right way to go in the > dynamic type sense is to first define type errors, and then just call > anything that finds type errors a type system. That would work, but it > would require a type error. You seem to want to push that work off of > the word "type error" and back onto "type system", but that requires > that you define what a type system is. I didn't know I was supposed to give a definition. > Incidentally, in the case of static type systems, we define the system > (for example, using the definition given from Pierce many times this > thread), and then infer the definition of types and type errors from > there. Because a solid definition has been given first for a type > system without invoking the concepts of types or type errors, this > avoids being circular. Do you mean this one? "A type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying phrases according to the kinds of values they compute." This isn't really such a strong definition because it shifts the problem of what exactly a type system is to finding a definition for the word "kind". But if this makes you happy, here is an attempt: "A dynamic type system is a tractable syntactic method for proving the absence of certain program behaviors by classifying values according to their kinds." Basically, this correlates with the typical approach of using tags to indicate the type/kind/class of values. And indeed, this is what dynamic type systems typically do: they check tags associated with values. Other kinds of runtime errors are not raised because of such checks, but because of other reasons. Therefore, there is naturally a distinction between runtime errors that are type errors and those that are not. I am not convinced that this definition of mine is a lot clearer than what I have said before, but I am also not convinced that Pierce's definition is any clearer either. It is merely a characterization of what static type systems do. The preciseness comes into play when actually defining a type system: then you have to give definitions what the errors at runtime are that you want to prove absent by way of the static type system, give the typing rules for the type system, and then prove soundness by showing that the typing rules correlate precisely to the runtime errors in the first stage. Since you have to map two different views of the same thing to each other you have to be precise in giving definitions that you can then successfully use in your proofs. In dynamic type system, this level of precision is not neces
Re: What is a type error?
Marshall wrote: > Pascal Costanza wrote: >> Consider division by zero: appropriate arguments for division are >> numbers, including the zero. > > A bold assertion! > > The general question is, what do we do about partial functions? > > >> The dynamic type check will typically not >> check whether the second argument is zero, but will count on the fact >> that the processor will raise an exception one level deeper. > > This is an implementation artifact, and hence not relevant to our > understanding of the issue. No, it's not. I am pretty sure that you can model this formally. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
David Hopwood wrote: > Marshall wrote: >> The real question is, are there some programs that we >> can't write *at all* in a statically typed language, because >> they'll *never* be typable? > > In a statically typed language that has a "dynamic" type, all > dynamically typed programs are straightforwardly expressible. What about programs where the types change at runtime? Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Marshall wrote: > Joe Marshall wrote: >> Marshall wrote: >> It isn't clear to me which programs we would have to give up, either. >> I don't have much experience in sophisticated typed languages. It is >> rather easy to find programs that baffle an unsophisticated typed >> language (C, C++, Java, etc.). > > C and Java, certainly, but I'm wary these days about making > any statement about limitations on C++'s type system, for it is > subtle and quick to anger. > >> Looking back in comp.lang.lisp, I see these examples: >> >> (defun noisy-apply (f arglist) >> (format t "I am now about to apply ~s to ~s" f arglist) >> (apply f arglist)) >> >> (defun blackhole (argument) >> (declare (ignore argument)) >> #'blackhole) >> > The noisy-apply function I think I understand; it's generic on the > entire arglist. In fact, if I read it correctly, it's even generic > on the *arity* of the function, which is actually pretty impressive. > True? This is an issue I've been wrestling with in my own type > system investigations: how to address genericity across arity. > > Does noisy-apply get invoked the same way as other functions? > That would be cool. > > As to the black hole function, could you explain it a bit? I apologize > for my lisp-ignorance. I am sure there is a world of significance > in the # ' on the third line, but I have no idea what it is. You can ignore the #'. In Scheme this as follows: (define blackhole (argument) blackhole) It just means that the function blackhole returns the function blackhole. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
David Hopwood wrote: > Pascal Costanza wrote: >> David Hopwood wrote: >>> Marshall wrote: >>> >>>> The real question is, are there some programs that we >>>> can't write *at all* in a statically typed language, because >>>> they'll *never* be typable? >>> In a statically typed language that has a "dynamic" type, all >>> dynamically typed programs are straightforwardly expressible. >> What about programs where the types change at runtime? > > Staged compilation is perfectly compatible with static typing. > Static typing only requires that it be possible to prove absence > of some category of type errors when the types are known; it > does not require that all types are known before the first-stage > program is run. Can you change the types of the program that is already running, or are the levels strictly separated? > There are, however, staged compilation systems that guarantee that > the generated program will be typeable if the first-stage program > is. ...and I guess that this reduces again the kinds of things you can express. > (It's clear that to compare the expressiveness of statically and > dynamically typed languages, the languages must be comparable in > other respects than their type system. Staged compilation is the > equivalent feature to 'eval'.) If it is equivalent to eval (i.e., executed at runtime), and the static type checker that is part of eval yields a type error, then you still get a type error at runtime! Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
David Hopwood wrote: > Pascal Costanza wrote: >> David Hopwood wrote: >>> Pascal Costanza wrote: >>>> David Hopwood wrote: >>>>> Marshall wrote: >>>>> >>>>>> The real question is, are there some programs that we >>>>>> can't write *at all* in a statically typed language, because >>>>>> they'll *never* be typable? >>>>> In a statically typed language that has a "dynamic" type, all >>>>> dynamically typed programs are straightforwardly expressible. >>>> What about programs where the types change at runtime? >>> Staged compilation is perfectly compatible with static typing. >>> Static typing only requires that it be possible to prove absence >>> of some category of type errors when the types are known; it >>> does not require that all types are known before the first-stage >>> program is run. >> Can you change the types of the program that is already running, or are >> the levels strictly separated? > > In most staged compilation systems this is intentionally not permitted. > But this is not a type system issue. You can't change the types in a > running program because you can't change the program, period. And you > can't do that because most designers of these systems consider directly > self-modifying code to be a bad idea (I agree with them). 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. There are at least systems that a lot of people rely on (the JVM, .NET) that achieve runtime efficiency primarily by executing what is essentially self-modifying code. These runtime optimization systems have been researched primarily for the language Self, and also implemented in Strongtalk, CLOS, etc., to various degrees. 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. > 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. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Matthias Blume wrote: > 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. I am not arguing against static type systems. I am just responding to the question what the things are that you cannot do in statically typed languages. > [ ... ] > >> 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. 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. 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. >>> 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. Pascal [1] BTW, that's also the approach taken in CLOS. -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What is Expressiveness in a Computer Language
Matthias Blume wrote: > 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. ...no, it will throw exceptions that you can catch and handle, maybe interactively. >> 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. ...and yet this requirement sometimes comes up. >>>>> 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? In CLOS, the test is indeed already there from the beginning. It's part of the runtime semantics. The translation of the data is handled by 'update-instance-for-redefined-class, which is a generic function for which you can define your own methods. So this is user-extensible and can, for example, be provided as part of the program update. Furthermore, slot accesses typically go through generic functions (aka setters and getters in other languages) for which you can provide methods that can perform useful behavior in case the corresponding slots have gone. These methods can also be provided as part of the program update. Note that I am not claiming that CLOS provides the perfect solution, but it seems to work reasonably well that people use it in practice. > 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? Presumably, objects have references to their class metaobjects which contain version information and references to more current versions of themselves. This is not rocket science. > 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. Maybe this feature just isn't made for you. Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Reddit broke - should have remained on Lisp?
[EMAIL PROTECTED] wrote: > Kay Schluehr wrote: >> Please, since this is a Python+Lisp cross-thread and you seem to have >> background info: can you explain why Lisp hackers have turned >> themselves into Python newbies for Reddit impl. and finally complain >> about the language switch? What was cause for their decision to use >> Python in the first place? > > Basically, it was the same complaint everyone else has about common > lisp. It's an awesome language, but there are no reliable standard > crossplatform (and free) libraries for threading and sockets. They > were using FreeBSD as a server, and (trying to) use powerbooks as a dev > platform, and that seriously restricted viable CL implemenations. > > http://redditblog.blogspot.com/2005/12/night-of-living-python.html > http://redditblog.blogspot.com/2005/12/on-lisp.html Compare this to that report: http://groups.google.com/group/comp.lang.lisp/msg/33fec2394f38546b Pascal -- 3rd European Lisp Workshop July 3 - Nantes, France - co-located with ECOOP 2006 http://lisp-ecoop06.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Ken Tilton wrote: > What is up the power continuum from Lisp? 3-Lisp. ;) Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: > "Alex Mizrahi" <[EMAIL PROTECTED]> writes: >> we can implement Scheme's call-with-current-continuation first :) >> it's relatively easy -- just a code walker that coverts everyting into CPS. > > It's not enough to convert to CPS, you have to be able to actually > save the continuation when you switch to another one, so you can go > back to the first one later. You get this for free once your program is in CPS. (This is true for any language, btw. It's just that it's easier to abstract away from the details of CPS in Lisp.) Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
I V wrote: > One of the things I've always found off-putting about lisp as that all the > syntax looks the same. In Algol-derived languages, each syntactic > construct has a fairly distinctive appearance, so when, for instance, I > encounter a for loop, I can quickly recognize that that's what it is, and > bracket out the "scaffolding" and pick out the details that interest me. > With lisp, I can't do that, I have to read through the sexp, decide on > what syntax it is, and then remind myself where to look for the relevant > specific details. May you have tried the wrong Lisp dialects so far: (loop for i from 2 to 10 by 2 do (print i)) This is Common Lisp. (Many Lisp and Scheme tutorials teach you that you should implement this using recursion, but you really don't have to. ;) Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote:
> Pascal Costanza <[EMAIL PROTECTED]> writes:
>> May you have tried the wrong Lisp dialects so far:
>>
>> (loop for i from 2 to 10 by 2
>>do (print i))
>
> The loop language is so complicated and confusing that I never
> bothered trying to learn it.
You can start with loop by using only the simple and straightforward
constructs, and slowly move towards the more complicated cases when
necessary. The nice thing about loop is that with some practice, you can
write code that more or less reads like English.
> I always used simpler primitives to
> write loops and it was always enough.
No language construct is so simple that it cannot be replaced with a
combination of simpler primitives.
>> This is Common Lisp. (Many Lisp and Scheme tutorials teach you that
>> you should implement this using recursion, but you really don't have
>> to. ;)
>
> You can't really use that much recursion in Lisp because of the lack
> of guaranteed TCO. I think that makes it reasonable to say that
> Scheme is a functional language but Lisp is not. ("Functional" = it's
> reasonable to code in a style where the only way to connect variables
> to values is lambda binding (maybe through syntax sugar), so all loops
> are implemented with recursion).
All Common Lisp implementations that I am aware of provide ways to
enable TCO, so it's definitely possible to program in a functional style
if you want to. It's just that the ANSI Common Lisp specification
doesn't guarantee this, but this doesn't matter much. The only downside
is that there is no common interface to enable TCO - that would indeed
be an improvement. The upside is that you can switch TCO off if you want
to, which for example may improve debugging.
It's correct that Scheme has a stronger tendency towards functional
programming than Lisp has.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
--
http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: > Pascal Costanza <[EMAIL PROTECTED]> writes: >> You can start with loop by using only the simple and straightforward >> constructs, and slowly move towards the more complicated cases when >> necessary. The nice thing about loop is that with some practice, you >> can write code that more or less reads like English. > > Yeah, but I'd also get English-like imprecision. Anyway, If I wanted > to write code that reads like English, I'd write in Cobol. That's the neat thing in Lisp: You can stay in Lisp if you want to write code in a different style. No need to switch your whole tool chain. >> All Common Lisp implementations that I am aware of provide ways to >> enable TCO, so it's definitely possible to program in a functional >> style if you want to. It's just that the ANSI Common Lisp >> specification doesn't guarantee this, > > Yes; I'd rather go by what the standard says than rely on > implementation-dependent hacks. You shouldn't limit yourself to what some standard says. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Pillsy wrote: > Ken Tilton wrote: > [...] >> That was my stance for about seven years of intense Lisp. Then the >> author of Practical Common Lisp did a nice job of breaking the whole >> mess up into sensible chunks and I picked it up. If one programs Lisp, >> one should learn Loop -- it is definitely worth the bother. I def regret >> not learning it sooner. > > When I first read PCL (which was my introduction to Lisp) I thought > LOOP was really neato. Once I actually started using it for things that > weren't so simple, I began to really hate it. I think that having a > specialized mini-language for iteration is a superb idea, but I don't > think LOOP is it. > > That being said, there's a portable alternatives out there that I like > way better, and I still use LOOP for dashing stuff off one-liners at > the REPL. If you hate LOOP then you don't have to use it. There's an important lesson to learn here: Not all language constructs are supposed to be loved by everyone. ;) Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: merits of Lisp vs Python
Paul Rubin wrote: > jayessay <[EMAIL PROTECTED]> writes: >>> It's simply that newer language designs by definition have more of an >>> experience base to build on than older ones, if the designers care to >>> make use of it. >> Agreed. Indeed, that was the underlying guiding principle in putting >> together CL. *ML being older than CL didn't have any more opportunity >> in this respect. > > You're forgetting that CL tried to be more or less backwards > compatible with its predecessors, at least compatible enough that > large systems in Maclisp, Interlisp, Zetalisp, etc. could be ported > without too much pain. Therefore, CL could not erase too many > mistakes from the past. Scheme went somewhat further than CL at > cleaning things up, and Scheme's aficionados think CL is a clumsy old > kludge as a result. But it's still a Lisp dialect. The ML's, for > their part, were able to start from scratch. It's funny: Language designers have been spending a lot of effort over the decades on designing language constructs that help to improve the opportunities to reuse of software libraries. Yet every five years, or so, new languages and technologies come up that require everyone to start from scratch. Starting from scratch is even being applauded, due to some mythical belief that "this time, we are going to get it all right." Something seems wrong here... Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: What are OOP's Jargons and Complexities?
alex goldman wrote: > John McGrath wrote: > >>Unfortunately, there is no >>consensus as to what the term means. > > If the language allows the programmer to write programs from the 'slack' > domain, by saying "just trust me on this", then it's not strongly typed. > > What other meanings are there? I wasn't aware of the lack of consensus. There is a difference between getting a core dump when you invoke undefined behavior on some object, or just getting an exception. You can programmatically react to an exception to do something meaningful but not to a core dump. Some people use the term weak typing to refer to languages that potentially core dump whereas they use the term strong typing for languages that don't. Pascal -- 2nd European Lisp and Scheme Workshop July 26 - Glasgow, Scotland - co-located with ECOOP 2005 http://lisp-ecoop05.bknr.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Lisp-like macros in Python?
Converge is a Python-style language with a macro facility. See http://convergepl.org/ Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Microsoft's Dynamic Languages Runtime (DLR)
sturlamolden wrote: > On Monday Microsoft announced a new runtime for dynamic languages, > which they call "DLR". It sits on top of the conventional .NET runtime > (CLR) and provides services for dynamically typed languages like > Python or Lisp (thus the cross-posting). Apparently is is distributed > under a BSD-like open-source license. > > I am curious to know how it performs in comparison to CPython and an > efficient compiled Lisp like CMUCL. Speed is a major problem with > CPython but not with .NET or CMUCL, so it will be interesting to see > how the DLR performs in comparison. It would be great to finally see a > Python that runs on steroids, but knowing M$ bloatware my expectations > are not too high. > > Has anyone looked at the DLR yet? What are your impression? So far, there is not a lot of information available. The only statement about the technology I have read so far is that the DLR is a thin layer on top of the CLR. This doesn't say a lot. So it's hard to tell whether this is a (good) marketing stunt or whether there are actual substantial improvement to the infrastructure. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Microsoft's Dynamic Languages Runtime (DLR)
Fuzzyman wrote: > On May 2, 8:20 pm, Pascal Costanza <[EMAIL PROTECTED]> wrote: >> sturlamolden wrote: >>> On Monday Microsoft announced a new runtime for dynamic languages, >>> which they call "DLR". It sits on top of the conventional .NET runtime >>> (CLR) and provides services for dynamically typed languages like >>> Python or Lisp (thus the cross-posting). Apparently is is distributed >>> under a BSD-like open-source license. >>> I am curious to know how it performs in comparison to CPython and an >>> efficient compiled Lisp like CMUCL. Speed is a major problem with >>> CPython but not with .NET or CMUCL, so it will be interesting to see >>> how the DLR performs in comparison. It would be great to finally see a >>> Python that runs on steroids, but knowing M$ bloatware my expectations >>> are not too high. >>> Has anyone looked at the DLR yet? What are your impression? >> So far, there is not a lot of information available. The only statement >> about the technology I have read so far is that the DLR is a thin layer >> on top of the CLR. This doesn't say a lot. >> >> So it's hard to tell whether this is a (good) marketing stunt or whether >> there are actual substantial improvement to the infrastructure. > > Well, they're now implementing four dynamic languages on top of the > DLR - not just IronPython. > > * IronPython > * IronRuby > * Java Script > * VBx (a dynamic version of VB) > > The DLR provides a dynamic type system and hosting environment for > dynamic languages. > > The nice part is that the DLR runs on top of the 'Core CLR' which > ships with Silverlight. This means that apps. that run in Silverlight > are secure - so you can run an IronPython console in the browser... That still doesn't explain what DLR actually does. You can implement these languages on top of the JVM as well. You could implement them on any Turing-complete language, for that matter. The interesting question how well integrated such an implementation is. However, Jim Hugunin seems to be willing to give more details on his blog - the recent entry gives hints that there is indeed something interesting going on. I'm still waiting for the meat, though... Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Why stay with lisp when there are python and perl?
Jon Harrop wrote: > It is worth noting that eager, statically-typed languages like OCaml and F# > are many times faster than the other languages at this task. This is > precisely the forte of OCaml and F#, manipulating trees and graphs. Here is a page that sums up some important observations about benchmarks: http://www.ccs.neu.edu/home/will/Twobit/bmcrock.temp.html Especially: - "With modern superscalar architectures, 5-level memory hierarchies, and wide data paths, changing the alignment of instructions and data can easily change the performance of a program by 20% or more, and Hans Boehm has witnessed a spectacular 100% variation in user CPU time while holding the executable file constant. Since much of this alignment is determined by the linker, loader, and garbage collector, most individual compiler optimizations are in the noise. To evaluate a compiler properly, one must often look at the code that it generates, not the timings." - "The execution time of a program is often dominated by the time spent in very small pieces of code. If an optimizing compiler happens to do a particularly good job of optimizing these hot spots, then the program will run quickly. If a compiler happens to do an unusually poor job of optimizing one or more of these hot spots, then the program will run slowly." - "If the hot spots occur within library routines, then a compiler may not affect the performance of the program very much. Its performance may be determined by those library routines." - "The performance of a benchmark, even if it is derived from a real program, may not help to predict the performance of similar programs that have different hot spots." Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
[CfP] Dynamic Languages Symposium 2007
* * * Dynamic Languages Symposium 2007 * *at ooPSLA 2007 - http://www.oopsla.org * * * * Montreal, Quebec, Canada, October 22, 2007 * * * * http://www.swa.hpi.uni-potsdam.de/dls07/ * * * Important dates: * Submission of papers: June 1, 2007 *hard deadline* * Author notification: June 30, 2007 * Final versions due: July 7, 2007 * DLS 2007: October 22, 2007 * OOPSLA 2007: October 21-25, 2007 Scope: ** The Dynamic Languages Symposium (DLS) at OOPSLA 2007 in Montreal, Canada, is a forum for discussion of dynamic languages, their implementation and application. While mature dynamic languages including Smalltalk, Lisp, Scheme, Self, and Prolog continue to grow and inspire new converts, a new generation of dynamic scripting languages such as Python, Ruby, PHP, and JavaScript are successful in a wide range of applications. DLS provides a place for researchers and practitioners to come together and share their knowledge, experience, and ideas for future research and development. DLS 2007 invites high quality papers reporting original research, innovative contributions or experience related to dynamic languages, their implementation and application. Accepted Papers will be published in the OOPSLA conference companion and the ACM Digital Library. Areas of interest include but are not limited to: * * Innovative language features and implementation techniques * Development and platform support, tools * Interesting applications * Domain-oriented programming * Very late binding, dynamic composition, and runtime adaptation * Reflection and meta-programming * Software evolution * Language symbiosis and multi-paradigm languages * Dynamic optimization * Hardware support * Experience reports and case studies * Educational approaches and perspectives * Object-oriented, aspect-oriented, and context-oriented programming Submissions and proceedings *** We invite original contributions that neither have been published previously nor are under review by other refereed events or publications. Research papers should describe work that advances the current state of the art. Experience papers should be of broad interest and should describe insights gained from substantive practical applications. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. Papers are to be submitted electronically at http://www.dcl.hpi.uni-potsdam.de/dls2007/ in PDF format. Submissions must not exceed 12 pages and need to use the ACM format, templates for which can be found at http://www.acm.org/sigs/pubs/proceed/template.html. Program chairs: *** * Pascal Costanza, Programming Technology Lab, Vrije Universiteit Brussel, Belgium * Robert Hirschfeld, Hasso-Plattner-Institut, University of Potsdam, Germany Program committee: ** * Gilad Bracha, Cadence Design Systems, USA * Johan Brichau, Universite Catholique de Louvain, Belgium * William Clinger, Northeastern University, USA * William Cook, University of Texas at Austin, USA * Pascal Costanza, Vrije Universiteit Brussel, Belgium * Stephane Ducasse, Universite de Savoie, France * Brian Foote, Industrial Logic, USA * Robert Hirschfeld, Hasso-Plattner-Institut Potsdam, Germany * Jeremy Hylton, Google, USA * Shriram Krishnamurthi, Brown University, USA * Michele Lanza, University of Lugano, Switzerland * Michael Leuschel, Universitaet Duesseldorf, Germany * Henry Lieberman, MIT Media Laboratory, USA * Martin von Loewis, Hasso-Plattner-Institut Potsdam, Germany * Philippe Mougin, OCTO Technology, France * Oscar Nierstrasz, University of Berne, Switzerland * Kent Pitman, PTC, USA * Ian Piumarta, Viewpoints Research Institute, USA * Nathanael Schaerli, Google, Switzerland * Anton van Straaten, AppSolutions.com, USA * Dave Thomas, Bedarra Research Labs, Canada * Dave Ungar, USA * Allen Wirfs-Brock, Microsoft, USA * Roel Wuyts, IMEC & Unversite Libre de Bruxelles, Belgium -- http://mail.python.org/mailman/listinfo/python-list
Re: programming by evolution?
Xah Lee wrote: Pascal Constanza is a Common Lisp fanatic. It's Costanza, not Constanza. Thank you, Pascal -- ELS'09: http://www.european-lisp-symposium.org/ My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
[CfP] DLS'10
Dynamic Languages Symposium 2010 October 18, 2010 Co-located with SPLASH (OOPSLA) 2010 In cooperation with ACM SIGPLAN John Ascuaga's Nugget, Reno/Tahoe, Nevada, USA http://www.dynamic-languages-symposium.org/dls-10/ * Call for papers * The 6th Dynamic Languages Symposium (DLS) at the conference formerly known as OOPSLA is a forum for discussion of dynamic languages, their implementation and application. While mature dynamic languages including Smalltalk, Lisp, Scheme, Self, Prolog, and APL continue to grow and inspire new converts, a new generation of dynamic scripting languages such as Python, Ruby, PHP, Tcl, and JavaScript are successful in a wide range of applications. DLS provides a place for researchers and practitioners to come together and share their knowledge, experience, and ideas for future research and development. DLS 2010 invites high quality papers reporting original research, innovative contributions or experience related to dynamic languages, their implementation and application. Accepted Papers will be published in the ACM Digital Library. Areas of interest include but are not limited to: * Innovative language features and implementation techniques * Development and platform support, tools * Interesting applications * Domain-oriented programming * Very late binding, dynamic composition, and runtime adaptation * Reflection and meta-programming * Software evolution * Language symbiosis and multi-paradigm languages * Dynamic optimization * Hardware support * Experience reports and case studies * Educational approaches and perspectives * Object-oriented, aspect-oriented, and context-oriented programming === Submissions and proceedings === We invite original contributions that neither have been published previously nor are under review by other refereed events or publications. Research papers should describe work that advances the current state of the art. Experience papers should be of broad interest and should describe insights gained from substantive practical applications. The program committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality. Accepted papers will be published in the ACM Digital Library. Papers are to be submitted electronically at http://www.easychair.org/conferences?conf=dls2010 in PDF format. Submissions must not exceed 12 pages and need to use the ACM format, templates for which can be found at http://www.acm.org/sigs/pubs/proceed/template.html. === Important dates === Submission of papers: June 1, 2010 (hard deadline) Author notification: July 15, 2010 Final versions due: August 13, 2010 DLS 2010: October 18, 2010 SPLASH/OOPSLA 2010: October 17-21, 2010 === Program chair === William Clinger, Northeastern University, Boston, Massachusetts, USA === Program committee === Robby Findler (Northwestern University) Jeffrey S. Foster (University of Maryland) Lars Thomas Hansen (Adobe Systems) Charlotte Herzeel (University of Brussels) S. Alexander Spoon (Google) Eric Tanter (University of Chile) Jan Vitek (Purdue University) Alessandro Warth (Viewpoints Research Institute) [to be completed] -- http://mail.python.org/mailman/listinfo/python-list
Re: Which is the best implementation of LISP family of languages for real world programming ?
On 10/06/2010 23:51, Pascal J. Bourguignon wrote: bolega writes: Which is the best implementation of LISP family of languages for real world programming ? What's the real world? What's real world programming? I guess somebody's just enjoying flame wars too much. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Which is the best implementation of LISP family of languages for real world programming ?
On 12/06/2010 19:36, bolega wrote: What was your main reason for picking the Allegro (commercial) as opposed to one of the open source ones ? Is there anything in this old norvig book that makes it worth pursuing as a text ? http://norvig.com/paip.html My favorite Common Lisp environment is LispWorks, which is a commercial offering, but I regularly deal with many other Common Lisp implementations as well, including both commercial ones and open source ones, due to my role as a maintainer of a compatibility layer that is widely used. When I started using Common Lisp a couple of years ago, I started with a commercial environment (Macintosh Common Lisp back then). The main reason was that this allowed me to focus on learning the language, while being able to use an IDE that was relatively close to what other IDEs offered in a familiar way. Back then, it seemed too much of a hassle to set up an environment using Emacs + some open source Common Lisp implementation, which was (and still is) the most widely used choice in a pure open source setting. I still believe that this is a major strength of the commercial systems, that you have a mostly hassle-free set up and can directly go into learning and/or programming in Common Lisp, without having to install, set up, and/or learn other tools, which may be non-trivial. (Of course, if you are already used to using Emacs, for example, this may be less of a problem for you.) Some people have the fear that there is a risk of a vendor lock-in if you go the commercial route. However, that's not really true: The portability of Common Lisp code across different implementations is excellent, and it is very hard to paint yourself into a corner. Since the commercial systems also provide free editions, which have some limitations but are usually more than good enough for learning purposes, you can also decide to just use them for learning, and then still make your mind up later on which implementation you eventually go with - at a stage when you can make a well-informed, and thus better choice. In fact, it seems to me that it's quite common that Common Lisp users do use several implementations on a regular basis, taking advantage of their various strengths depending on the task at hand. Just my €0.02. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Which is the best implementation of LISP family of languages for real world programming ?
On 12/06/2010 19:36, bolega wrote: Is there anything in this old norvig book that makes it worth pursuing as a text ? http://norvig.com/paip.html This "old" book by Peter Norvig is still one of the best Common Lisp introductions you can find, and has some excellent material that is not covered elsewhere. If you are interested in some fundamental AI concepts at the same time, this is one of the best choices. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On 30/09/2010 08:09, TheFlyingDutchman wrote: That argument can be made for dynamic language as well. If you write in dynamic language (e.g. python): def maximum(a, b): return a if a> b else b The dynamic language's version of maximum() function is 100% correct -- if you passed an uncomparable object, instead of a number, your call of it is incorrect; you just didn't pass the right sort of data. And that's your problem as a caller. In fact, since Python's integer is infinite precision (only bounded by available memory); in practice, Python's version of maximum() has less chance of producing erroneous result. "in C I can have a function maximum(int a, int b) that will always work. Never blow up, and never give an invalid answer. " Dynamic typed languages like Python fail in this case on "Never blows up". They don't "blow up". They may throw an exception, on which you can act. You make it sound like a core dump, which it isn't. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
Re: "Strong typing vs. strong testing"
On 05/10/2010 05:36, salil wrote: On Sep 30, 1:38 pm, Lie Ryan wrote: The /most/ correct version of maximum() function is probably one written in Haskell as: maximum :: Integer -> Integer -> Integer maximum a b = if a> b then a else b Integer in Haskell has infinite precision (like python's int, only bounded by memory), but Haskell also have static type checking, so you can't pass just any arbitrary objects. But even then, it's still not 100% correct. If you pass a really large values that exhaust the memory, the maximum() could still produce unwanted result. Second problem is that Haskell has Int, the bounded integer, and if you have a calculation in Int that overflowed in some previous calculation, then you can still get an incorrect result. In practice, the type-agnostic language with *mandatory* infinite precision arithmetic wins in terms of correctness. Any language which only has optional infinite precision arithmetic can always produce erroneous result. I have not programmed in Haskell that much, but I think Haskell inferences type "Integer" (the infinite precision) by default and not "Int" (finite precision) type for the integers. So, the programmer who specifically mentions "Int" in the signature of the function, is basically overriding this default behavior for specific reasons relevant to the application, for example, for performance. I think Haskell's way is the right. It is providing "safe behavior" as default and at the same time treating programmer as adults, at least in this case. I think dynamic languages are attractive because they make programs less verbose. But, statically typed languages with type inference (Haskell, OCaML, Scala, F#) is a very good compromise because they offer both type safety and succinctness. And when we need algorithms that should work the same independent of types, Haskell has typeclasses which are pretty intuitive, unlike the horrible C++ templates. Static typing still doesn't mesh well with certain kinds of reflection. Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ -- http://mail.python.org/mailman/listinfo/python-list
