On Thu, 16 Jul 2020, 14:38 Jan Mercl, <0xj...@gmail.com> wrote:
> On Thu, Jul 16, 2020 at 3:12 PM 'Axel Wagner' via golang-nuts
> <golang-nuts@googlegroups.com> wrote:
>
> > I dislike the idea of using $ and @ because I don't want to add new
> symbols to the language, if it can be avoided. In general I'd argue that Go
> tends to use keywords instead of symbols to convey meaning - e.g. we don't
> write `a -> b`, but `func(a) b`. There are exceptions (pointers are a big
> one) of course, but Go is still pretty light on symbols.
> > I think the overuse of symbols to convey semantics is a huge reason that
> I find perl and Haskell so unreadable, personally.
>
> There are 31 printable, non blank, non-digit, non-letter ASCII
> symbols. Go (lexical grammar) currently uses 27 of them. I'm not sure
> if using 27 of 31 vs using 29 out 31 makes a notable difference. (I
> have not counted smybol groups like ":=" ">=", "<-" etc., but that
> makes the number of symbols used in Go only bigger, not smaller.)
>
> But of course, a keyword would work as well. For example, $ can be
> replaced with no semantic change with 'type'. And @ can be dropped
> while keeping the original draft syntax for type instantiation - and
> the original parsing ambiguities. Then we can have something like
>
> Original:
>
> func Keys(type K comparable, V interface{})(m map[K]V) []K { ... }
> s := Keys(int, string)(m)
>
> Alternative-AW:
>
> func Keys(m map[type K comparable]type V) []K
> s := Keys(int, string)(m)
>
> FTR: In the alternative draft I missed the `~` (tilde) character, so
> there are not 3 but actually 4 ASCII symbols not used by Go.
>
> But I like the $, @ option because the language change is pushed
> "down" to be based mainly in the lexer grammar.
A few reasons that I'm not keen on your $, @ proposal:
- elsewhere in Go, when a name is defined, there is one clear construct
that defines it, not an arbitrary place within a type expression. That's
not the case in your proposal.
- the ordering of the type parameters is important, but is implicit in the
ordering of the type expressions rather than explicit. The order of the
type parameters may not even be visible to an external consumer of an API
(for example, consider a function that returns a generic struct where the
only generic elements are private fields). Reordering fields within a
struct could affect the type parameter order - something that should be
possible to do backwardly compatibly.
- it's strictly less general than the original proposal. There's no way to
write a generic function that doesn't mention the generic type as part of
its signature. For example, you couldn't write this function:
func zeroPtrInterface[type T]() interface{} {
return new(T)
}
- I'm not keen on the @, $ syntax. It co-opts not just one but two new
symbols into the Go syntax, and I suspect that the merging of reference and
definition will make the resulting code hard to read.
For the record, I support the [] syntax. The analogy between generic
functions and maps makes sense to me, and I think it's sufficiently
syntactically distinct to avoid the issues with round brackets. My main
reservation is about backward compatible evolution of generic types. It's
not possible to add a new type parameter in a backwardly compatible way. In
larger systems, I wonder if that might turn out to be a significant issue.
cheers,
rog.
I haven't made any
> attempt to write a parser for the alternative draft, but I think this
> makes the changes on top of the existing parser pretty minimal. The
> original draft, on the other hand, needs IMO much more changes.
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/CAA40n-VwE2URengdE0Cd7sPQNCm5%3DTm5%3DaUS8kMwOpEw%3DXjJyg%40mail.gmail.com
> .
>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAJhgach5eUJvZ6ek5SZzoLW%3Dgi7axXRUbtz3-ukbLLSCVLAiOw%40mail.gmail.com.
