On 6 Nov, 08:39, torb...@[EMAIL PROTECTED]
(Torben =C6gidius Mogensen)
wrote:
..=2E.
> > var <array (0 ... 255) of <char>> translate_table #Compound type
>
> Why the brackets around char in the last example? The outer brackets
> should be enough to establish that we are talking about types.
Perhaps. My declaration system is far from complete yet.
..=2E.
> Yes, but here we are talking about a function g, which returns an int
> and takes as its parameter a function f which takes as its parameter
> an array of ten integers and returns an int.
OK. I see your point about the invented name in the original C.
..=2E.
> > Sorry, can't bring myself to go with inferred types. (Why do you like
> > them?)
>
> For several reasons:
>
> 1. It makes the programs shorter.
But it also makes them ambiguous.
> 2. You don't have to decide in advance how polymorphic/generic your
> functions are -- the type inference makes them maximally
> polymorphic.
I want control over how polymorphic functions are. Maximally
polymorphic doesn't sound good to me. On the other hand I intend
arbitrarily-parameterised types which would allow the necessary
polymorphism but retain control.
> 3. It makes it easier to refactor your programs, as you don't have to
> change a zillion declarations when you, say, change something from
> a list to an array. Of course, if you use typedefs all over the
> place, you can change a single typedef instead of a zillion types,
> but that requires discipline.
For this I intend a type system that allows incoming parameters to be
behaviourally specified - e.g. "sequence of" - whereas the actual
parameter supplied can be concrete such as "array of" or "file of"
etc. I take your point about typedefs. Not sure how best to encourage
the use of type names.
> > I want the user to explicitly specify all types. Inferred types
> > seems to me too likely a cause of unexpected errors. That's maybe
> > because I have never used them but I'm thinking of this as an
> > engineering tool and expect all types to be stated.
>
> I have used languages with type inference for two decade, and in my
> experience, the compiler spots type errors about as well as if you
> stated them explicitly. Type errors are usually of the form "These
> two uses of a variable/function do not agree, because one use implied
> a type of form A and the other a type of form B, which are not
> compatible", so you have to figure out which of the two uses are
> wrong, which is a bit harder than if you just get a single use that
> doesn't fit a declaration. But it is not really a problem in my
> experience.
>
> I would still make type declarations optional, so you can specify your
> intent to the compiler and to readers of your code.
Perhaps the type parameterisation and partial typing would address
your preferences. In truth, adding type inference to a compiler adds
greatly to its complexity. I'm finding that writing the compiler
without type inference is more than enough of a challenge!
> I prefer a combination of type inference with optional declarations
> over both dynamic types and explicit static type declarations, both of
> which I have also used extensively.
>
> So, before you finalize your design, you should read up on type
> inference. Even if you end up not using it, you at least have the
> satisfaction of making that decision on an informed basis.
I've read some about it. I do have what you may call optional
declarations, or rather optional parts of declarations. Part of the
ethos of my language is toward more explicit specification rather than
less. General type inference would not fit well with that and would be
an anomalous addition. I will, however, bear your comments in mind.
There may be ways to satisfy the requirements while maintaining the
engineering discipline. As I say, this is work in progress.....
--
James
|
