In #Go, you cannot call the String method on a literal URL struct ("cannot call pointer method String on url.URL") because the String method has a pointer receiver. String does not modify the object, but it uses a pointer receiver to avoid copying the object for each call.
This is what you get when 1/ you design a language with pointers (why would you do that in 2009?) and 2/ you do not have "const".
@holgerschurig And yet I use C libraries just fine in Common Lisp, a language which does not use pointers as a language mechanism. No intermediate C. A pointer is just an address, as long as your language has integers and the necessary primitives to call C code, you can use C libraries directly. Ruby FFI does the same thing.
@galdor Using integers for this sounds very lispy: a crude hack that then survives decades. Not because it is good, but only because it is good enough.
I mean, which other programming language uses assembler mnemonics from a long died of computer system today? car / cdr ...
You do realize that pointers are memory addresses, which are simply integers
Sure. But that's a very incomplete picture. Not outright wrong, but incomplete.
Today pointers in C are almost never "void *ptr". But instead "struct foo *ptr". So you get some type checking.
So you might frown on pointers in your high-level language ... but when you emulate pointers, you fall back to the worst possible implementation. Some integers that cannot be type-checked at all.
Linux for example all the time invents new syscalls and ioctl(). Many more than e.g. the GNU C library covers. Many of these use pointers. And if I write a function prototype for them, then I'd of course use typed pointers. It makes little sense to not use this to prevent --- type checking helps oneself from shooting into the foot.
So, if you frown about pointers --- which I can fully understand! --- at least provide a better alternative. Not a worse one.
But maybe my view is too much a systems programmer view, I value languages mostly from a systems programming point of view (where I e.g. like Nim, D or Rust, but not so much Python, Lua, and anyone of the 100s of Lisps). So I might be preoccupied!
Modern Common Lisp implementations also have typed foreign types, this is not the wild west ;) Pointers are not "emulated", I honestly have no idea what you imagine. There are a lot of issues with Common Lisp, and I'm the first one to complain about them, but working with C libraries has always been very comfortable compared to what it is in Ruby, Erlang, or even Go (well, CGo).
I do not frown on pointers in general (I wrote way too much C professionally for that), but they do not make sense in Go: there is a GC and pointer arithmetic is not available! There is nothing useful you can do with them, and they cause so many headaches.
Earlier you wrote that "pointers are memory addresses, which are simply integers". And more importantly, after I mentioned Lisp and that maybe it has trouble calling system calls.
And now you write "Modern Common Lisp implementations also have typed foreign types"
So accept what I wrote was based on unclear information transfer :-)
Add comment