Re: RAD vs. performance

Jon Harrop wrote:
Curtis W wrote:
Jon Harrop wrote:
One type, either specific (e.g. int) or generic (e.g. 'a).

Yes, but eventually you're going to get down to a point where you can't
use 'a and have to use a specific type.

Is 'a * 'b a "specific type"? It is more specific than 'a but is still
polymorphic.
I was referring to types like "int|float".

OCaml does handle this, but it
requires you use type constructors and all the ugliness that comes with
them.

Show me a translation of my symbolic simplifier that is less ugly.
Just get rid of the need for type constructors and allow for similar
pattern matching syntax through data structures.

Right, your type system infers more general types and is undecidable.

Which I don't think is a bad thing :)

Sure, but you should recognise that it is a tradeoff.
Yes, but I still believe my approach is better.

Exactly, yes. If you can only infer less specific types then the types
that you infer convey less information to the type checker.

No. Conveying less information doesn't matter; conveying _accurate_
information does, which is dependant on what the user wants.

Yes. Specialising types tends to improve the accuracy of type checking
whereas generalising them does not. In OCaml, you have the choice of
inferred or declared unions.
No. General types are almost always preferable to specialised types
simply through good coding practices. If you consider this, it makes
sense to make type inference general by default and allow the
programmer, in the small chance that he needs a less specific type, to
specify it manually.

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.

In my mind, that is almost certainly an error and I want my compiler to
force me to fix it.

But you've already given me an example where it's not an error--your
algebraic simplifier.

Yes. That is a badly-written simplifier. Better style would be to use a
declared union type instead of polymorphic variants, like this:

*snip*

Note that the inferred type is exactly correct now, whereas before it was
valid but still inaccurate.
No, you missed my point. That example illustrates that what you wanted
was a generic type but you have to specify it manually (or use type
constructors) in order for the inferencer to figure that out. Show me
an example where specific types are a good thing and I can show you
1000 where they aren't.

Since my type system has no need for type
constructors, variables and constants would just be strings and
numbers.

What would symbolic expressions be?
Any value with a 'simplify' routine, of course.

IMPLICIT NONE in Fortran is a similar idea. Having implicit variable
declarations allows for more succinct code but the cost in terms of the
number of errors introduced into code is too great.

This generally isn't a problem unless variable *use* doesn't trigger an
error, either. It would be relatively easy to show information on
variable instantiation and types through a visual and noticeable manner
in an IDE, for example, which I suspect would largely make this a
non-issue.

Yet almost all modern languages disallow implicit variable declaration. How
could an IDE highlight erroneous declarations?
They couldn't; I'm saying that they can give you information to help
correct any errors that might be because of an uninitialized variable.
To be honest, though, in all my years working with python, I don't
think I've ever had such an error, or if I did it wasn't noticeable
enough to remember.

My ray tracer uses infinity to represent the parametric intersection
point of rays that don't intersect anything.

Well there's my problem--I've never written a raytracer ;)

You should - they're good fun! :-)
Maybe I'll write one in my language and send it in to you if I ever
start on the compiler.

No, int and float are very different. Indeed, none of their operators
have the same semantics, e.g. a+b+c = a+c+b is true only for int. Even
equality is different...

No, you mean equality doesn't have the same semantics. I've already
been thinking about the idea of using an implicit epsilon in float
comparisons, which would make a+b+c = a+c+b true.

That doesn't work in general. Interval arithmetic is better but is still no
panacea.
What do you mean?

I have actually had difficulty tracking down numerical errors caused by
implicit casting of ints and floats in C++.

Well there's your problem; C++ IDEs and the language itself hardly make
a good development environment.

I've never seen an IDE that would help with implicit casting bugs. I've
considered the use of coloured operators to improve type throwback in
OCaml. I think that could be cool.
Yup. Current development environments are rather poor at presenting
information that's not directly in the source code, which is why most
languages either force you to write it yourself or just leave you
without the information.

That's fine. There has been a lot of research done on this over the years
and there is no real concensus. I'd say that people in North America tend
to use dynamic typing whereas people in Europe tend to use static typing.

Yup. Maybe it has something to do with your small cars ;-)

We have nothing to make up for. ;-)
Well, at least I don't have to pay an insane amount of money for
gas/internet.

The simplest problem illustrated by my example was that of parallel
pattern matching. Dynamic dispatch doesn't handle the case of dispatching
over more than one key simultaneously.

Again, it'd be possible, just more verbose.

Try it.
I'm trying to think of whether there would be a better way to handle
it, possibly by introducing a new construct.

.

Relevant Pages

  • Re: Go ahead. Stop programming. This ensures you from any mistakes.
    ... is truth that the variables in the imerative languages, ... deferred declarations, ... first thing any programmer should understand -- the program flow. ... So, normally, switches should be rare. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Declarative constraints in practical terms
    ... of conjunction and disjunction and be sound w.r.t. ... but there's a ton of what in imperative languages and there seems ... mathematics, then it's declarative. ...
    (comp.databases.theory)
  • Re: This was memory fragmentation
    ... system or (in an academic setting) proposing extentions. ... All major languages have types. ... There is an infinite number of bugs a type system won't catch. ... realistic than switching to declarations. ...
    (comp.lang.prolog)
  • Re: Declaration design preference: type or name first
    ... you need to find the declarations of mytype and oldtype to know what ... My intention is that declarations can appear at the top of any block ... compilers for languages with type inference can be made to report the ... precision to the compiler, or do you leave it as just an identifier ...
    (comp.lang.misc)
  • Re: Rationale for C++/CLI Value Types not having a default constructor
    ... C# doesn't support default constructors for value types either. ... The CLR itself doesn't support default and copy constructors for value types. ... Only those internal types can't be used from any other module, they're private, just like the x86 code generated by a native C++ compiler. ... Anything is doable in private code, but you won't be able to make that public and use that type from other DLLs and other languages. ...
    (microsoft.public.dotnet.languages.vc)