On 07/01/2010 08:14 AM, Brad Long wrote: > > Yes, that makes sense, for example: (display pt.x)
You might want to check Racket's object system. It's different from structs, but is at least the kind of abstraction you're probably thinking of. (define point% (class object% (init-field x y) (super-new)) (define pt (new point% (x 1) (y 2))) (get-field x pt) => 1 (get-field y pt) => 2 (define point-x (class-field-accessor point x)) (point-x pt) => 1 ---------------------------- The problem with the syntax pt.x is that there is nothing in that syntax to indicate what type pt is. (point-x pt) is the C++ equivalent of ((Point)pt).x and normally pt.x automatically divines the type in C++. Not so in racket. The speed overhead of having "types" like that, which the compiler can introspect to identify certain properties such as what fields there are and what they do, that overhead is significant, so the default is that you have to specify that information manually in your code. That overhead might be smaller later though, and it's nothing you'd ever have to worry about for all but the most lean of applications. If you're interested in learning how Racket can perform that kind of type divination, you might consider learning the "typed racket" language. It's under active development now, but already is capable of a lot of that sort of type magic. http://docs.racket-lang.org/ts-guide/index.html _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
