Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

pdf.yt

Post reply on HN
Print view View original

11–19 of 19 posts

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

#11

Post by vidarh »

kensai wrote: post #2

The predecessor of C was typeless as well.

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 [2] http://www.cl.cam.ac.uk/~mr10/BCPL.html

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

#12

Post by vidarh »

yuubi wrote: post #6
techdebt5112 wrote: post #5

Earlier quoted context omitted.

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.

int f(float x) { return *(int *)x; }

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.

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

#13

Post by jeorgun »

vidarh wrote: post #12
yuubi wrote: post #6

Earlier quoted context omitted.

int f(float x) { return *(int *)x; }

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 casti…

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.

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

#14

Post by vidarh »

jeorgun wrote: post #13
vidarh wrote: post #12

Earlier quoted context omitted.

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 casti…

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.

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.

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

#15

Post by vegedor »

Eridrus wrote: post #7
techdebt5112 wrote: post #5

Earlier quoted context omitted.

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.

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…

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.

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

#16

Post by vegedor »

vidarh wrote: post #14
jeorgun wrote: post #13

Earlier quoted context omitted.

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.

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…

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.

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

#17

Post by [deleted] »

vidarh wrote: post #12
yuubi wrote: post #6

Earlier quoted context omitted.

int f(float x) { return *(int *)x; }

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 casti…

[deleted]

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

#18

Post by yuubi »

vidarh wrote: post #12
yuubi wrote: post #6

Earlier quoted context omitted.

int f(float x) { return *(int *)x; }

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 casti…

The intent was to show that (at least one implementation of) C does stop a completely nonsensical cast from float to pointer, not to demonstrate anything semi-sensible like getting the bits of a float.
Post reply on HN