In response to Lummox JR
Lummox JR wrote:
Here's the dirty secret at the heart of DM that has made this problem difficult: The . and : operators live a dual life. DM uses them along with / as path operators, but it also uses them as var/method access operators. And it turns out to the parser, they're identical.


Not a secret, I've documented this fact extensively over the years. =P (It's still a mess of nonsense though and I never tell people to use it)
Praise u based gods
Progress report: I have this line of code working:

world << contents.Copy().len

That's pretty quick work, all things considered. Adapting the parser, the code generator, and a few other bits and pieces has been quite difficult.

Interestingly this change doesn't particularly need to wait for 512 that I can see--that is, it involves no new instructions--but because it's a syntax change I'll be holding off on releasing it till 512 regardless.

Next I'm gonna test if I can get this to work with assigning to a chained expression, and then I'll test with chaining from lists (which should work the same).
This is arousing news.
In response to Lummox JR
Lummox JR wrote:
Interestingly this change doesn't particularly need to wait for 512 that I can see--that is, it involves no new instructions--but because it's a syntax change I'll be holding off on releasing it till 512 regardless.

With this accomplished, now I'm kinda wondering if something like Dart's .. operator would be worth pursuing.
In response to Lummox JR
Lummox JR wrote:
With this accomplished, now I'm kinda wondering if something like Dart's .. operator would be worth pursuing.

If I read correctly it would be something like

src
..proc()
..proc()


Same as src.proc() src.proc()?
My understanding of this, is that .. use is called a cascade.

Basically, the interpreter stores the last object that was called on.

So:

a.b()
..c() //calls c() on a
..density = 0


The .. operator stores the last object you called a method on so you can do sequential operations on an object without having to actually store it.

This is useful for stuff like this:

//list/l
for(var/pos in 1 to l.len)
if(l[pos].onTick())
..last_tick = world.time


Whereas without this chaining, the structure would wind up having to be more like this:

//list/l
var/atom/o
for(var/pos in 1 to l.len)
o = l[pos]
if(o.onTick())
o.last_tick = world.time


This is of course assuming you don't want to do an in-place copy of the list l via for(o in l) pattern.
In response to Ter13
Ter13 wrote:
> //list/l
> for(var/pos in 1 to l.len)
> if(l[pos].onTick())
> ..last_tick = world.time
>

This looks like it would perform faster imo, hopefully it gets added, I can see the potential for it now.
In response to Ter13
That's not exactly what the cascade "operator" does... at least, not in Dart.

https://www.dartlang.org/guides/language/ language-tour#cascade-notation-

It uses the last reference before any cascades.
a // a is to be used by the cascades.
..b() // a.b()
..c() // a.c()
..density = FALSE // a.density = FALSE

Your first snippet would actually do this:
a.b()
..c() // calls a.b().c()
..density = 0 // does a.b().density = 0
// (a.b() is only called once, of course)

It's shorthand for making a variable initialized to the target expression to use it immediately:
var foo/foo = a.b()
foo.c()
foo.density = 0
Page: 1 2 3 4

Login to reply.