Calling from a list.

Page: 1 2 3 4
Apr 19 2017, 10:15 pm (Edited on Apr 20 2017, 3:20 am)
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)
Apr 20 2017, 6:53 am
Praise u based gods
Apr 20 2017, 10:45 pm
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).
Apr 20 2017, 11:20 pm
This is arousing news.
Apr 21 2017, 2:05 pm
With this accomplished, now I'm kinda wondering if something like Dart's .. operator would be worth pursuing.
Apr 22 2017, 12:44 pm
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()?
Apr 22 2017, 12:57 pm (Edited on Apr 22 2017, 1:16 pm)
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.
Apr 25 2017, 1:57 pm
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.
Apr 25 2017, 2:23 pm
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
May 4 2017, 4:54 pm
While you're at it any chance for the ability to do this?
proc SpaceInsteadofSlashpls()

atm it produces 
SpaceInsteadofSlashpls: undefined proc
Sep 25 2017, 12:43 pm
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.
Sep 25 2017, 10:54 pm
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