James Harris <james.harris.1@[EMAIL PROTECTED]
> writes:
> On 31 Oct, 08:27, torb...@[EMAIL PROTECTED]
(Torben Ęgidius Mogensen)
> wrote:
> OK. Based on the various replies, for now the following is where I am
> at:
>
> 1. Introduce the kind of thing we are defining with a storage class
> keyword - variable, value
> 2. Clear syntax - angle brackets - to show the type
> 3. The type before the name in both declaration and explicit
> conversion. (People preferred consistency.)
>
> So, some made-up statements (for anyone to criticise). I'd be
> interested to know why if people dislike the syntax and how they would
> prefer to see the code.
>
> Declarations:
> value <integer 32> CHAR_WIDTH = 8 #Defines a constant called
> CHAR_WIDTH
>
> type char = <natural CHAR_WIDTH> #Define type "char" (natural is
> unsigned)
>
> value <char> BASE_CHAR = 48 #Use type "char" to define another
> constant
>
> var <char> char_value = BASE_CHAR #Declare and init a variable
> var <integer 16> hit_counter = 0
> var <integer 32> a = any, b = any #Declare and do not init variables
> 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.
> Executable statements:
> hit_counter = <integer 16> a #Checked type narrowing
> char_value = BASE_CHAR #No type change needed
>
>> What I mostly object to is putting part of the type before the name
>> and other parts after the name, such as "int x[10]". This makes it
>> very hard to read the type of a name. Is is better with "int[10] x"
>> or "x : int[10]".
>
> Agreed.
>
>> C-style type syntax gets even worse if we have
>> functional parameter types, such as "int g(int f(int x[10]))". Note
>> that to specify a type for the functional parameter f, we have to
>> invent a dummy name for its parameter -- a name that isn't really part
>> of the type.
>
> I don't think C requires this. Can you not declare a function
>
> int f(int [10]);
>
> to say f is a function taking an array of ten integers and returning
> an int?
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.
>> Keep it consistent but, where you can, make explicit types optional
>> and let the compiler infer them.
>
> Sorry, can't bring myself to go with inferred types. (Why do you like
> them?)
For several reasons:
1. It makes the programs shorter.
2. You don't have to decide in advance how polymorphic/generic your
functions are -- the type inference makes them maximally
polymorphic.
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.
> 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.
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.
Torben
|
