Thoughts about dicts and objects #97

New Issue

scott · 2024-07-01T23:52:49Z

scott commented

2024-07-01 23:52:49 +00:00

The alternative to #96 is a dict-based object system. We could develop special syntax, and it would probably be almost exactly like Python or Javascript:

let proto = #{
  :foo fn (self, arg) -> fobulate (self, arg)
}

let instance = #{
  :proto proto
  :bar fn (self, arg) -> quux (self, arg)
  :put fn (self, key, value) -> assoc (self, key, value)
}

instance :bar (instance, 42) & quux'ed 42
instance :foo (instance, 23) & frobulated 23
instance :put (instance, :foo, :bar) & a new instance! no changes to `instance`
& but note: the above line clobbers the `:foo` on the prototype

So you'd get a magic field, :proto, that acts as a prototype object; you'd probably want magic naming of functions acting as methods, so that methods wouldn't be anonymous functions; and you might want syntax sugar of something like ::method (arg) which would desugar into :method (self, arg).

In many ways, this is a much, much simpler arrangement than the actors + message passing situation. (You'd actually need a function to make new instances, but that's not important.)

It would not introduce any new concepts, especially. You'd be storing functions in dicts, instead of in packages. I guess there's something about delegation to a prototype. You'd get the convention (that seems annoying in Python, but way less annoying in Zig) of accepting self as an explicit argument. But, because of that, it also feels like it's not especially important to include. In the sense that it may not make sense as to a "why?" when you could just use data & functions.

That said, unlike the actors + messages arrangement, it does not require any additions to the language, with the exception of delegation using a :proto field. This addition would effectively give you the old model of a Javascript prototypical inheritance scheme.

But again, why do that when you can do pattern matching? It doesn't give you asynchrony or concurrency, it doesn't allow for decoupling message sending and receiving, it doesn't allow for error handling. But it's there.

The alternative to #96 is a dict-based object system. We could develop special syntax, and it would probably be almost exactly like Python or Javascript: ``` let proto = #{ :foo fn (self, arg) -> fobulate (self, arg) } let instance = #{ :proto proto :bar fn (self, arg) -> quux (self, arg) :put fn (self, key, value) -> assoc (self, key, value) } instance :bar (instance, 42) & quux'ed 42 instance :foo (instance, 23) & frobulated 23 instance :put (instance, :foo, :bar) & a new instance! no changes to `instance` & but note: the above line clobbers the `:foo` on the prototype ``` So you'd get a magic field, `:proto`, that acts as a prototype object; you'd probably want magic naming of functions acting as methods, so that methods wouldn't be anonymous functions; and you might want syntax sugar of something like `::method (arg)` which would desugar into `:method (self, arg)`. In many ways, this is a much, much simpler arrangement than the actors + message passing situation. (You'd actually need a function to make new instances, but that's not important.) It would not introduce any new concepts, especially. You'd be storing functions in dicts, instead of in packages. I guess there's something about delegation to a prototype. You'd get the convention (that seems annoying in Python, but way less annoying in Zig) of accepting `self` as an explicit argument. But, because of that, it also feels like it's not especially important to include. In the sense that it may not make sense as to a "why?" when you could just use data & functions. That said, unlike the actors + messages arrangement, it does not require _any_ additions to the language, with the exception of delegation using a `:proto` field. This addition would effectively give you the old model of a Javascript prototypical inheritance scheme. But again, why do that when you can do pattern matching? It doesn't give you asynchrony or concurrency, it doesn't allow for decoupling message sending and receiving, it doesn't allow for error handling. But it's there.

scott commented

2024-07-02 23:43:16 +00:00

After a conversation with @matt today, we've decided NOT to go with dict-objects. The Actor Model it is! (Not to be confused with the actor/model.)

scott closed this issue

2024-07-02 23:43:16 +00:00

Sign in to join this conversation.