Hi all,
Been thinking about go 2 ideas, and I wanted to put forth some motivated
but rough ideas. Here she goes:
1. "defer go" extend defers to work on goroutine exit with mechanism just
like defer, but if we say "defer go f()"
instead of "defer f()" then we run on goroutine exit. Very big gains for
scaling here IMHO.
2. complex numbers:
- add support for addressable "real()" and "imag()", so that we may
update 1 component
- make the type system accept "x + 0i" for a floating point variable x
as a complex expression
3. add parametric types with go-like syntax and simplified rules covering
most cases.
To my taste, this might be something like, like the following, which adds
new usage of keywords
"make" and "type" -- "make" for type arguments indicating the corresponding
code has to be made to
be used. And the following uses "kind" expressions in make, which
describes a very basic type of
types:
kind := 'type' | <interface> | 'numeric'
where 'type' means any type
<interface> refers to a type name which is an interface type
<numeric> means any builtin numeric type.
// example
// parameterized type declaration:
make(A, B type, C Stringer, ...) type T struct {
a A
b B
c C
....
// recursion possible
next *T
}
// concrete (non-parameterized) type expression -- type checker checks
// each argument fits kind specified in declaration.
type MyT T[int, float, string, ...]
// partially concrete
make(A type) type U T[int, A, string]
// code templates with make, all type arguments
// must have the exact same kind as in the type declaration for T
make(A, B type, C Stringer)
func (t *T) Method() {
}
//object instantiation: instantiate parametric type T with int, float,
map[string]int, ..
// type checker checks that all type parameters fit the respective Kind in
the type
// declaration for T.
t := make(T[int, float, map[string]int])
Unfortunately I don't have time to write out a real spec, this is just an
informal expression
of what I feel might be nice in go2. The overall idea is to simplify
parametric typing rules
so that the notion of kinds is simple (eg no partial code specializations)
and the syntax go-like
Perhaps, though numeric could be further specified as integral (with bit
operators).
4. Extend above to simplified overloading: allow defining all of [+,-, /,
*, %, <, >, <=, >=, ^, <<, >>, |, &]
to make new numeric (or integral) types, but don't allow defining only
some of them (for numeric, resp integral types).
Do this by introducing a new builtin parametric interface "numeric" (or
"integral") with
methods Add, Mul, etc with appropriate signatures
make(T type) interface numeric {
Add( T) T
// ...
// perhaps a special method indicating numeric kindness
Numeric()
}
Now to define a new type using builtin operators
type myRat struct {
numerator int
denominator int
}
func (n myRat) Add(o myRat) {
}
// ...
type MyRat numeric[myRat]
This would simplify operator overloading, making its abuse or use in
hard-to read circumstances difficult
while enabling it where it is most needed: numbers.
Thanks for reading, I hope this post gets some folks thinking and I also
ask that it not be taken as invitation
for technical debate, as I unfortunately don't have time to engage that.
Best
Scott
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
