f



replacement for '{' and '}' ?

I am still playing around with what kind of syntax I would like to
mark up my documents.

Are there equivalent long substitutes for { and } when they are not
used to describe arguments to functions?  Something like \begin{group}
and \end{group}.

In other words, if I could force myself to write, say, \begin{group}
\it ... \end{group} instead of {\it ... }, then I believe I could
identify from the markup context what is an argument that belongs to a
just invoked macro and what is text.  {Of course, in this context,
\textit{...} would be better.}  No more ambiguity whether a in
\myfunction{a} is an argument or just text.

Is there a way to make latex barf when it sees an ordinary '{' in
text, rather than \begin{group}, but not barf when I want it (to
denote macro arguments)?

Regards,

/iaw
0
ivowel (414)
8/16/2008 5:01:11 PM
comp.text.tex 39027 articles. 3 followers. Post Follow

13 Replies
2718 Views

Similar Articles

[PageSpeed] 4

On Aug 16, 6:01=A0pm, "ivo...@gmail.com" <ivo...@gmail.com> wrote:
> Is there a way to make latex barf when it sees an ordinary '{' in
> text, rather than \begin{group}, but not barf when I want it (to
> denote macro arguments)?

What do you mean exactly? I don't understand. Do you have in mind your-
to-be-new-syntax or just regular latex?

Cheers,

Tomek
0
t.m.trzeciak (227)
8/16/2008 5:18:49 PM
ivowel@gmail.com wrote:
> I am still playing around with what kind of syntax I would like to
> mark up my documents.
> 
> Are there equivalent long substitutes for { and } when they are not
> used to describe arguments to functions?  Something like \begin{group}
> and \end{group}.
> 
> In other words, if I could force myself to write, say, \begin{group}
> \it ... \end{group} instead of {\it ... }, then I believe I could
> identify from the markup context what is an argument that belongs to a
> just invoked macro and what is text.  {Of course, in this context,
> \textit{...} would be better.}  No more ambiguity whether a in
> \myfunction{a} is an argument or just text.
> 
> Is there a way to make latex barf when it sees an ordinary '{' in
> text, rather than \begin{group}, but not barf when I want it (to
> denote macro arguments)?
> 
> Regards,
> 
> /iaw

Not sure what you are up to, but \bgroup and \egroup?
-- 
Joseph Wright
0
joseph.wright (1875)
8/16/2008 6:02:12 PM
ivowel@gmail.com wrote:

> Are there equivalent long substitutes for { and } when they are not
> used to describe arguments to functions? 

"function" - what does that mean in TeX?

{_1 and }_2 are scope-delimiters for several kinds of scope in TeX.
The scope in question can be the scope of a token's argument.
It can also be a new group wherein (local) definitions etc take
place.

> In other words, if I could force myself to write, say, \begin{group}
> \it ... \end{group} 

The \begin-macro opens up a new environment/scope/group.
The \end-macro checks by means of its argument whether
the appropriate environment/scope/group is about to be closed
and - if so - closes it.

You could write \newenvironment{Group}{}{} and then use
the Group-environment \begin{Group}..\end{Group} for
denoting a non-argument-scope.

You could also use \begingroup .. \endgroup - primitives
as long as they are not removed by some macro which uses
them as argument-delimiters ;->

> instead of {\it ... }, then I believe I could
> identify from the markup context what is an argument that belongs to a
> just invoked macro and what is text.
[...]
> No more ambiguity whether a in
> \myfunction{a} is an argument or just text.

What about:   \myfunction a  ?

You don't need braces for single-token-arguments. So there
would probably still be some ambiguity left. Also you 
probably don't need braces with delimited-argument-macros'
arguments.

If you could make LaTeX "barf" in case braces are used as
scope-delimiters not denoting the scope of an argument,
functionality of forking between argument-scope and
non-argument-scope would be broken:

\newif\ifPutIntoGroup

\newcommand\@ifPutIntoGroup{%
  \ifPutIntoGroup\else\expandafter\@firstofone\fi 
}%

% Now "Stuff" is not put into a group
\PutIntoGroupfalse
\@ifPutIntoGroup{Stuff}

% Now "Stuff" is put into a group
\PutIntoGrouptrue
\@ifPutIntoGroup{Stuff}

Ulrich
0
eu_angelion1 (617)
8/16/2008 6:30:01 PM
\bgroup and \egroup are exactly what I was looking for.  Thanks,
Joseph.

Ulrich: thanks for your post.  I do not understand the last part of
your post, which is what I would love to learn more about.  Say, I
would now use \bgroup and \egroup if I am not delimiting argument
scopes.  (Sorry, I often write incorrectly "function" when I mean
"macro" --- habit.)

Is there a way to get the following functionality:

\newcommand{\m}[1]{ok: #1}
\m{fine}  % no error
\m{fine}{barf}  % latex stops with an error that there is a text group
\m{fine}\bgroup barf \egroup  % this is what I need to replace it with
\m1   % latex stops with an error that says "\m required arguments,
but none were provided

I know its a lot to ask for, but neither arcane incapability for
simple tasks nor capability for very complex tasks in TeX no longer
surprise me...

/iaw
0
ivowel (414)
8/16/2008 8:12:58 PM
ivowel@gmail.com wrote:

> Ulrich: thanks for your post.  I do not understand the last part of
> your post, which is what I would love to learn more about.

The gist is: By conditional execution of \@firstofone,
you can remove a surrounding brace-group.
If \@firstofone is not executed, the braces remain
in place and can as well serve as non-argument-scope delimiters.

> Is there a way to get the following functionality:
> 
> \newcommand{\m}[1]{ok: #1}
> \m{fine}  % no error
> \m{fine}{barf}  % latex stops with an error that there is a text group
> \m{fine}\bgroup barf \egroup  % this is what I need to replace it with
> \m1   % latex stops with an error that says "\m required arguments,
> but none were provided
> 
> I know its a lot to ask for, but neither arcane incapability for
> simple tasks nor capability for very complex tasks in TeX no longer
> surprise me...

This is a very special case for which it seems possible.

First issue:

Such an \m-macro would need to "look ahead" token-wise,
not argument-wise. \(futute)let-assignments look ahead
tokenwise.

Second issue:

\meaning{         yields:  begin-group character {
\meaning\bgroup   yields:  begin-group character {
\meaning}         yields:  end-group character }
\meaning\egroup   yields:  end-group character }

Distinguishing \bgroup from { is needed while
\bgroup is defined as \let\bgroup={
\egroup is defined as \let\egroup=} .

Approach:

\m could be a left-brace-delimited macro which does not take
any argument and calls another macro which does fetch an
argument, temporarily give \bgroup another meaning as usual
and then check via \futurelet whether the next token equals {.

This of course requires that no other token's meaning is let
equal to the begin-group-character { .

Also \m is not expandable as \futurelet-assignments take place.

This is not a general approach as \m is about only one argument.
With more than one argument, you cannot easily raise errors in
case any of those arguments is not nested into braces as you
cannot easily use the #{-left-brace-delimiter-syntax then.
You could probably use some recursion but that is cumbersome
and ineffective.

Ulrich



\documentclass{article}

\makeatletter
\newcommand\m{}\def\m#{\innerm}%
\newcommand\innerm[1]{%
  \begingroup
  \def\bgroup{another meaning}%
  \def\tempa{#1}%
  \futurelet\tempb\innerinnerm
}
\newcommand*\innerinnerm{%
  \ifx{\tempb
    \iffalse}\fi% brace-balancing in macro-definition
    \expandafter\@firstoftwo
  \else
    \expandafter\@secondoftwo
  \fi
  {\expandafter\endgroup\tempa\@gobble{} - ERROR}%
  {\expandafter\endgroup\tempa\@gobble{} - OK}%
}
\makeatother
\begin{document}
\m{fine}  % OK

\m{fine}{barf}  % ERROR

\m{fine}\bgroup barf \egroup  % OK

\m1 % Error about \m not matching its definition.
\end{document}
0
eu_angelion1 (617)
8/16/2008 9:45:59 PM
ivowel@gmail.com wrote:
> Is there a way to get the following functionality:
> 
> \newcommand{\m}[1]{ok: #1}
> \m{fine}  % no error
> \m{fine}{barf}  % latex stops with an error that there is a text group
> \m{fine}\bgroup barf \egroup  % this is what I need to replace it with
> \m1   % latex stops with an error that says "\m required arguments,
> but none were provided

It would be asking for trouble, but I suppose you could have \m take no
arguments, set the category codes of "{" and "}" to 1 and 2 respectively
(their default values), and invoke a helper macro that takes one argument
and, after processing it, sets the category codes of "{" and "}" to 15
(invalid).  You'd of course have to play similar tricks with _all_ of the
macros you intend to invoke, including \begin and \end if you want to use
any LaTeX environments.

TeX provides a way to make "\m1" fail:  \def\m#{ok}

-- Scott
0
ctt (1173)
8/16/2008 9:47:43 PM
On Aug 16, 10:01 am, "ivo...@gmail.com" <ivo...@gmail.com> wrote:
> In other words, if I could force myself to write, say, \begin{group}
> \it ... \end{group} instead of {\it ... },

In this case you are best advised to use \begin{it}...\end{it}.

Donald Arseneau                                  asnd@triumf.ca


0
asnd (4601)
8/16/2008 9:56:15 PM
Scott Pakin wrote:

> It would be asking for trouble, but I suppose you could have \m take no
> arguments, set the category codes of "{" and "}" to 1 and 2 respectively
> (their default values), and invoke a helper macro that takes one argument
> and, after processing it, sets the category codes of "{" and "}" to 15
> (invalid).  You'd of course have to play similar tricks with _all_ of the
> macros you intend to invoke, including \begin and \end if you want to use
> any LaTeX environments.

One trouble might be dealing with nested braces within an
argument while the outer braces delimit the argument-scope
and some inner braces delimit a non-argument-scope. The inner
braces already got tokenized with catcode 1 and 2 respectively
although they should be of catcode 15. You might need to
switch catcodes within the macro and use \scantokens...

Another trouble might be primitives etc that take arguments.
A primitive cannot change catcodes. You could not use such
primitives directly any more.

Yet another trouble is about expandability. \catcode-assignments
are not expandable.

Ulrich
0
eu_angelion1 (617)
8/16/2008 9:57:00 PM
On Aug 16, 5:47=A0pm, Scott Pakin <scott+...@pakin.org> wrote:
> ivo...@gmail.com wrote:
> > Is there a way to get the following functionality:
>
> > \newcommand{\m}[1]{ok: #1}
> > \m{fine} =A0% no error
> > \m{fine}{barf} =A0% latex stops with an error that there is a text grou=
p
> > \m{fine}\bgroup barf \egroup =A0% this is what I need to replace it wit=
h
> > \m1 =A0 % latex stops with an error that says "\m required arguments,
> > but none were provided
>
> It would be asking for trouble, but I suppose you could have \m take no
> arguments, set the category codes of "{" and "}" to 1 and 2 respectively
> (their default values), and invoke a helper macro that takes one argument
> and, after processing it, sets the category codes of "{" and "}" to 15
> (invalid). =A0You'd of course have to play similar tricks with _all_ of t=
he
> macros you intend to invoke, including \begin and \end if you want to use
> any LaTeX environments.
>
> TeX provides a way to make "\m1" fail: =A0\def\m#{ok}

Indeed, I heartily agree that this is asking for trouble, and so I
will disclaim the following ramblings as being thoroughly Evil.  But
as long as { and } are catcoded to 1 and 2, TeX will never have a
problem with using them for delimiting groups.  On the other hand, I
could imagine the following setup:
  { and } are active, and \def'd to give an error (I would catcode to
invalid, but we may want \{ and \}).
  \ is active and used to call macros.
  \macro(arg1,arg2) would turn into \macro{arg1}{arg2}.
We need a way to deal with optional arguments, so we can give an
optional argument telling how to treat each of the arguments
(optional, required, delimited, single-token, etc...)
  \section[*or](short,long) would turn into \section*[short]{long}.

This would fail miserably with AMS and verbatim environments.  Also,
now NOTHING is expandable, so a heck of a lot else would break too...
If you don't want to strictly enforce the \m1 error, then you could
leave \ as an escape character and instead use * or something to call
macros.  Then, some macros would still be expandable, but not many,
since you can't pass multi-token parameters...

This seems like it would be mildly interesting to write, but would
take a few hours and is a bit too morally expensive for me to actually
carry out...  This way leads to the Dark Side.

Cheers,
steve
0
stephenhicks (127)
8/16/2008 10:03:37 PM
Steve Hicks <stephenhicks@gmail.com> writes:

> Indeed, I heartily agree that this is asking for trouble, and so I
> will disclaim the following ramblings as being thoroughly Evil.  But
> as long as { and } are catcoded to 1 and 2, TeX will never have a
> problem with using them for delimiting groups.

\def\barfm#1#2{#1\csname barf#2\endcsname#1}
\def\barfc#1{}
\def\forbidgroups{\expandafter\barfm\expandafter\bgroup\romannumeral
  253100 }
\def\allowgroups{\expandafter\barfm\expandafter\egroup\romannumeral
  253100 }
\def\m#1{\message{#1}}

\forbidgroups
\m{aha}
\allowgroups
{ehe}
\forbidgroups
\m{oho}
{uhu}
\allowgroups
\end

This drops out at {uhu} with a typical TeX engine.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
0
dak (3569)
8/16/2008 10:37:28 PM
amazing!  thanks.

/ivo

On Aug 16, 6:37 pm, David Kastrup <d...@gnu.org> wrote:

> \def\barfm#1#2{#1\csname barf#2\endcsname#1}
> \def\barfc#1{}
> \def\forbidgroups{\expandafter\barfm\expandafter\bgroup\romannumeral
>   253100 }
> \def\allowgroups{\expandafter\barfm\expandafter\egroup\romannumeral
>   253100 }
> \def\m#1{\message{#1}}
>
> \forbidgroups
> \m{aha}
> \allowgroups
> {ehe}
> \forbidgroups
> \m{oho}
> {uhu}
> \allowgroups
> \end
>
> This drops out at {uhu} with a typical TeX engine.
>
> --
> David Kastrup, Kriemhildstr. 15, 44793 Bochum
> UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
0
ivowel (414)
8/17/2008 12:10:11 AM
On Aug 16, 8:10=A0pm, "ivo...@gmail.com" <ivo...@gmail.com> wrote:
> On Aug 16, 6:37 pm, David Kastrup <d...@gnu.org> wrote:
>
> > \def\barfm#1#2{#1\csname barf#2\endcsname#1}
> > \def\barfc#1{}
> > \def\forbidgroups{\expandafter\barfm\expandafter\bgroup\romannumeral
> > =A0 253100 }
> > \def\allowgroups{\expandafter\barfm\expandafter\egroup\romannumeral
> > =A0 253100 }
> > \def\m#1{\message{#1}}
>
> > \forbidgroups
> > \m{aha}
> > \allowgroups
> > {ehe}
> > \forbidgroups
> > \m{oho}
> > {uhu}
> > \allowgroups
> > \end
>
> > This drops out at {uhu} with a typical TeX engine.
>
> amazing!  thanks.

(I've rearranged the message to top-quoting so that the conversation
flow makes any sense at all - please top-quote).  I hope you
understand that this solution is not particularly serious, since (you
may quickly discover) it doesn't work so well in practice.  It's a
very clever trick, though... TeX typically only allows 255 levels of
grouping, so \forbidgroups basically expands to (what looks like) 253
\bgroup's (not sure where the other 2 come from), and then
\allowgroups closes them all...  So environments will also cause
errors, among other things.

But I am certainly impressed...

Cheers,
steve
0
stephenhicks (127)
8/17/2008 5:00:26 AM
Steve Hicks <stephenhicks@gmail.com> writes:

> On Aug 16, 8:10�pm, "ivo...@gmail.com" <ivo...@gmail.com> wrote:
>> On Aug 16, 6:37 pm, David Kastrup <d...@gnu.org> wrote:
>>
>> > \def\barfm#1#2{#1\csname barf#2\endcsname#1}
>> > \def\barfc#1{}
>> > \def\forbidgroups{\expandafter\barfm\expandafter\bgroup\romannumeral
>> > � 253100 }
>> > \def\allowgroups{\expandafter\barfm\expandafter\egroup\romannumeral
>> > � 253100 }
>> > \def\m#1{\message{#1}}
>>
>> > \forbidgroups
>> > \m{aha}
>> > \allowgroups
>> > {ehe}
>> > \forbidgroups
>> > \m{oho}
>> > {uhu}
>> > \allowgroups
>> > \end
>>
>> > This drops out at {uhu} with a typical TeX engine.
>>
>> amazing!  thanks.
>
> (I've rearranged the message to top-quoting so that the conversation
> flow makes any sense at all - please top-quote).  I hope you
> understand that this solution is not particularly serious, since (you
> may quickly discover) it doesn't work so well in practice.  It's a
> very clever trick, though... TeX typically only allows 255 levels of
> grouping, so \forbidgroups basically expands to (what looks like) 253
> \bgroup's (not sure where the other 2 come from), and then
> \allowgroups closes them all...  So environments will also cause
> errors, among other things.

One would have to change \begin and \end accordingly, and one would make
\forbidgroups insert a variable amount of \bgroup (depending on eTeX's
\currentgrouplevel) and have \allowgroups compensate accordingly.  And
of course, a lot of other groups inside of TeX commands would just bomb
out.  It is not feasible in practice.

Somewhat more feasible would be to record \currentgrouplevel, and insert
checkpointing code at strategic places that would make sure that no
surprising changes have occured.  Of course, then the error would occur
somewhat asynchronously.

So I don't think there is much of a possibility to do this usefully.
I've not checked LuaTeX's hooks in that respect: it may have some hook
for entering groups.  If it does, then one should be able to check
whether one is right now reading from the input file (rather than a
macro) and complain in that case.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
UKTUG FAQ: <URL:http://www.tex.ac.uk/cgi-bin/texfaq2html>
0
dak (3569)
8/17/2008 8:14:42 AM
Reply: