first-class types (was: Go language)
|
Prev: CFP (deadline extension): GROW'10 (2nd Workshop on GCC Research Opportunities)
Next: Sequential consitency on X86_64 - implementation of a bust wait algo not working inspite of using mfences
From: Anton Ertl on 15 Nov 2009 06:12 Andrew Reilly <areilly---(a)bigpond.net.au> writes: >On Sat, 14 Nov 2009 15:43:19 +0000, nmm1 wrote: >> Secondly, to count as "first-class", at the very least the language has >> to permit the arrays to be operated on as composite objects, and include >> at least the basic array-specific operations (such as subsections). Nick playing Humpty-Dumpty as usual. >That's a substantially stronger meaning for "first class" than I was >using, and in that sense, Go doesn't have 'em. I was using first class >in the common computer science sense that they are types supplied by and >managed by the language itself, rather than by user-supplied libraries or >by convention. That's not the common meaning used in programming language terminology (and Nick's meaning isn't either). A first-class type in a programming language is a type on which you can performq all the non-type-specific operations of the programming language. E.g., in C you can have variables of type int, you can copy ints by a simple assignment, you can pass them to a function as parameter, and return them as function result, you can create arrays of ints and have int fields in structs and unions. So, int is a first-class data type in C. You can also do all of these things for structs, so structs are first-class data types in (modern) C. You cannot do all of these things for arrays (you can do some, but for others you only get a pointer to the first element), so arrays are not a first-class data type in C. - anton -- M. Anton Ertl Some things have to be seen to be believed anton(a)mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
From: nmm1 on 15 Nov 2009 06:49 In article <2009Nov15.121246(a)mips.complang.tuwien.ac.at>, Anton Ertl <anton(a)mips.complang.tuwien.ac.at> wrote: > >>That's a substantially stronger meaning for "first class" than I was >>using, and in that sense, Go doesn't have 'em. I was using first class >>in the common computer science sense that they are types supplied by and >>managed by the language itself, rather than by user-supplied libraries or >>by convention. > >That's not the common meaning used in programming language terminology >(and Nick's meaning isn't either). A first-class type in a >programming language is a type on which you can performq all the >non-type-specific operations of the programming language. The aphorism "Nothing to do with computing and not a science" fits that usage extremely well. In many languages, there are NO non-type-specific operations, for a start! None, zilch, zero, nihilum, de nada, .... Indeed, that is true of MOST traditional languages, definitely not excluding C, C++ and Fortran. I will give you that, UNLIKE so many of the terms that computer scientists have abused to justify their non-results, the term "first-class type" did originate in computer science. But my recollection is that it meant closer to my definition than yours when it was first introduced. Regards, Nick Maclaren.
From: Peter Grandi on 29 Nov 2009 05:21 [ ... ] >>> That's a substantially stronger meaning for "first class" >>> than I was using, and in that sense, Go doesn't have 'em. I >>> was using first class in the common computer science sense >>> that they are types supplied by and managed by the language >>> itself, rather than by user-supplied libraries or by >>> convention. That's more like "builtin type". >> That's not the common meaning used in programming language >> terminology (and Nick's meaning isn't either). A first-class >> type in a programming language is a type on which you can >> performq all the non-type-specific operations of the >> programming language. Sort of; that is more pedantically the notion of first class *values*; a value is first class when the operations possible on its are not specifically restricted. For example some languages have pointer value, but these cannot themselves be pointed to, or have procedure values, but they cannot be passed as arguments, etc. I think that a description of this definition is part of a paper with a title like "civil right for values" or similar. Indeed this search seems to return some apposite links (the Wikipedia one for example): http://www.google.com/search?num=100&as_q=programming+language&as_epq=first+class+values > In many languages, there are NO non-type-specific operations, for > a start! None, zilch, zero, nihilum, de nada, .... Indeed, that > is true of MOST traditional languages, definitely not excluding > C, C++ and Fortran. It is not the actual *operation*, it is the the *interface*; and there are several types in those languages whose interfaces have a common subset, including interfaces for being assigned, passed as an arguments, compared for equality, etc.; the idea is that values beloging to types whose interface is a superset of some "basic" interface are first class values. The operations may well have different implementations and somewhat different semantics. > recollection is that it meant closer to my definition than > yours when it was first introduced. Once could say to neither, as strictly speaking "first class type" has another meaning: a language has first class types when any type operation that can be done on another *type* (not on the values of the type) is valid on that type too, e.g. a first class type can be used to build arrays, records, be part of a procedure type both in the parameter list and the return spec, and so on. In Java for example builtin types are not first class, and in C bitfield types are not first class either (e.g. you cannot build a bitfield array or define a pointer type to one). There is also a much rarer usage of "first class type" which denotes the case where types are reified at run time and are subject to the same rules as other values; that is you can pass a type as an argument to a procedure, have type variables (references) and assign a type to a value. Right now I can only remember EL/1 from Harvard as a language with reified first class types (but I remember there were others). Anyhow, discussions about types are usually pointless, being undermined by poorly misunderestimated terminology and ontology; for example some well known papers or books by famous authors are entirely based on the lack of understanding of the vital difference between types and type constraints (one of my many pet peeves). What exactly "first class" means or should mean fades into insignificance compared to that.
From: nmm1 on 29 Nov 2009 05:53
In article <yf3skbxskbo.fsf(a)tree.gp.example.com>, Peter Grandi <pg_nh(a)0910.exp.sabi.co.UK> wrote: > >> In many languages, there are NO non-type-specific operations, for >> a start! None, zilch, zero, nihilum, de nada, .... Indeed, that >> is true of MOST traditional languages, definitely not excluding >> C, C++ and Fortran. > >It is not the actual *operation*, it is the the *interface*; and >there are several types in those languages whose interfaces have >a common subset, including interfaces for being assigned, passed >as an arguments, compared for equality, etc.; the idea is that >values beloging to types whose interface is a superset of some >"basic" interface are first class values. The operations may >well have different implementations and somewhat different >semantics. The difference between the terms "operation" and "interface", in the context of programming language specifications, is a bit on the religious side for me :-) Whatever. My point stands, no matter which aspect you consider. >> recollection is that it meant closer to my definition than >> yours when it was first introduced. > >Once could say to neither, as strictly speaking "first class >type" has another meaning: a language has first class types when >any type operation that can be done on another *type* (not on >the values of the type) is valid on that type too, e.g. a first >class type can be used to build arrays, records, be part of a >procedure type both in the parameter list and the return spec, >and so on. All right. I am happy with that one, too, and my point STILL stands for most mainstream programming languages! However, the failure is not always as obvious as types not being arbitrarily constructible, but the fact that there are differences between an X composed of Ys and an X composed of Zs, as seen at the X level. >Anyhow, discussions about types are usually pointless, being >undermined by poorly misunderestimated terminology and ontology; >for example some well known papers or books by famous authors >are entirely based on the lack of understanding of the vital >difference between types and type constraints (one of my many >pet peeves). What exactly "first class" means or should mean >fades into insignificance compared to that. Let's agree on that as a summary :-) My pet peeves in that area are the authors who seem incapable of understanding that syntax does not imply semantics, and the ones that claim that (mathematical) resource limitations are outside the province of programming language design. Regards, Nick Maclaren. |