LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Manuel Pégourié-Gonnard <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Date:
Fri, 14 Aug 2009 11:19:07 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (46 lines)
J.Fine a écrit :
> Thank you.  It's not the only nice thing we can do.  Here are some more:
> 
>   * Allow digits in control sequence names
>   * Allow period in control sequence names

I think the naming scheme (at the programming level at leat) has been discussed
previously and is now considered stable. Let's not re-discuss again and again
points were decisions are already made. (And btw, I personnaly think the namign
scheme in expl3 is good.)

>   * Allow '~' to produce a space /in all circumstances/
> 
What would be the purpose?

> The LaTeX3 project has put much effort into naming conventions for control
> sequences.  I think having the ability to name parameters will bring
> at least the same benefit.
> 
I think realism should also be a key word if we ever want to be a stable LaTeX3.
And I really would like to see it :-)

>> it doesn't seem that important to me how we refer to
>> arguments within a macro.
> 
I agree with your (Will) argument and conclusion on this point.

> Which is easier to type and to read?
>    \wibble.wobble_trip
>    \wibble_wobble_trip
> 
It depends on your personal habits. The second one is perfectly fine for me.
(After all, unlike most language, we have to type \ in the front of every
"function", so let's not try to mimick other languages too much.)

> We could even go further and implement something much more
> like a real module system for macro programming.   Something
> that would raise load- or compile-time import errors, rather than
> the current run-time error.
> 
Again, let's be realistic. There is already some error handling done. Moreover,
the distinction between load, compile and run time doesn't seem relevant for TeX.


Manuel.

ATOM RSS1 RSS2