5 ms·

Gedanken: A Simple Typeless Language (1970) [pdf]

36 points by rutenspitz 12y ago

pmcjones 12y ago
This archive of GEDANKEN history includes a scan of the listing of Reynolds' LISP implementation of GEDANKEN, and also his 1969 technical report with a formal definition of GEDANKEN: http://www.softwarepreservation.org/projects/lang/GEDANKEN/ http://www.softwarepreservation.org/projects/lang/GEDANKEN/
kensai 12y ago
The predecessor of C was typeless as well.
- techdebt5112 12y ago
  as is C
  - anacrolix 12y ago
    Almost
    - techdebt5112 12y ago
      it's sort of like trying to argue that "Whose Line" is not a game without points. There are types there, but they don't matter at all. You can cast anything to anything and it will never fail.
      - vidarh 12y ago
        Try to cast everything to the same type in C, and you quickly see that isn't true. While C does not give you safety, the typing is important for ease of access to members of structures, for example, and for deciding the number of bits or bytes to operate on, and for deciding layout of a type. The moment you go fully typeless, you suddenly need to be explicit about layout, size and signedness far more places.
      - yuubi 12y ago
        int f(float x) { return *(int *)x; }
        vidarh 12y ago
        That program refuses to compile not because you can't cast to/from arbitrary types in C, but because you don't make your intent explicit (assuming I read what you tried to do correctly). Try this: int f(float x) { return *(int *)&x; } On one hand you demonstrate that C cares a tiny little bit about type, but mostly because of implicit numeric conversions rather than any serious attempt at stropping you from bad casting. I do agree with the point that C isn't "typeless" in any real sense, though.
        jeorgun 12y ago
        I think the original was intentional. If C refuses to let you cast from a non-pointer to a pointer, then it is in fact enforcing some (small) degree of type-safety.
        vidarh 12y ago
        The reason I assumed it was not, is that obtaining the bitwise representation of a float is something people actually often ask for (and my variation is not the "right" way to do so). You may be right C does not refuse to let you cast from a non-pointer to a pointer either, though. It just forces you to be slightly more devious in this case: return *(int **)&x; Though I think the implicit conversions that force some of these contortions (e.g. "(int *)(int)x" compiles, but does not return an integer pointer with the address equal to the bit pattern of "x" interpreted as an integer, but the integer portion of the float reinterpreted as a pointer) are more convincing demonstration that C is not typeless in a meaningful way in my opinion, as they also mean identical statements will give different results depending on the types of the variables.
        vegedor 12y ago
        Well, you are laying of the safety belt there, don't complain afterwards. It make sense to me in some cases, so i won't even argue.
      - Eridrus 12y ago
        Not sure where I was reading this the other day, but types have two advantages: abstraction and checking. You can add a third one to that list: safety. C has types in the sense that it allows you to do abstraction, and type checking, but it doesn't enforce safety. 2/3 doesn't seem bad to me, especially for a systems language. I'd say that Typescript is in a similar position, you can cast anything to any type you want and there is no runtime check to stop you, but it helps you add structure to your code. Types do very much matter in these languages in practice, since you want to very much want to avoid writing a giant mess.
        vegedor 12y ago
        Of course C has safety features for the type system, warnings for problematic casts, and structs that can't be cast unless specifically unionized and explicitly ordered to.
- vidarh 12y ago
  BCPL, though I've never used it (my exposure to BCPL was mostly swearing at it because early parts of AmigaDOS was written in it, and at least that version of BCPL annoyingly stored memory addresses shifted, so when dealing with them C you could never de-reference them directly), was my dubious inspiration for avoiding typing early on in my compiler articles [1]. This before I went overboard and started layering a Ruby compiler on top of it. While I'm adding a tiny little bit of typing to it these days, it's only to distinguish "must be a Ruby object" from "can be anything". You can get away with no type information for surprisingly much. The main hassle is dealing with layout of structured data, but even then it's relatively straight-forward to deal with through a combination of memory and documentation (but maybe it's the assembly programmer in me - my first compiler was written in m68k assembly and then gradually translated into inline assembly in the language the compiler was for) That core is not by any means a fully fledged usable language, though, which BCPL of course was/is. Martin Richards, the creator of BCPL even still has a web page for it that includes a BCPL distribution [2] with both examples and the compiler. [1] http://www.hokstad.com/compiler http://www.hokstad.com/compiler [2] http://www.cl.cam.ac.uk/~mr10/BCPL.html http://www.cl.cam.ac.uk/~mr10/BCPL.html
shaunxcode 12y ago
Here is a non pdfy link: ftp://ftp.cs.cmu.edu/usr/jcr/gedanken.pdf
abecedarius 12y ago
http://www.erights.org/history/morris73.pdf http://www.erights.org/history/morris73.pdf is a great follow-up with more code in GEDANKEN. https://www.hackerschool.com/blog/46-paper-of-the-week-on-understanding-data-abstraction-revisited https://www.hackerschool.com/blog/46-paper-of-the-week-on-un... introduces a much more recent essay exploring these ideas about procedural data structures.

36 points by rutenspitz 12y ago

This archive of GEDANKEN history includes a scan of the listing of Reynolds' LISP implementation of GEDANKEN, and also his 1969 technical report with a formal definition of GEDANKEN: http://www.softwarepreservation.org/projects/lang/GEDANKEN/ http://www.softwarepreservation.org/projects/lang/GEDANKEN/

kensai 12y ago

The predecessor of C was typeless as well.

techdebt5112 12y ago
as is C
- anacrolix 12y ago
  Almost
  - techdebt5112 12y ago
    it's sort of like trying to argue that "Whose Line" is not a game without points. There are types there, but they don't matter at all. You can cast anything to anything and it will never fail.
    - vidarh 12y ago
      Try to cast everything to the same type in C, and you quickly see that isn't true. While C does not give you safety, the typing is important for ease of access to members of structures, for example, and for deciding the number of bits or bytes to operate on, and for deciding layout of a type. The moment you go fully typeless, you suddenly need to be explicit about layout, size and signedness far more places.
    - yuubi 12y ago
      int f(float x) { return *(int *)x; }
      - vidarh 12y ago
        That program refuses to compile not because you can't cast to/from arbitrary types in C, but because you don't make your intent explicit (assuming I read what you tried to do correctly). Try this: int f(float x) { return *(int *)&x; } On one hand you demonstrate that C cares a tiny little bit about type, but mostly because of implicit numeric conversions rather than any serious attempt at stropping you from bad casting. I do agree with the point that C isn't "typeless" in any real sense, though.
        jeorgun 12y ago
        I think the original was intentional. If C refuses to let you cast from a non-pointer to a pointer, then it is in fact enforcing some (small) degree of type-safety.
        vidarh 12y ago
        The reason I assumed it was not, is that obtaining the bitwise representation of a float is something people actually often ask for (and my variation is not the "right" way to do so). You may be right C does not refuse to let you cast from a non-pointer to a pointer either, though. It just forces you to be slightly more devious in this case: return *(int **)&x; Though I think the implicit conversions that force some of these contortions (e.g. "(int *)(int)x" compiles, but does not return an integer pointer with the address equal to the bit pattern of "x" interpreted as an integer, but the integer portion of the float reinterpreted as a pointer) are more convincing demonstration that C is not typeless in a meaningful way in my opinion, as they also mean identical statements will give different results depending on the types of the variables.
        vegedor 12y ago
        Well, you are laying of the safety belt there, don't complain afterwards. It make sense to me in some cases, so i won't even argue.
    - Eridrus 12y ago
      Not sure where I was reading this the other day, but types have two advantages: abstraction and checking. You can add a third one to that list: safety. C has types in the sense that it allows you to do abstraction, and type checking, but it doesn't enforce safety. 2/3 doesn't seem bad to me, especially for a systems language. I'd say that Typescript is in a similar position, you can cast anything to any type you want and there is no runtime check to stop you, but it helps you add structure to your code. Types do very much matter in these languages in practice, since you want to very much want to avoid writing a giant mess.
      - vegedor 12y ago
        Of course C has safety features for the type system, warnings for problematic casts, and structs that can't be cast unless specifically unionized and explicitly ordered to.
vidarh 12y ago
BCPL, though I've never used it (my exposure to BCPL was mostly swearing at it because early parts of AmigaDOS was written in it, and at least that version of BCPL annoyingly stored memory addresses shifted, so when dealing with them C you could never de-reference them directly), was my dubious inspiration for avoiding typing early on in my compiler articles [1]. This before I went overboard and started layering a Ruby compiler on top of it. While I'm adding a tiny little bit of typing to it these days, it's only to distinguish "must be a Ruby object" from "can be anything". You can get away with no type information for surprisingly much. The main hassle is dealing with layout of structured data, but even then it's relatively straight-forward to deal with through a combination of memory and documentation (but maybe it's the assembly programmer in me - my first compiler was written in m68k assembly and then gradually translated into inline assembly in the language the compiler was for) That core is not by any means a fully fledged usable language, though, which BCPL of course was/is. Martin Richards, the creator of BCPL even still has a web page for it that includes a BCPL distribution [2] with both examples and the compiler. [1] http://www.hokstad.com/compiler http://www.hokstad.com/compiler [2] http://www.cl.cam.ac.uk/~mr10/BCPL.html http://www.cl.cam.ac.uk/~mr10/BCPL.html

shaunxcode 12y ago

Here is a non pdfy link: ftp://ftp.cs.cmu.edu/usr/jcr/gedanken.pdf

abecedarius 12y ago

http://www.erights.org/history/morris73.pdf http://www.erights.org/history/morris73.pdf is a great follow-up with more code in GEDANKEN. https://www.hackerschool.com/blog/46-paper-of-the-week-on-understanding-data-abstraction-revisited https://www.hackerschool.com/blog/46-paper-of-the-week-on-un... introduces a much more recent essay exploring these ideas about procedural data structures.