On 31 Oct, 08:27, torb...@[EMAIL PROTECTED]
(Torben =C6gidius Mogensen)
wrote:
> James Harris <james.harri...@[EMAIL PROTECTED]
> writes:
> > As a matter of preference the declarations of some languages put the
> > type before the name such as
..=2E.
> > I can see advantages to each and would be interested to know what
> > other language designers and programmers (i.e. the customers of
> > language designers) prefer.
>
> I, mostly, don't care, as long as the context clearly tells me whether
> I look at a type or something else. Several other posters pointed out
> the problem with C-style types where parsing something like "foo*bar"
> requires one to know if "foo" is a type or a variable. If you always
> use a keyword or other symbol with a declaration, you are not in
> doubt, and it matters little if the type is before or after the name.
> Examples: "var foo* bar", "bar : foo*", "let foo* bar =3D ...". I have
> a small preference for types after names, but that may be because most
> of my favourite languages (ML, Haskell, Pascal, ...) use this.
OK. Based on the various replies, for now the following is where I am
at:
1=2E Introduce the kind of thing we are defining with a storage class
keyword - variable, value
2=2E Clear syntax - angle brackets - to show the type
3=2E 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 =3D 8 #Defines a constant called
CHAR_WIDTH
type char =3D <natural CHAR_WIDTH> #Define type "char" (natural is
unsigned)
value <char> BASE_CHAR =3D 48 #Use type "char" to define another
constant
var <char> char_value =3D BASE_CHAR #Declare and init a variable
var <integer 16> hit_counter =3D 0
var <integer 32> a =3D any, b =3D any #Declare and do not init variables
var <array (0 ... 255) of <char>> translate_table #Compound type
Executable statements:
hit_counter =3D <integer 16> a #Checked type narrowing
char_value =3D 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?
> It is much better with a postfix syntax like
> "g(f : int[10]->10) : int" or a prefix syntax like "int g(int[10]->10
> f)". It is even worse if we in C-style type syntax have to declare a
> function that returns a function. This would be something like
>
> int f(int x[10]) g(int x)
>
> I'm not sure this is valid C syntax, and it certainly isn't easy to
> read. Isn't it better to write something like
>
> g(x : int) : int[10]->int
..=2E.
Not sure I understand all of the above but I have a problem with
function definitions in that the way I would like to specify them is a
way that I think people will not like. So for the moment I'm toying
between a strict way and a more user-friendly way. The strict way puts
the type (and all argument types) first:
function out(<integer 32>) in(<array (0 ... 9) of <integer 32>>) f
out(retval) in(source)
so the function name and argument names all come at the end. The more
friendly way puts the names within the argument list:
function f out(<integer 32> retval) in(<array (0 ... 9) of <integer
32>> source)
or should it be more like old C where the types follow the names:
function f out(retval) in(source)
<integer 32> retval
<array (0 ... 9) of <integer 32>> source
> > Also, my current design, has gone through some iterations of minor
> > detail and currently has the ability to allow either the name or the
> > type first. I'd be interested to know what people think of this
> > flexibility. Is it a good thing? Or does it simply make the code too
> > hard to read? If so which option would you say should be enforced?
>
> 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?) 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.
--
James
|
