[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Txr-users] fail to use a function as the <replacement> object in @(

From: Kaz Kylheku
Subject: Re: [Txr-users] fail to use a function as the <replacement> object in @(regsub <regex> <replacement> <string>)
Date: Sat, 13 Jul 2013 07:57:37 -0700
User-agent: Roundcube Webmail/0.4

On Sat, 13 Jul 2013 17:16:13 +0800, 苏灵 <address@hidden> wrote:
> 2013/7/13 Kaz Kylheku <address@hidden>
>> The main problem here is that string literals don't support
>> backslash-newline continuation like
>> C, the POSIX shell or Makefiles. They are single line only, oops!
> That is a trivial detail. I will be careful to avoid this kind of mistake.

I'm afraid that I lied!

In fact, continuations work in string literals and regexes. The
behavior is just not adequately documented for string literals. This was
introduced in version 38 almost two years ago:
ChangeLog entry:

2011-09-29  Kaz Kylheku  <address@hidden>

        * parser.l: Implemented backslash continuations in SPECIAL
        state, regexes and string literals.

        * txr.1: Documented.

However, what seems to be missing is support for the sequence "\ "
(basckslash space)
to escape a space. This is useful because in TXR line continuations,
the leading
whitespace of the continuing is eaten. So for instance you can write


this denotes the string "abcdef" not "abc      def".   If you wanted
"abc def",
it should be possible like this:

    \ def"

Alas, it doesn't work.

> That is interesting.I was using Scheme, I had never use lisp for real coding.
> As I know, functions and variables are stored in different namespace in
> common lisp. However, they share one namespace in Scheme.
> Does this mean, in the scope of  "DWIM brackets", if the TXR
> interpreter can't
> find a name in the namespace of  variables, the interpreter will look
> for it in the
>  namespace of functions?

That's right, but function space lookups remain function space

So it's not the case that function calls nested in the DWIM
bracket scope become Lisp-1 style; just the treatment of their

The scoping behavior is only implemented to the extent that
it is necessary for convenience. It's nice to be able to
do something like:

  [mapcar (chain func1 func2) list]

where we don't care whether func1 are function or variable
bindings, without having to use the square brackets again.
But if chain happened to be a variable that holds a function
and we wanted to call that, then we would need the square

reply via email to

[Prev in Thread] Current Thread [Next in Thread]