MIME-Version: 1.0
References: <CACKZBPU39WashARzg94y3YLNM=H78kNaD7ojskwGCOAej-mSGQ@mail.gmail.com> <51ECE2AC.7020806@morningstar2.co.uk>
            <CACKZBPVV7hkeQYOP328fVYNOPpwc9zTiQF1hKJ1bUDzJMp+Mqw@mail.gmail.com> <51ED4B60.8040900@morningstar2.co.uk>
            <CACKZBPW5bM=Pw-Vk5FapiPxCXwNb9LMiG7Ri2chGWgKCGHfE5g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Message-ID:  <CANQYN6zjYJUun1V7=FeL2O-nGsYKriU0EyhoqFC7zF2vyK=g3w@mail.gmail.com>
Date:         Tue, 23 Jul 2013 18:27:36 -0400
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: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Re: Propagation of 'global'ness
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CACKZBPW5bM=Pw-Vk5FapiPxCXwNb9LMiG7Ri2chGWgKCGHfE5g@mail.gmail.com>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

We are moving away from the original question, which was how to keep
track of the scope.  I would argue that functionality equivalent to
the proposed \prop_sput:NNnn exists, as \use:c { prop_#1put:Nnn } with
#1 being either { } or { g }.  For instance, applying this approach
(which is IIRC used in l3keys) to the prop example you gave, we would
obtain

\cs_new_protected_nopar:Npn \prop_put:Nnn  { \@@_put:nNnn { } }
\cs_new_protected_nopar:Npn \prop_gput:Nnn { \@@_put:nNnn { g } }
\cs_new_protected:Npn \@@_put:NNnn #1#2#3#4
  {
    \tl_set:Nn \l_@@_internal_tl
      { \s_@@ \tl_to_str:n {#3} \s_@@ { \exp_not:n {#4} } }
    \@@_split:NnTF #2 {#3}
      { \use:c { tl_ #1 set:Nx } #2 { \exp_not:n {##1}
\l_@@_internal_tl \exp_not:n {##3} } }
      { \use:c { tl_ #1 put_right:Nx } #2 { \l_@@_internal_tl } }
  }

In low-level code such as this one, I prefer the current approach
because it is faster.  In higher-level code such as third-party
packages, the \use:c approach seems fine to me.  The drawback of
\use:c will appear if we ever want to attempt some static analysis of
the code (if only to know which function requires which, or how to
properly indent code), as it is very hard to find out that \tl_set:Nx
is called in the above.  But I think that it is not such a huge
drawback, as it is already unlikely that we can extract much
meaningful information from TeX code anyways.  I see the other
approach (adding 'sput' functions) as having a larger drawback, as it
requires adding hundreds of functions (including the inevitable
variants).

>> I've no real experience of other languages, though, so perhaps I miss
>> something. What does one do in say C if the data structures available
>> are not suitable? (I didn't think you could even add keywords in most
>> languages, so adding data types seems tricky.)
>
> C is quite old, but even C allows the creation of new datastructures
> and control-flow constructs. New keywords can be added with
> preprocessor directives (which are very close to TeX command
> sequences, actually; both are often referred to as macros).
>
> What C lacks is encapsulation. Like LaTeX, it has to rely on goodwill
> and convention to prevent conflicts. C++ fixed this (somewhat).

I think C's structs can be completely emulated using a prop in expl3:
of course, that leads to an overhead as the names of the struct
entries are stored with the data.  Some object ideas I am working on
at the moment would alleviate that, storing the entry names once for
all structs of the same type.

C pointers cannot easily be emulated, as one needs the ability to
create unique names (cf. another recent discussion where we concluded
that providing a function for that purpose was best).  Am I missing
some goodies that C provides?

While we are talking of datastructure, hence are not very far from
objects, let me ask a question: do we want function polymorphism?  In
other words, do we want the ability for a function to switch behavior
depending on the type of its argument, e.g., letting us provide
\obj_to_str:N <any object>?  Some somewhat-object-oriented languages
do not allow this, for instance OCaml will balk at "1.2 + 3.4", and
will require "+." instead of "+" for floating points.

>> [BTW, I'd hope expl3 is used for 'typesetting', broadly :-) Bruno may
>> want to pilot the Mars rover in TeX, but ...]
>
> TeX is Turing Complete. If you won't exploit it, someone else will.
>
> Enhanced programming tools help us to build packages that ultimately
> make life easier for authors. Below that level, treating TeX like a
> general purpose language makes a lot of sense. Isn't that why you guys
> are creating expl3 in the first place, and why dialects like LuaTeX
> exist?

Yes, TeX is Turing Complete, and we do make use of it.  One question
is to know if we want to go much beyond what C provides (I think we
are not very far from covering that) in terms of general-purpose
programming tools.  Remember that beyond this we also need to worry
about tools to handle many other aspects ranging from setting options
on a document-wide, environment-wide, or otherwise local basis, taking
care of fonts, building paragraphs, maths formulas, tables, and pages
from all this, as well as placing figures, understanding the correct
approach for letting the user control their placement, etc.  There is
more than just programming.

--
Bruno