Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


#64 w $$@handler is borked

Steve Zeck

This works:

s handler="label^routine"
d @handler@("param1","param2") ; spiffy!

This doesn't:

s handler="^x" w $$@handler
%GTM-E-LABELMISSING, Label referenced but not defined:

or this:
s handler="label^routine(""firstarg"")"
w $$@handler
%GTM-E-LABELMISSING, Label referenced but not defined:

It appears that $$@var truncates the label/routine name
contained in 'var' to 8 characters (or pads it out to 8
with the word 'PADDING' if it's shorter)

Even if you can get it to come out to 8 characters
exactly it still breaks with 'LABELMISSING'

s handler="labl^rtn" w $$@handler
%GTM-E-LABELMISSING, Label referenced but not defined:

As it is, we were impressed that 'd @handler@(args)'
works, we'd never thought to try it. It would be nice
if we could get the return values too, though there are
workarounds for that (use a globally-defined local
variable, pass a variable by reference, etc..)

This would be great for bludgeoning objects and methods
into M if the minor problem of $$@var could be fixed.

d new^object(.objref)
d @objref("method")@(param)


  • Steven Estes
    Steven Estes

    Logged In: YES

    This looks like it is likely a case of a fairly common
    indirection usage confusion. There are two types of
    indirection: expression indirection and name level
    indirection. The two are NOT interchangeable and are used in
    different situations. The argument for $$ is name level
    indirection which means nothing but a routine OR variable
    name can be put there. The term "label^routine" is an
    expression and cannot be used in name level indirection. If
    you want to specify both routine and label you have two choices:

    In an expression situation, you do something like:
    S handler="$$labl^rtn" w @handler

    For a name situation you do something like:
    S hndllbl="labl" S hndlrtn="rtn" W $$@lbl^@rtn

    However, in this later example, there do appear to be some
    issues with passing parameters (they get treated as part of
    the indirection expression even if rtn is terminated by a
    '@'). I haven't looked up the actual parsing rules in that
    situation so I'm not ready to call it a bug *yet*.. ;-)

    Hope that answers your question