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.
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
While you're at it any chance for the ability to do this?
proc SpaceInsteadofSlashpls()

atm it produces
SpaceInsteadofSlashpls: undefined proc
Lummox JR resolved issue with message:
Proc calls and list reads can now be used in conjunction with the . or : operators. Since procs do not have such a thing as a return types and there is no such thing as a typed list, . and : behave identically in these cases.
Is it wise to have the . operator behave the same as the : operator? In an analogous case, calling functions on proc return values, the . operator rightly throws a compile error, because the compiler does not know the type of the return value. But the : operator works, as it is meant for unsafe access. It seems to me that the semantics are the same: typed lists don't exist, so only the : operator should work.
Page: 1 2 3 4