Google's Go language and "goroutines"
in [TCL]
|
Prev: tcl ssh extension library?
Next: Expect spawn expect
From: Donal K. Fellows on 15 Nov 2009 06:21 On 15 Nov, 01:46, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > Looks like a cool language, from the hype, but one thing stuck out > which seems very promising: > > * Go's type system has no hierarchy, so no time is spent defining the > relationships between types. Also, although Go has static types the > language attempts to make types feel lighter weight than in typical OO > languages. That's essentially duck typing. In a compiled language, that's unusual (and is in fact something that's brought in from scripting languages if I've understood the FAQ right). This is something to watch to see how well it works in practice. > Wow! Finally someone has dared to state the obvious: type hierarchy is > expensive and difficult to understand, even for a compiler. Compilers can cope well enough. It's programmers that have the problem it seems; most people tend to find deep is-a-kind-of hierarchies difficult to comprehend. (C++'s insane slowness to compile is due to other issues, such as turing-complete template complexity.) Donal.
From: Alexandre Ferrieux on 16 Nov 2009 03:45 On Nov 15, 12:21 pm, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > On 15 Nov, 01:46, "tom.rmadilo" <tom.rmad...(a)gmail.com> wrote: > > > Wow! Finally someone has dared to state the obvious: type hierarchy is > > expensive and difficult to understand, even for a compiler. > > Compilers can cope well enough. It's programmers that have the problem > it seems; most people tend to find deep is-a-kind-of hierarchies > difficult to comprehend. In some cases it goes beyond the hierarchy's depth, and there's a shared responsibility: think about Eiffel's esoteric compilation messages, especially in the presence of generics, or covariance/ contravariance clashes with the "like" operator. Even a perfectly rigorous programmer can be helpless in front of the system's own contradictions ;-) -Alex
From: Donal K. Fellows on 16 Nov 2009 05:28 On 16 Nov, 08:45, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > In some cases it goes beyond the hierarchy's depth, and there's a > shared responsibility: think about Eiffel's esoteric compilation > messages, especially in the presence of generics, or covariance/ > contravariance clashes with the "like" operator. I don't know Eiffel *that* well. However, I do know that there's a tendency for generics/templates to lead to mystifying error messages and in many languages (Java is not good, C++ is famously bad, and Standard ML can be pretty nasty too). But ultimately, the problem comes when you try to establish type relationships between derived types (functions, arrays, modifiable variables) and not principal types (simple values, structures). The complexity of objects is an interesting topic. So this discussion isn't mistaken for comp.lang.misc :-) Tcl's objects don't work this way at all. The fact that you can restructure the type hierarchy underneath the feet of everything means that what we've got is not really a type hierarchy at all, but something else. (A responsibility hierarchy perhaps?) Donal.
From: Alexandre Ferrieux on 16 Nov 2009 07:41 On Nov 16, 11:28 am, "Donal K. Fellows" <donal.k.fell...(a)manchester.ac.uk> wrote: > > So this discussion isn't mistaken for comp.lang.misc :-) Tcl's objects > don't work this way at all. The fact that you can restructure the type > hierarchy underneath the feet of everything means that what we've got > is not really a type hierarchy at all, but something else. (A > responsibility hierarchy perhaps?) Indeed. And talking about hierarchies, Tcl_ObjTypes display absolutely zero null nada ability for polymorphism, which is a longstanding itch of mine. The whole core is sprinkled with "if (objPtr->typePtr == &tclFooType)", so that if you want to extend Foo you cannot do it without a core patch. Moreover, the patch tends to be scattered over several places if Foo happens to have fast conversion shortcuts with other types, like List/Dict. One way out would be something like "if (INHERITS_FROM(objPtr- >typePtr,tclFooType))" with #define INHERITS_FROM(t1,t2) \ (t1)&&((t1)->inheritsFrom ? \ (t1)->inheritsFrom(t2) : \ ((t1)==(t2))) and the obvious extension of the Tcl_ObjType struct with an inheritFrom "method", left to NULL for primitive types to minimize overhead. The only problem of course is to do that in an ABI-stable manner. Maybe letting sizeof(Tcl_ObjType) be returned by a stub-reachable function ? If that's for Tcl9 of course, no problem, but let's not be beaten again later, and put sizeof(X) in struct X for all public structures ;-) -Alex
From: Donal K. Fellows on 16 Nov 2009 08:25
On 16 Nov, 12:41, Alexandre Ferrieux <alexandre.ferri...(a)gmail.com> wrote: > And talking about hierarchies, Tcl_ObjTypes display absolutely > zero null nada ability for polymorphism, which is a longstanding itch > of mine. You're only getting antsy about this because you're thinking of a Tcl_Obj as an object. It's not. It's a value, but Tcl_Value was taken for something else at the time. There's simply no type hierarchy involved with the basic value types. It's just that some operations understand multiple types (well, that's also inaccurate, but not nearly as bad as what you were saying). Donal. |