PXSL Ask-a-Question If you have a question that isn't answered elsewhere, please ask it below. (You'll have to register first. Sorry about that.) We'll do our best to answer promptly. If for some reason you don't want to register or ask your question in a public forum, feel free to send me email at {link:tom@moertel.com|mailto:tom@moertel.com}. 1.1 Probs on MacOSX, Drift Sources see: [PXSL Ask-a-Question/MacOSX, ghc 6.4 , Drift Sources] 2006-07-15 00:40:43.805 2003-06-10 17:19:07.664 comment-PXSL Ask-a-Question-1 I've been playing around with PXSL and have noticed that it barfs on tabs. Is this intentional? 2003-06-13 15:34:58.536 2003-06-13 15:35:00.024 comment-PXSL Ask-a-Question-2 Yes. Tabs are evil as far is PXSL (and most layout-driven syntaxes) are concerned. Either you pick a fixed tab width, which hoses (perhaps silently) the camp of folks who don't agree with your choice, or you disallow them altogether, which is what PXSL does. How do you think that PXSL ought to handle tabs? 2003-06-13 16:46:13.352 2003-06-13 16:46:18.424 comment-PXSL Ask-a-Question-3 One more thing on tabs: If you have a Unix-like environment (e.g., {link:Cygwin|http://www.cygwin.com/} on Windows), you can use the __expand__ command to "detabify" your files. It converts each tab into the appropriate number of spaces. For example, if your editing environment placed a tab stop every four spaces, you could detabify your files like so: {code} expand -4 tabs.txt > no-tabs.txt {code} Or, more to the point: {code} expand -4 myfile.pxsl | pxslcc > myfile.xml {code} Nevertheless, I still recommend not having any tabs in your source files because tabs are fragile, fickle things. 2003-06-13 23:47:11.096 2003-06-13 17:14:38.568 comment-PXSL Ask-a-Question-4 Tom, PXSL is very very well done. Quite aside from the fact that XSLT is finally somewhat readable, the fact that you've added a serious macro system means that some serious scripting of XML can occur. I'm very impressed. So far I've been able to do everything I try to do -- except one thing. To wit: I would like to have a macro such that: ,command c a1 a2 a3 produces <a href="c?a1=,a1&a2=,a2&a3=a3">,BODY</a> In other words I would like to have macro parameters appear in an attribute However I can't find a way to do it. The '-attribute=' syntax binds too tightly, and there's nothing I can pass to -href= that doesn't instantly get treated as a single string. The closest I've gotten is: ,command c a1 a2 a3 = a -href=<( ,command <<?a1=>> a1 <<&a2=>> a2 <<&a3=>> a3 )> which for ',command -a1=s1 -a2=s2 -a3=s3' at least produces '<a href="command">' But that's it. Can't get past the first string. I imagine the current implementation cannot do what I'm trying to do. But do you see the utility of it? Thanks for any help. And thanks muchly for a very nice tool. 2004-01-03 01:53:39.512 2004-01-03 01:53:41.704 comment-PXSL Ask-a-Question-5 First, thanks for the kind words about PXSL. Second, good question. And, I have the answer you are looking for: Yes, you can do this in stock PXSL. The key is to remember that the <( )> delimiters open a full ~~pxsl-fragment~~, which lets you include any number of statements into an argument value. The results of the statements are concatenated to yield the final argument value. With that in mind, here's one solution: {code:none} ,command c a1 a2 a3 = a -href=<( ,c <<?a1=>> ,a1 <<&a2=>> ,a2 <<&a3=>> ,a3 )> ,BODY ,command cmd param1 param2 param3 <<My command link>> {code} which produces the following output when processed with __pxslcc -i__: {code:xml} <a href="cmd?a1=param1&amp;a2=param2&amp;a3=param3">My command link</a> {code} Strictly speaking, we ought to rewrite the above output so that bare ampersands don't appear in the CDATA value of the ~~href~~ attribute: {code:xml} <a href="cmd?a1=param1&amp;amp;a2=param2&amp;amp;a3=param3">My command link</a> {code} While ampersands are fine in URLs, they ought not to appear unescaped in URLs placed inside of attribute values. Fortunately, we can use PXSL's <\{ \}> delimiters to take care of the escaping for us automatically. Also, to make the code's workings a little more obvious, we could factor out the portion that builds the argument body and compact the lines where the arguments' names and values are joined. Thus we end up with the following, final version of our macro: {code:none} ,command c a1 a2 a3 = a -href=<(,hrefval)> ,BODY \# build href value from arguments ,hrefval = ,c <{?a1=}> ,a1 <{&a2=}> ,a2 <{&a3=}> ,a3 {code} 2004-12-10 16:13:10.586 2004-01-07 16:24:13.624 comment-PXSL Ask-a-Question-6 Impressive. It's good to see functional programming out in the wild. I'm developing a tool which parses XML to create Swing users interfaces. I converted some of my files from XML to PXSL and the readability was much improved. I'm looking forward to playing with the macro system. Thanks. 2004-03-12 22:34:58.304 2004-03-12 22:34:36.632 comment-PXSL Ask-a-Question-7 Thanks for the friendly words about PXSL. After you use it for a while, please let me know what you think, good or bad. If you find anything confusing, let me know. If the docs are hard to understand, let me know. If you have any suggestions for improvement, please let me know. Cheers,\\ Tom 2004-03-12 22:35:19.456 2004-03-12 22:35:20.336 comment-PXSL Ask-a-Question-8 I came across roughly the same issue as Mr. invisible. You might want to consider putting an example in the docs. I have a question: How can I pass a sequence of one or more attribute name-value-pairs to a macro? I imagine that I might want something like a varargs macro. Thanks again. 2004-03-12 22:35:38.6 2004-03-12 22:35:38.04 comment-PXSL Ask-a-Question-9 Can you give me an example of where you might want varargs-like behavior? The reason I ask is because if there is a real need for it, I want to understand the root cause. Perhaps there is a more general way to support that need, and in doing so support other needs that varargs alone cannot. 2004-03-12 22:35:53.928 2004-03-12 22:35:53.784 comment-PXSL Ask-a-Question-10 (This doesn't necessary relate to my previous question, but it's in the same ballpark.) I'd like to be able to have (something like, modulo markup) this: ,defs = -a=b -c=d -e=f ... foo ,defs -test=true compile to: <foo a="b" c="d" e="f" ? test="true"/> Thanks. 2004-03-12 22:36:12.704 2004-03-12 22:36:15.04 comment-PXSL Ask-a-Question-11 I see. Right now, you can't splice attributes with stock PXSL, so you're ought of luck. (But you can assemble attribute ~~values,~~ as the earlier examples show. Not that it helps with your situation.) Let me think about the options. 2004-03-12 22:36:30.76 2004-03-12 22:36:30.576 comment-PXSL Ask-a-Question-12 Thanks for the answer. That's what I thought. It's a "would be nice to have" rather than a "must have" for me. 2004-03-12 22:36:43.848 2004-03-12 22:36:45.872 comment-PXSL Ask-a-Question-13 It seems that pxslcc exits with success (0) even on a parse error. 2004-03-12 22:37:06.12 2004-03-12 22:37:05.288 comment-PXSL Ask-a-Question-14 Oops! Good catch, Chris. I have uploaded a quick-fix version 0.9.2 ({link:source|http://community.moertel.com/pxsl/sources/} and {link:RPMs|http://community.moertel.com/pxsl/RPMS/}) that should fix the problem. Please let me know if you have any difficulties with it. 2004-03-12 22:37:49.816 2004-03-12 22:37:48.28 comment-PXSL Ask-a-Question-15 Great, thanks. 2004-03-12 22:38:10.648 2004-03-12 22:38:11.616