User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0)
            Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
References: <19in0asqvv02p$.dlg@nililand.de>
            <554CF61C.6070700@latex-project.org>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Message-ID:  <55520F64.4020008@morningstar2.co.uk>
Date:         Tue, 12 May 2015 15:34:12 +0100
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Joseph Wright <joseph.wright@MORNINGSTAR2.CO.UK>
Subject: Re: TeX capacity exceeded, with \prop_map_inline
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <554CF61C.6070700@latex-project.org>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 08/05/2015 18:45, Mittelbach, Frank wrote:
> On 08.05.2015 18:48, Ulrike Fischer wrote:
>> Is this a bug? Or simply something one must remember when using
>> c-type arguments?
> 
> 
> interesting question. On the whole we have not burdened expl3 with a lot
> of checking to avoid it getting too slow, i.e., in case with very well
> defined rules it is up to the programmer not to violate them
> 
> finite recursion (especially those that end up in quarks executing are
> something we made usually an exception as they are pretty nasty.
> 
> as for the rule: "c" should not be misused to do an implicit "new" even
> though that obviously works for some data types (if you know the
> underlying coding). For the "prop" type that doesn't work as
> \c_empty_prop" is quite different from \relax
> 
> so perhaps it is worth thinking of adding to functions for types like
> that always a quick initial check to see that the variable is a prop or
> rather at least not simply generated as a name from "c"
> 
> of course it would be a test happening each and every time
> 
> thoughts?
> 
> frank

Probably we should add something: as Ulrike says, at the very least
\prop_show should complain.

Joseph