On Friday, March 14, 2003, at 12:21 PM, Dave Whipp wrote:
Michael Lazzaro wrote:
3) If an "untyped" var is used for a typed parameter, a simple
dataflow analysis is used to determine whether the compiler can
guarantee that, at that point, an "untyped" var will _always_ contain
values of a known
Michael Lazzaro wrote:
3) If an "untyped" var is used for a typed parameter, a simple dataflow
analysis is used to determine whether the compiler can guarantee that,
at that point, an "untyped" var will _always_ contain values of a known,
specific type. If so, the type is inferred (silently or
On Friday, March 14, 2003, at 11:06 AM, Michael Lazzaro wrote:
AFAICT, these are the *only* possible solutions to the problem. At
last count, Larry was leaning towards #2. Damian was countering with
#1. Some Lowly Grubs were suggesting #3. Am I missing anything?
Whoops! That needs correctin
I apologize for not including a previous message thread -- I
fumble-fingered myself out of all the relevant ones
Still, I'd just like to cast my tiny vote regarding inferences.
I'd like to be able to write classes that can take advantage of
screaming speed, and types contribute.
I'd like to
Friday 14 March 2003 20:06, Michael Lazzaro wrote:
> 3) If an "untyped" var is used for a typed parameter, a simple
> dataflow analysis is used to determine whether the compiler can
> guarantee that, at that point, an "untyped" var will _always_
> contain values of a known, specific type. If so, t
OK, divide & conquer. We seem to be spasming about this and trying to
talk about N things at once, so here's an issue summary. We're talking
about at least two separate cases, (1) "inferring" type where none has
been specified, and (2) "coercing" a typed value into another type.
Let's take t
