Thanks for the clear answer Carl - below are just some more thoughts... <br><br><div><span class="gmail_quote">On 6/11/07, <b class="gmail_sendername">Carl Eastlund</b> <<a href="mailto:cce@ccs.neu.edu">cce@ccs.neu.edu</a>
> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>> Not at all. The function (lambda (x) 3.7) qualifies as a number ->
<br>> number function, but it is not int -> int. Calling add1 a number -><br>> number function throws away valuable information about how it can be<br>> used on integers, positive numbers, and so forth.</blockquote>
<div><br>Okay - I understand your point now - thanks for clarification. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Raising an exception means control passes to the nearest dynamically
<br>> installed exception handler, nothing more or less. Programs and<br>> semantics don't make value judgments. Programs often raise exceptions<br>> when nothing "incorrect" has happened.</blockquote>
<div><br>If you mean exceptions arising outside of programmer's control such as out of disk space, etc., I see those as defensive programming techniques, that from an end user's perspective, failure to handle the exceptions is incorrect semantic ;)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> As for the "type semantics" of raising an exception, as I said, many
<br>> static type systems treat expressions known to raise exceptions as<br>> having any type. Hence my statement that add1, which raises an<br>> exception on large classes of inputs, has many different return types
<br>> for those inputs. If you want to assign a different "type semantics"<br>> to exceptions, you'll have to describe your type system in greater<br>> detail.</blockquote><div><br>This is where I see a general exception or condition or continuation mechanism, while good as building blocks, loses the richer information that you are alluding with the add1 example (
i.e. using number -> number loses the richer meaning of int -> int) - but I am<br>digressing here... <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Do you mean conceptually, as in "we can imagine the type int -> int<br>> for add1"? Or do you mean actually, in that "Scheme knows that add1<br>> is a procedure"? Of course in the former sense, we can apply most
<br>> type systems to just about any language. In the latter, Scheme has a<br>> type system, but not a very detailed one.</blockquote><div><br>I didn't know what type info is available internally in mzscheme, but assume at least the latter. I would assume the lack of a detailed type system is not an inadvertent admission in scheme specification - right? ;) And if the reason is to support research and experimentation, that's fine. If the reason is because one cannot describe all types that would terminate, that's fine too ;)
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Depends on what you mean. Of course, in Scheme you can assign a type<br>
> to everything, but "Scheme value" is not a very useful type. On the<br>> other hand, if your type system uses "int -> int" to designate<br>> "functions which, when given an integer input, always terminate and
<br>> yield an integer result", then yes you will run into problems trying<br>> to typecheck some functions, partly because of that "always terminate"<br>> clause. There are some things type systems can't do.
</blockquote><div><br>Wondering what people think of Qi (<a href="http://www.lambdassociates.org/">http://www.lambdassociates.org/</a>) that features a type system that doesn't guarantee to terminate... ;) <br>Thanks,
<br>yc<br><br></div></div>