This is very closely related to a previous question of mine. From the comments to this previous question, I understand that my approach here is completely wrong headed. So why bother post a question, right?

I'm posting this question because, in my attempts at debugging and creating a work-around, I have what seem like essentially equivalent approaches but I'm getting different behavior when I run the document through LaTeX.

Here's the MWE:

\documentclass{article}
\usepackage{pstricks,pst-node}
\usepackage{xparse}
\ExplSyntaxOn
\prop_new:N \g__sunset_plist
\tl_new:N \l__temporary_tl
\NewDocumentCommand{\setattr}{ mm }
    {
        \prop_gput:Nnn \g__sunset_plist {#1} {#2}
    }
\DeclareExpandableDocumentCommand{\gettr}{ m }
    {
        \prop_get:Nn \g__sunset_plist { #1 } \l__temporary_tl
    }
\DeclareExpandableDocumentCommand{\gettrdebug}{ m }
    {
        \msg_term:x { I've ~ been ~ passed ~ #1}
        \prop_get:NnN \g__sunset_plist { #1 } \l__temporary_tl
        \tl_use:N \l__temporary_tl
    }
\ExplSyntaxOff
\setattr{my_linestyle}{linestyle=dashed,linecolor=blue}
\setattr{my_line}{\psline[linestyle=dashed,linecolor=blue](A)(B)}
\pagestyle{empty}
\begin{document}

\begin{pspicture}(10,10)

    \pnode(0,0){A}
    \pnode(10,10){B}
    \pnode(10,0){C}
    \pnode(0,10){D}


    \gettr{my_line}   %% <-- works as expected
    \psline[\gettr{my_linestyle}](C)(D)  %% <-- not working
    \psline[\gettrdebug{my_linestyle}](C)(D)  %% <-- not working

\end{pspicture}

\end{document}

In this MWE, \psline[\gettr{....}]... generates the error:

! Package xkeyval Error: `linestyle=dashed,linecolor=blue' undefined in familie
s `,pstricks,pst-node'.

See the xkeyval package documentation for explanation.
Type  H <return>  for immediate help.
 ...                                              

l.36     \psline[\gettr{my_linestyle}](
                                       C)(D)  %% <-- not working

And as explained to me in my previous approach, this is just wrong headed. But what's perplexing me is that \psline[\gettrdebug{...}]... just hangs.

Aren't these two functions essentially doing the same thing? Why does one create a recoverable error and the other seem to hang?

  • 1
    As David says, you've got a quark here. Broadly, unless you know that a property list will contain an item you should use on of the TF versions to test. – Joseph Wright Feb 6 '13 at 20:39
up vote 5 down vote accepted

Beware of playing with quarks, they can bite the unwary. Add \tracingall and you see

\g__sunset_plist ->\q_prop my_linestyle\q_prop {linestyle=dashed,linecolor=blue
}\q_prop my_line\q_prop {\psline [linestyle=dashed,linecolor=blue](A)(B)}\q_pro
p 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

\q_prop ->\q_prop 

that is you are in an infinite loop expanding a command that expands to itself.

  • (Question 1) So did I get in this loop because I made a none expandable function call in my expandable function? The thing is, even if that is what I did, \gettrdebug seems to work fine if not called from inside \psline[...]. (Question 2) why is the infinite loop only occurring when inside \psline[...]? – A.Ellett Feb 6 '13 at 20:42
  • 2
    yes basically it's classic latex fragile command in moving argument error, latex3 provides higher level structures but it can't protect you from all realities of TeX programming. – David Carlisle Feb 6 '13 at 20:48

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.