ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Hans Hagen <j.hagen@xs4all.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: lmtx
Date: Fri, 19 Jun 2020 12:11:03 +0200	[thread overview]
Message-ID: <7bdf3017-ba3f-999d-8832-43b2f8784003@xs4all.nl> (raw)

Hi,

Here's an update about what Wolfgang and I are doing in the lmtx code 
base i.e. where it differs from the mkiv code. Much has to do with 
cleaner code, less memory usage and less tracing clutter. To some extend 
it might be more efficient in terms of runtime, but in practice there is 
not much (measurable) to gain at the macro level wrt speed. Most 
bottlenecks are at the Lua end anyway.

(1) macro arguments:

In tex a macro argument is defined with numbers, so

   \def\foo#1#2{... #2 ... #2 ...}

in luametatex we can have some variants

   #0 : the argument is picked up but not stored
   #- : the argument is ignored and not even counted
   #+ : the argument is picked up but no outer braces are removed

There is some explanation in the evenmore document, like:

   \def\foo    [#1]{\detokenize{#1}}
   \def\ofo    [#0]{\detokenize{#1}}
   \def\oof    [#+]{\detokenize{#1}}
   \def\fof[#1#-#2]{\detokenize{#1#2}}
   \def\fff[#1#0#3]{\detokenize{#1#3}}

   \meaning\foo\ : <\foo[{123}]> \crlf
   \meaning\ofo\ : <\ofo[{123}]> \crlf
   \meaning\oof\ : <\oof[{123}]> \crlf
   \meaning\fof\ : <\fof[123]>   \crlf
   \meaning\fff\ : <\fof[123]>   \crlf

I mention this because you may encounter something other than #1 .. #9 
in error reports or tracing.

(2) interception of unmatched delimiters

If you define macros like

   \def\foo[#1=#2]{...}

the brackets and equal had better be there. However there is some 
trickery in the macro parsing that can be used to intercept cases where 
they are missing: optional tokens as well as forcing end of scanning (so 
if you see \ignorearguments and \ifarguments in the code, that is what 
we're talking about: premature quitting and checking why that happened 
and acting upon it: less hackery is needed but then of course also less 
possibility to 'show off how clever one is wrt writing obscure macros' 
... so be it.

Both (1) and (2) are relatively lightweight extensions that are downward 
compatible as well as have no impact on performance. We don't expect 
them to be used at the user level (where one seldom defines macros 
anyway) but we apply them in some low level macros (and might apply them 
more). One can measure better performance but only when applied millions 
of times which is seldom the case in context (we're often more talking 
thousands there than millions of expansions).

(3) There is some more 'matching token sequences' code that is being 
applied stepwise but again this is normally not seen at the user level. 
It sometimes permits cleaner fully expandable solutions.

(4) There are some additional if tests but these are already around for 
quite a while and probably went unnoticed anyway.

(5) Nested conditions can be flattened by using \orelse and that's what 
happens now in quite some places in the lmtx code (it's already there 
for a quite a while and kind of well tested). Again this leads to less 
tracing, can in priniciple be more efficient, but also demands less 
multiple expand after situations. It also just looks nicer.

(6) Upcoming code can use some more (simplified) grouping magic but that 
is something we need to test more (which is what we are doing now).

Just that you know when you get some error and see unfamiliar primitives,

Hans

-----------------------------------------------------------------
                                           Hans Hagen | PRAGMA ADE
               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

             reply	other threads:[~2020-06-19 10:11 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-19 10:11 Hans Hagen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-02-03 21:00 lmtx Hans Hagen via ntg-context
2021-02-19 12:32 lmtx Hans Hagen
2021-01-18 18:20 lmtx Hans Hagen
2021-01-19 10:57 ` lmtx Floris van Manen
2021-01-19 11:10   ` lmtx Hans Hagen
2021-01-19 11:31     ` lmtx Jano Kula
2021-01-19 19:12 ` lmtx Jan U. Hasecke
2021-01-19 23:03   ` lmtx Hans Hagen
2020-10-30 22:29 lmtx Hans Hagen
2020-10-31  2:50 ` lmtx Jairo A. del Rio
2020-11-02 19:43   ` lmtx Hans Hagen
     [not found] <mailman.1.1576234801.28358.ntg-context@ntg.nl>
2019-12-13 19:29 ` lmtx Jeong Dal
     [not found] <mailman.310.1576128525.1207.ntg-context@ntg.nl>
2019-12-12 23:48 ` lmtx Jeong Dal
2019-12-13  8:39   ` lmtx Otared Kavian
2019-12-12  0:37 lmtx Hans Hagen
2019-12-12  5:28 ` lmtx Otared Kavian
2019-12-12  6:04   ` lmtx Otared Kavian
2019-12-12 10:08   ` lmtx Hans Hagen
2019-12-12  6:36 ` lmtx Richard Mahoney | Indica et Buddhica
2019-12-12 16:59 ` lmtx Pablo Rodriguez
2019-12-12 20:13   ` lmtx Pablo Rodriguez
2019-08-05 12:38 lmtx Hans Hagen
2019-04-02  9:05 lmtx Hans Hagen
2019-04-02 19:03 ` lmtx Taco Hoekwater
2019-04-02 20:11 ` lmtx Henri Menke
2019-04-02 20:19   ` lmtx Hans Hagen
2019-04-02 20:30     ` lmtx Henri Menke
2019-04-02 20:47       ` lmtx Hans Hagen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7bdf3017-ba3f-999d-8832-43b2f8784003@xs4all.nl \
    --to=j.hagen@xs4all.nl \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).