Re: RAD vs. performance

There is no lost type information.

Yes there is. If you write "a + b" with an overloaded/abstracted "+" then
you don't know the specific types of "a" or of "b". That type information
is lost. You can regain it but only by analysing the expression in a
wider context.

I can see what you're getting at, but I wouldn't consider that "lost"
in any sense of the word.

A program has specific types inferred in ML but the same program cannot have
such specific typed inferred in your system. In that sense, the specific
type information is "lost".
Again, it's never lost because it's never there. ML has to *assume*
that the given variable is only ever one specific type. This isn't true
most of the time, which is why my type system *assumes* that a variable
can hold types which are compatible with its use.

Your approach

I didn't design ML.
No, but you're backing it.

It provides more specific type information and, therefore, can be used to
improve reliability by providing better static typing.

No, it doesn't. Global and local variables are always assumed to be
'any';

The least-specific type, providing no error checking whatsoever.
Whoah, slow down there. You're teatering on the idea that a less
specific type system gives you less information, which is simply not
true. It may not be in the form of an error, but it doesn't just
completely leave you in the dark like you seem to be implying. So long
as I can easily find out the type of a variable I don't mind the
compiler assuming I'm right.

the type inference for those is simply for optimisation
purposes.

If the same global variable is inferred to be an int in one module and a
string in another then you think that information is "simply for
optimisation" and could not be used to indicate the presence of some kind
of type error?
Nope. It's impossible to determine whether that's an error or
intentional, and since the programmer is always right we have to assume
it's correct. The type would be int|[char], although this would be
presented to the user just in case he's wrong so he can correct
himself.

If it infers "int|float" then your function is compatible with both.

Yes. That does not mean that your function will work correctly with both.

Most of the time it will.

Nonsense. You'll have a tough time finding any non-trivial functions that
work with both int and float. A quick look in the Complex modules reveals
that div, inv and norm will fail.
Most of the numeric functions I've seen do. For example, take a look at
some of these rect/collision detection routines:
http://24.12.0.88/~bytecoder/rect.py

I've never seen a case where infinity was a valid answer, which is
essentially the difference between the two types.

Parts of the float/int interface shouldn't be
shared, I agree, but unfortunately that's how it was first done and
breaking that compatibility by, e.g. having two divide operators for
possible division by zero and normal division, would probably cause
more bugs than it would solve.

You mean "approximate floating point division" and "Euclidean quotient".
They are two completely different operations. Giving them different names
and making them incompatible can only be a good thing.
Hmm. I'll take you up on this: I'll put a /. operator in my language
for floating point division, but I'll keep / for floats as well and
make it compatible with the int./ operator.

It doesn't matter whether or not the function is "compatible" in the
sense that you happen to have exposed interfaces with members of the same
name (e.g. "+" for both int and float addition). It does matter whether
or not the function will work with those types. If my function will not
work then I want to know.

Again, it's a compatibility issue. If you go around changing something
so basic as arithmetic you're going to get confusion and bugs because
of it. I suspect the number of bugs caused by having the same interface
for ints and floats is a fairly rare occurance and probably wouldn't be
nearly as bad to track down as, say, a bad pointer.

Sure. Get rid of pointers.
Way to side-step my point ;)

If this isn't
true, it's the programmer's fault and there's nothing we can do about
it. With this in mind, what you're saying doesn't make sense: if it
infers [<`A|`B] then it will work for [<`A|`B], period.

No, if it infers [<`A|`B] then your system will compile it when other
systems would have given a type error.
Whether or not this is a good thing depends on what the user wants--I
contend that assuming interfaces are equivalent and inferring the most
general type will produce much more accurate results than a
simple-minded type inferencer that arbitrarily constricts types.

It takes a symbolic expression and applies some replacement rules to
simplify it. It is just an example of a pattern match that uses lots of
features that are not provided by OOP so I chose to use it as a
counter-example to your incorrect statement "Pattern matching can be
replaced with dynamic dispatch through objects--they're both optimised
the same way".

Ok, I get what you're doing now. OCaml can be fairly concise,

This is also about catching errors at compile time.
Correct. There would be a number of ways to do it in my language while
retaining type safety. Dynamic function dispatch would be the most
similar to your method, albeit a little less concise.

.

Relevant Pages

  • Re: RAD vs. performance
    ... either specific (e.g. int) or generic. ... int and float are very different. ... contend that assuming interfaces are equivalent and inferring the most ... Dynamic dispatch doesn't handle the case of dispatching over more ...
    (comp.lang.misc)
  • Re: Abnormal program termination
    ... foo.c:4: warning: function declaration isn't a prototype ... Your version is legal under C90 rules, but int mainis more explicit ... float ave(), average; ...
    (comp.lang.c)
  • RTF Render with Scale
    ... float fHorzSizeInches = nHorzSize / 25.4f; ... IntPtr hdc = graphics.GetHdc; ... int nHorzSize = SafeNativeMethods.GetDeviceCaps(hdc, ... PHYSICALWIDTH = 110, ...
    (microsoft.public.dotnet.languages.csharp)
  • (part1b) Han from China teaches you C
    ... int flist, mlist, slist; ... float board_size; ... static void draw_tube(float bottom_radius, float top_radius, ... glVertex3f(xmin, ymin, zmax); glVertex3f; ...
    (comp.lang.c)
  • Re: RTF Render with Scale
    ... float fHorzSizeInches = nHorzSize / 25.4f; ... IntPtr hdc = graphics.GetHdc; ... int nHorzSize = SafeNativeMethods.GetDeviceCaps(hdc, ... PHYSICALWIDTH = 110, ...
    (microsoft.public.dotnet.languages.csharp)
Quantcast