A change to non result-returning methods?

[paulmansour]

In the middle of a dfn of a co-worker I saw the following line, which somewhat surprised me:

Code: Select all

some code
SomeDotNetObject.SomeMethod
more code

Despite the lack of assignment from the .Net method call, the function kept on running to the end. I assume this was because the method returned no result, and in fact, when I tried to assign a result I got a VALUE ERROR, so this seemed to bear this out. This was in a fairly recent but not the most current version of Dyalog.

In the most recent version of Dyalog however, this same method (from the exact same dll) actually returns a result, thus breaking the above code by causing it to exit early.

Has there been some subtle change to the .NET interface in this regard? I can't find a bug fix that would indicate this change.

[JohnS|Dyalog]

I'm surprised that the code following SomeDotNetObject.SomeMethod was reached. This feels wrong.
I'll try to find a simple reproducible example and report back.

[paulmansour]

John,

Thanks, but don't spend much effort on this. As I noted, the behavior has changed between two recent versions of the interpreter. I have a freely available dll (itext pdf library) where the offending method was from. If it's important I can put together a code example for you.

Paul

[Tomas Gustafsson]

Hey John, guys, my first post, i'm still alive and kicking :-). Good to see the activity here.

Q: Why does a dfn have to exit upon a call to a .net method like:

Code: Select all

void SetPosition(float32 x, float32 y, float32 z)

Dfns are exellent eg. for keyboard handlers in a game loop (the boat simulator, Stormwind) where an ongoing fight against time takes place. Always call the same dfn (to avoid conditional :'s) but change the contents of the dfn depending on for example the selected boat. Stylish and efficient!

Except that the dfn can hold one void method() call, or one per guard.

What harm could there be if the dfn continued execution after the void method() call? Or perhaps an ability to configurable this behaviour? Certainly this couldn't cause much overhead in the excellent dfn's handling segment of the APL interpreter?

v. 10.1

[JohnS|Dyalog]

Hi Tomas - good to hear from you.

> Q: Why does a dfn have to exit upon a call to a .net method like: ...

Dfns were designed to implement a functional, rather than a procedural, style of programming. Ignoring guards for the moment, a dfn is: an expression preceded by zero or more definitions used in that expression. For example:

    mean←{
        sum←+/⍵
        num←⍬⍴⍴⍵
        sum÷num
    }

Given this, it makes no sense to have anything following the result expression "sum÷num".

Secondly, in common with tradfns, we can have no-result- or void- returning dfns:

    0=⍴⍵:    ⍝ empty: finished
or
    sink←{}

This means that the "result expression" of a dfn is entitled to be void-returning, as in the example you give.

Even if we wanted to, it may be too late to change dfns' behaviour at this time. Note however, that APL#, which is designed to accommodate a procedural style of programming, does exactly what you want. In APL#, it's the last, rather than the first (and in the case of a dfn, only) executable expression that terminates the function.

John.

[Tomas Gustafsson]

I spent a fair anount of time trying to find a weakness in that logic, or a simple change in the functionality of dfns in order to accomplish what i was asking for.

Came out with nothing. Dismantled step by step, the current behaviour seems totally right and logical, also in companion with the void.

The only way to execute multiple void method() calls in a dfn is then:

a ← ⍎'void method1() {diamond} void method2() {diamond} 1'

... but that's not nice to look at.

(Also thought of "forgiving guards", for ecample a semicolon. Wouldn't enforce the jump out at the row - a simple if+end implementation, instead if an extra inner level dfn)

Maybe one could say it's a pity that the dfn won't do in this void-context, since it's so easy to create throw around. Something to keep behind the ear.

[JohnS|Dyalog]

FYI, there's a note about this problem in dfns.dws.
See http://dfns.dyalog.com/n_do.htm

[Tomas Gustafsson]

Hm... that's a 404. Perhaps temporary, i'll try later.

Be aware my ws's are loaded with dfns, as are likely most other dyalog coders' too :-). Thanks!