TyOverby / ares

A Lisp made for easy integration with Rust.
9 stars 1 forks source link

Method Syntax #38

Open TyOverby opened 9 years ago

TyOverby commented 9 years ago

Method Syntax

Right now there is only one way to call a function on some data.

(move-player player x y)

But instead of polluting the global namespace, and in order to more closely relate objects and their properties, it would be nice to write this:

(player.move x y)

The lambda for move-player and player.move could be identical

(lambda (player x y)
    (setm player 'x x) ; hypothetical hashmap set function 
    (setm player 'y y)
    player)

but when called in the "method notation" (player.move), it would automatically place the player in the first argument slot.

This would only happen for Maps that have Symbols mapping to functions.

Fallback (optional)

This is an optional addition to method notation. When the receiver of a method call either isn't a map, or can't be found in the map, a function is looked for in the current environment and used instead.

(my-list.map (lambda (x) (* x x)))

Field Syntax

Same as method syntax, but for fields.

(print game-object.x) 

This might need to be different from method syntax, but it could be possible to join them together (so that (foo.bar x y z) is just doing a field access on foo.bar and calling it.

TyOverby commented 9 years ago

I split this up into two different issues so that we can focus on them individually

bwo commented 9 years ago

So if I'm implementing a function like move-player, do I also specify its "dot access name", and require that to be unique? Or how is the lookup from .move to move-player done?

TyOverby commented 9 years ago

My thought was that there would be no translation between move-player and .move. You would do one or the other.

Obviously in certain contexts function syntax makes more sense, and in others method syntax would be better.

bwo commented 9 years ago

Oh, I see.

TyOverby commented 9 years ago

The function would be defined the same way though. That is to say, (lambda (this x y) (...)) would be exactly the same regardless if it was a method or function.