Are there any plans in arc2c or SNAP to reify pointers and direct memory addressing in arc? I realize that isn't very "lispy" but it would be way cool to be able to do low level byte mashing/memory management in an otherwise high level language.
pointers + macros = really cool or really dangerous.
Maybe we should go for something a bit like erlang's bit syntax instead.
Err, no. Hehe. Although I believe some Lisps actually implemented their memory managers (GC!) in Lisp itself ^^, but I think it was back when Lisp was more imperative (i.e. when (prog ...) with labels was more popular).
Hmm. Interesting idea, although I can't quite imagine how to do this.
"interesting" doesn't convey much information. Does it mean positive interesting, as in you'd be interested in trying it? Or does it mean negative interesting, as in your interested in why I would want such a crazy feature in the first place? :)
> Does it mean positive interesting, as in you'd be interested in trying it?
This one. If it were the negative interesting, I'd ask you directly "what for?" ^^
Hmm. Although it might be difficult to do with a copying GC.
As an aside, I'm thinking of exposing the "sharedvar" objects into arc, basically they would be called the "container" type. An arc-on-mzscheme implementation would be:
Basically assigning to it would be equivalent to setting the pointer, and (foo) would be equivalent to (* foo) in C.
I thought it might be useful in a C FFI (when I get there in, say, T=inf). If a C function accepts a int*, for example, where it would put an int, you would pass in a container, which would automagically get the int.
Sounds like a reasonable syntax. Would the value in a container in a container be accessed with ((foo))? It fits, but it might get old after a while.
Also, how similar would these "containers" be to pointers? It doesn't seem like it would be as useful, because I doubt you can increment/decrement a container.
So, what are the problems we might encounter if we actually use this?
The value pointed to by the container would be accessed with (foo), just a single layer of parens. The container's pointer would be mutated as (= (foo) ...) though. Oh well.
Edit: Oh, you said "container in a container". Yes, ((foo)) it is.
> It doesn't seem like it would be as useful, because I doubt you can increment/decrement a container
This functionality would be in a scanner, although a scanner, technically, would be just an iterator.
For instance, I fully intend to implement string scanners and input file scanners on the C++-side in SNAP; they would be somewhat "safe" wrappers around C++ iterators, which are just a generalization on the pointer. so (car foo) would be *foo and (cdr foo) would be (foo + 1).
> what are the problems we might encounter if we actually use this?
None at all, if you're talking about just containers and scanners. A container is just a reference to an Arc object. A scanner would just be an Arc-safe wrapper around an iterator.
