-
Notifications
You must be signed in to change notification settings - Fork 178
/
l3fp-parse.dtx
2933 lines (2933 loc) · 105 KB
/
l3fp-parse.dtx
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
% \iffalse meta-comment
%
%% File: l3fp-parse.dtx Copyright (C) 2011-2018 The LaTeX3 Project
%
% It may be distributed and/or modified under the conditions of the
% LaTeX Project Public License (LPPL), either version 1.3c of this
% license or (at your option) any later version. The latest version
% of this license is in the file
%
% https://www.latex-project.org/lppl.txt
%
% This file is part of the "l3kernel bundle" (The Work in LPPL)
% and all files in that bundle must be distributed together.
%
% -----------------------------------------------------------------------
%
% The development version of the bundle can be found at
%
% https://github.com/latex3/latex3
%
% for those people who are interested.
%
%<*driver>
\documentclass[full,kernel]{l3doc}
\begin{document}
\DocInput{\jobname.dtx}
\end{document}
%</driver>
% \fi
%
% \title{The \textsf{l3fp-parse} package\\
% Floating point expression parsing}
% \author{^^A
% The \LaTeX3 Project\thanks
% {^^A
% E-mail:
% \href{mailto:latex-team@latex-project.org}
% {latex-team@latex-project.org}^^A
% }^^A
% }
% \date{Released 2018/03/05}
%
% \maketitle
%
% \begin{documentation}
%
% \end{documentation}
%
% \begin{implementation}
%
% \section{\pkg{l3fp-parse} implementation}
%
% \begin{macrocode}
%<*initex|package>
% \end{macrocode}
%
% \begin{macrocode}
%<@@=fp>
% \end{macrocode}
%
% \subsection{Work plan}
%
% The task at hand is non-trivial, and some previous failed attempts
% show that the code leads to unreadable logs, so we had better get it
% (almost) right the first time. Let us first describe our goal, then
% discuss the design precisely before writing any code.
%
% In this file at least, a \meta{floating point object} is a floating
% point number or tuple. This can be extended to anything that starts
% with \cs{s_@@} or \cs{s_@@_\meta{type}} and ends with |;| with some
% internal structure that depends on the \meta{type}.
%
% \begin{macro}[EXP]{\@@_parse:n}
% \begin{syntax}
% \cs{@@_parse:n} \Arg{fpexpr}
% \end{syntax}
% Evaluates the \meta{floating point expression} and leaves the result
% in the input stream as a floating point object. This
% function forms the basis of almost all public \pkg{l3fp} functions.
% During evaluation, each token is fully \texttt{f}-expanded.
%
% \cs{@@_parse_o:n} does the same but expands once after its result.
% \begin{texnote}
% Registers (integers, toks, etc.) are automatically unpacked,
% without requiring a function such as \cs{int_use:N}. Invalid
% tokens remaining after \texttt{f}-expansion lead to
% unrecoverable low-level \TeX{} errors.
% \end{texnote}
% \end{macro}
%
% \begin{variable}
% {
% \c_@@_prec_func_int,
% \c_@@_prec_hatii_int,
% \c_@@_prec_hat_int,
% \c_@@_prec_not_int,
% \c_@@_prec_times_int,
% \c_@@_prec_plus_int,
% \c_@@_prec_comp_int,
% \c_@@_prec_and_int,
% \c_@@_prec_or_int,
% \c_@@_prec_quest_int,
% \c_@@_prec_colon_int,
% \c_@@_prec_comma_int,
% \c_@@_prec_tuple_int,
% \c_@@_prec_end_int,
% }
% Floating point expressions are composed of numbers, given in various
% forms, infix operators, such as |+|, |**|, or~|,| (which joins two
% numbers into a list), and prefix operators, such as the unary~|-|,
% functions, or opening parentheses. Here is a list of precedences
% which control the order of evaluation (some distinctions are
% irrelevant for the order of evaluation, but serve as signals), from
% the tightest binding to the loosest binding.
% \begin{itemize}
% \item[16] Function calls.
% \item[13/14] Binary |**| and~|^| (right to left).
% \item[12] Unary |+|, |-|, |!| (right to left).
% \item[10] Binary |*|, |/|, and juxtaposition (implicit~|*|).
% \item[9] Binary |+| and~|-|.
% \item[7] Comparisons.
% \item[6] Logical \texttt{and}, denoted by~|&&|.
% \item[5] Logical \texttt{or}, denoted by~\verb*+||+.
% \item[4] Ternary operator |?:|, piece~|?|.
% \item[3] Ternary operator |?:|, piece~|:|.
% \item[2] Commas.
% \item[1] Place where a comma is allowed and generates a tuple.
% \item[0] Start and end of the expression.
% \end{itemize}
% \begin{macrocode}
\int_const:Nn \c_@@_prec_func_int { 16 }
\int_const:Nn \c_@@_prec_hatii_int { 14 }
\int_const:Nn \c_@@_prec_hat_int { 13 }
\int_const:Nn \c_@@_prec_not_int { 12 }
\int_const:Nn \c_@@_prec_times_int { 10 }
\int_const:Nn \c_@@_prec_plus_int { 9 }
\int_const:Nn \c_@@_prec_comp_int { 7 }
\int_const:Nn \c_@@_prec_and_int { 6 }
\int_const:Nn \c_@@_prec_or_int { 5 }
\int_const:Nn \c_@@_prec_quest_int { 4 }
\int_const:Nn \c_@@_prec_colon_int { 3 }
\int_const:Nn \c_@@_prec_comma_int { 2 }
\int_const:Nn \c_@@_prec_tuple_int { 1 }
\int_const:Nn \c_@@_prec_end_int { 0 }
% \end{macrocode}
% \end{variable}
%
% \subsubsection{Storing results}
%
% The main question in parsing expressions expandably is to decide where
% to put the intermediate results computed for various subexpressions.
%
% One option is to store the values at the start of the expression, and
% carry them together as the first argument of each macro. However, we
% want to \texttt{f}-expand tokens one by one in the expression (as
% \cs{int_eval:n} does), and with this approach, expanding the next
% unread token forces us to jump with \cs{exp_after:wN} over every value
% computed earlier in the expression. With this approach, the run-time
% grows at least quadratically in the length of the expression, if
% not as its cube (inserting the \cs{exp_after:wN} is tricky and slow).
%
% A second option is to place those values at the end of the expression.
% Then expanding the next unread token is straightforward, but this
% still hits a performance issue: for long expressions we would be
% reaching all the way to the end of the expression at every step of the
% calculation. The run-time is again quadratic.
%
% A variation of the above attempts to place the intermediate results
% which appear when computing a parenthesized expression near the
% closing parenthesis. This still lets us expand tokens as we go, and
% avoids performance problems as long as there are enough parentheses.
% However, it would be better to avoid requiring the closing
% parenthesis to be present as soon as the corresponding opening
% parenthesis is read: the closing parenthesis may still be hidden in a
% macro yet to be expanded.
%
% Hence, we need to go for some fine expansion control: the result is
% stored \emph{before} the start!
%
% Let us illustrate this idea in a simple model: adding positive
% integers which may be resulting from the expansion of macros, or may
% be values of registers. Assume that one number, say, $12345$, has
% already been found, and that we want to parse the next number. The
% current status of the code may look as follows.
% \begin{syntax}
% \cs{exp_after:wN} |\add:ww| \cs{int_value:w} 12345 \cs{exp_after:wN} ;
% \cs{exp:w} |\operand:w| \meta{stuff}
% \end{syntax}
% One step of expansion expands \cs{exp_after:wN}, which triggers the
% primitive \cs{int_value:w}, which reads the five digits we have
% already found, |12345|. This integer is unfinished, causing the
% second \cs{exp_after:wN} to expand, and to trigger the construction
% \cs{exp:w}, which expands |\operand:w|, defined to read
% what follows and make a number out of it, then leave \cs{exp_end:}, the
% number, and a semicolon in the input stream. Once |\operand:w| is
% done expanding, we obtain essentially
% \begin{syntax}
% \cs{exp_after:wN} |\add:ww| \cs{int_value:w} 12345 ;
% \cs{exp:w} \cs{exp_end:} 333444 ;
% \end{syntax}
% where in fact \cs{exp_after:wN} has already been expanded,
% \cs{int_value:w} has already seen |12345|, and
% \cs{exp:w} is still looking for a number. It finds
% \cs{exp_end:}, hence expands to nothing. Now, \cs{int_value:w} sees
% the \texttt{;}, which cannot be part of a number. The expansion
% stops, and we are left with
% \begin{syntax}
% |\add:ww| 12345 ; 333444 ;
% \end{syntax}
% which can safely perform the addition by grabbing two arguments
% delimited by~|;|.
%
% If we were to continue parsing the expression, then the following
% number should also be cleaned up before the next use of a binary
% operation such as |\add:ww|. Just like \cs{int_value:w} |12345|
% \cs{exp_after:wN}~|;| expanded what follows once, we need |\add:ww|
% to do the calculation, and in the process to expand the following
% once. This is also true in our real application: all the functions of
% the form \cs[no-index]{@@_\ldots_o:ww} expand what follows once. This comes at the
% cost of leaving tokens in the input stack, and we need to be
% careful not to waste this memory. All of our discussion above is nice
% but simplistic, as operations should not simply be performed in the
% order they appear.
%
% \subsubsection{Precedence and infix operators}
%
% The various operators we will encounter have different precedences,
% which influence the order of calculations: $1+2\times 3 = 1+(2\times
% 3)$ because $\times$~has a higher precedence than~$+$. The true
% analog of our macro |\operand:w| must thus take care of that. When
% looking for an operand, it needs to perform calculations until
% reaching an operator which has lower precedence than the one which
% called |\operand:w|. This means that |\operand:w| must know what the
% previous binary operator is, or rather, its precedence: we thus rename
% it |\operand:Nw|. Let us describe as an example how we plan to do
% the calculation |41-2^3*4+5|. More precisely we describe how to
% perform the first operation in this expression. Here, we abuse
% notations: the first argument of |\operand:Nw| should be an integer
% constant (\cs{c_@@_prec_plus_int}, \ldots{}) equal to the precedence
% of the given operator, not directly the operator itself.
% \begin{itemize}
% \item Clean up~|41| and find~|-|. We call |\operand:Nw|~|-| to find
% the second operand.
% \item Clean up~|2| and find~|^|.
% \item Compare the precedences of |-| and~|^|. Since the latter is
% higher, we need to compute the exponentiation. For this, find the
% second operand with a nested call to |\operand:Nw|~|^|.
% \item Clean up~|3| and find~|*|.
% \item Compare the precedences of |^| and~|*|. Since the former is
% higher, |\operand:Nw|~|^| has found the second operand of the
% exponentiation, which is computed: $2^{3} = 8$.
% \item We now have |41-8*4+5|, and |\operand:Nw|~|-| is still
% looking for a second operand for the subtraction. Is it~$8$?
% \item Compare the precedences of |-| and~|*|. Since the latter is
% higher, we are not done with~$8$. Call |\operand:Nw|~|*| to find
% the second operand of the multiplication.
% \item Clean up~|4|, and find~|+|.
% \item Compare the precedences of |*| and~|+|. Since the former is
% higher, |\operand:Nw|~|*| has found the second operand of the
% multiplication, which is computed: $8*4 = 32$.
% \item We now have |41-32+5|, and |\operand:Nw|~|-| is still looking
% for a second operand for the subtraction. Is it~$32$?
% \item Compare the precedences of |-| and~|+|. Since they are equal,
% |\operand:Nw|~|-| has found the second operand for the
% subtraction, which is computed: $41-32=9$.
% \item We now have |9+5|.
% \end{itemize}
% The procedure above stops short of performing all computations, but
% adding a surrounding call to |\operand:Nw| with a very low precedence
% ensures that all computations are performed before |\operand:Nw|
% is done. Adding a trailing marker with the same very low precedence
% prevents the surrounding |\operand:Nw| from going beyond the marker.
%
% The pattern above to find an operand for a given operator, is to find
% one number and the next operator, then compare precedences to know if
% the next computation should be done. If it should, then perform it
% after finding its second operand, and look at the next operator, then
% compare precedences to know if the next computation should be done.
% This continues until we find that the next computation should not be
% done. Then, we stop.
%
% We are now ready to get a bit more technical and describe which of the
% \pkg{l3fp-parse} functions correspond to each step above.
%
% First, \cs{@@_parse_operand:Nw} is the |\operand:Nw| function above,
% with small modifications due to expansion issues discussed later. We
% denote by \meta{precedence} the argument of \cs{@@_parse_operand:Nw},
% that is, the precedence of the binary operator whose operand we are
% trying to find. The basic action is to read numbers from the input
% stream. This is done by \cs{@@_parse_one:Nw}. A first approximation
% of this function is that it reads one \meta{number}, performing no
% computation, and finds the following binary \meta{operator}. Then it
% expands to
% \begin{quote}
% \meta{number}\\
% | \__fp_parse_infix_|\meta{operator}|:N| \meta{precedence}
% \end{quote}
% expanding the \texttt{infix} auxiliary before leaving the above in the
% input stream.
%
% We now explain the \texttt{infix} auxiliaries. We need some
% flexibility in how we treat the case of equal precedences: most often,
% the first operation encountered should be performed, such as |1-2-3|
% being computed as |(1-2)-3|, but |2^3^4| should be evaluated as
% |2^(3^4)| instead. For this reason, and to support the equivalence
% between |**| and~|^| more easily, each binary operator is converted to
% a control sequence |\__fp_parse_infix_|\meta{operator}|:N| when it is
% encountered for the first time. Instead of passing both precedences
% to a test function to do the comparison steps above, we pass the
% \meta{precedence} (of the earlier operator) to the \texttt{infix}
% auxiliary for the following \meta{operator}, to know whether to
% perform the computation of the \meta{operator}. If it should not be
% performed, the \texttt{infix} auxiliary expands to
% \begin{syntax}
% |@| \cs{use_none:n} |\__fp_parse_infix_|\meta{operator}|:N|
% \end{syntax}
% and otherwise it calls \cs{@@_parse_operand:Nw} with the precedence of
% the \meta{operator} to find its second operand \meta{number_2} and the
% next \meta{operator_2}, and expands to
% \begin{syntax}
% |@| \cs{@@_parse_apply_binary:NwNwN}
% ~~~~\meta{operator} \meta{number_2}
% |@| |\__fp_parse_infix_|\meta{operator_2}|:N|
% \end{syntax}
% The \texttt{infix} function is responsible for comparing precedences,
% but cannot directly call the computation functions, because the first
% operand \meta{number} is before the \texttt{infix} function in the
% input stream. This is why we stop the expansion here and give control
% to another function to close the loop.
%
% A definition of \cs{@@_parse_operand:Nw} \meta{precedence} with some
% of the expansion control removed is
% \begin{syntax}
% \cs{exp_after:wN} \cs{@@_parse_continue:NwN}
% \cs{exp_after:wN} \meta{precedence}
% \cs{exp:w} \cs{exp_end_continue_f:w}
% ~~\cs{@@_parse_one:Nw} \meta{precedence}
% \end{syntax}
% This expands \cs{@@_parse_one:Nw} \meta{precedence} completely, which
% finds a number, wraps the next \meta{operator} into an \texttt{infix}
% function, feeds this function the \meta{precedence}, and expands it,
% yielding either
% \begin{syntax}
% \cs{@@_parse_continue:NwN} \meta{precedence}
% \meta{number} |@|
% \cs{use_none:n} |\__fp_parse_infix_|\meta{operator}|:N|
% \end{syntax}
% or
% \begin{syntax}
% \cs{@@_parse_continue:NwN} \meta{precedence}
% \meta{number} |@|
% \cs{@@_parse_apply_binary:NwNwN}
% ~~\meta{operator} \meta{number_2}
% |@| |\__fp_parse_infix_|\meta{operator_2}|:N|
% \end{syntax}
% The definition of \cs{@@_parse_continue:NwN} is then very simple:
% \begin{syntax}
% |\cs_new:Npn \__fp_parse_continue:NwN #1#2@#3 { #3 #1 #2 @ }|
% \end{syntax}
% In the first case, |#3|~is \cs{use_none:n}, yielding
% \begin{syntax}
% \cs{use_none:n} \meta{precedence} \meta{number} |@|
% |\__fp_parse_infix_|\meta{operator}|:N|
% \end{syntax}
% then \meta{number} |@| |\__fp_parse_infix_|\meta{operator}|:N|. In
% the second case, |#3|~is \cs{@@_parse_apply_binary:NwNwN}, whose role
% is to compute \meta{number} \meta{operator} \meta{number_2} and to
% prepare for the next comparison of precedences: first we get
% \begin{syntax}
% \cs{@@_parse_apply_binary:NwNwN}
% ~~\meta{precedence} \meta{number} |@|
% ~~\meta{operator} \meta{number_2}
% |@| |\__fp_parse_infix_|\meta{operator_2}|:N|
% \end{syntax}
% then
% \begin{syntax}
% \cs{exp_after:wN} \cs{@@_parse_continue:NwN}
% \cs{exp_after:wN} \meta{precedence}
% \cs{exp:w} \cs{exp_end_continue_f:w}
% |\__fp_|\meta{operator}|_o:ww| \meta{number} \meta{number_2}
% \cs{exp:w} \cs{exp_end_continue_f:w}
% |\__fp_parse_infix_|\meta{operator_2}|:N| \meta{precedence}
% \end{syntax}
% where |\__fp_|\meta{operator}|_o:ww| computes \meta{number}
% \meta{operator} \meta{number_2} and expands after the result, thus
% triggers the comparison of the precedence of the \meta{operator_2} and
% the \meta{precedence}, continuing the loop.
%
% We have introduced the most important functions here, and the next few
% paragraphs we describe various subtleties.
%
% \subsubsection{Prefix operators, parentheses, and functions}
%
% Prefix operators (unary |-|, |+|,~|!|) and parentheses are taken care
% of by the same mechanism, and functions (\texttt{sin}, \texttt{exp},
% etc.) as well. Finding the argument of the unary~|-|, for instance,
% is very similar to grabbing the second operand of a binary infix
% operator, with a subtle precedence explained below. Once that operand
% is found, the operator can be applied to it (for the unary~|-|, this
% simply flips the sign). A left parenthesis is just a prefix operator
% with a very low precedence equal to that of the closing parenthesis
% (which is treated as an infix operator, since it normally appears just
% after numbers), so that all computations are performed until the
% closing parenthesis. The prefix operator associated to the left
% parenthesis does not alter its argument, but it removes the closing
% parenthesis (with some checks).
%
% Prefix operators are the reason why we only summarily described the
% function \cs{@@_parse_one:Nw} earlier. This function is responsible
% for reading in the input stream the first possible \meta{number} and
% the next infix \meta{operator}. If what follows \cs{@@_parse_one:Nw}
% \meta{precedence} is a prefix operator, then we must find the operand
% of this prefix operator through a nested call to
% \cs{@@_parse_operand:Nw} with the appropriate precedence, then apply
% the operator to the operand found to yield the result of
% \cs{@@_parse_one:Nw}. So far, all is simple.
%
% The unary operators |+|, |-|,~|!| complicate things a little bit:
% |-3**2| should be $-(3^2)=-9$, and not $(-3)^2=9$. This would easily
% be done by giving~|-| a lower precedence, equal to that of the infix
% |+| and~|-|. Unfortunately, this fails in cases such as |3**-2*4|,
% yielding $3^{-2\times 4}$ instead of the correct $3^{-2}\times 4$. A
% second attempt would be to call \cs{@@_parse_operand:Nw} with the
% \meta{precedence} of the previous operator, but |0>-2+3| is then
% parsed as |0>-(2+3)|: the addition is performed because it binds more
% tightly than the comparision which precedes~|-|. The correct approach
% is for a unary~|-| to perform operations whose precedence is greater
% than both that of the previous operation, and that of the unary~|-|
% itself. The unary~|-| is given a precedence higher than
% multiplication and division. This does not lead to any surprising
% result, since $-(x/y) = (-x)/y$ and similarly for multiplication, and
% it reduces the number of nested calls to \cs{@@_parse_operand:Nw}.
%
% Functions are implemented as prefix operators with very high
% precedence, so that their argument is the first number that can
% possibly be built.
%
% Note that contrarily to the \texttt{infix} functions discussed
% earlier, the \texttt{prefix} functions do perform tests on the
% previous \meta{precedence} to decide whether to find an argument or
% not, since we know that we need a number, and must never stop there.
%
% \subsubsection{Numbers and reading tokens one by one}
%
% So far, we have glossed over one important point: what is a
% \enquote{number}? A number is typically given in the form
% \meta{significand}|e|\meta{exponent}, where the \meta{significand} is
% any non-empty string composed of decimal digits and at most one
% decimal separator (a period), the exponent
% \enquote{\texttt{e}\meta{exponent}} is optional and is composed of an
% exponent mark~|e| followed by a possibly empty string of signs
% |+| or~|-| and a non-empty string of decimal digits. The
% \meta{significand} can also be an integer, dimension, skip, or muskip
% variable, in which case dimensions are converted from points (or mu
% units) to floating points, and the \meta{exponent} can also be an
% integer variable. Numbers can also be given as floating point
% variables, or as named constants such as |nan|, |inf| or~|pi|. We may
% add more types in the future.
%
% When \cs{@@_parse_one:Nw} is looking for a \enquote{number}, here is
% what happens.
% \begin{itemize}
% \item If the next token is a control sequence with the meaning of
% \cs{scan_stop:}, it can be: \cs{s_@@}, in which case our job is
% done, as what follows is an internal floating point number, or
% \cs{s_@@_mark}, in which case the expression has come to an early
% end, as we are still looking for a number here, or something else,
% in which case we consider the control sequence to be a bad
% variable resulting from \texttt{c}-expansion.
% \item If the next token is a control sequence with a different
% meaning, we assume that it is a register, unpack it with
% \cs{tex_the:D}, and use its value (in \texttt{pt} for dimensions
% and skips, \texttt{mu} for muskips) as the \meta{significand} of a
% number: we look for an exponent.
% \item If the next token is a digit, we remove any leading zeros,
% then read a significand larger than~$1$ if the next character is a
% digit, read a significand smaller than~$1$ if the next character
% is a period, or we have found a significand equal to~$0$
% otherwise, and look for an exponent.
% \item If the next token is a letter, we collect more letters until
% the first non-letter: the resulting word may denote a function
% such as |asin|, a constant such as |pi| or be unknown. In the
% first case, we call \cs{@@_parse_operand:Nw} to find the argument
% of the function, then apply the function, before declaring that we
% are done. Otherwise, we are done, either with the value of the
% constant, or with the value |nan| for unknown words.
% \item If the next token is anything else, we check whether it is a
% known prefix operator, in which case \cs{@@_parse_operand:Nw}
% finds its operand. If it is not known, then either a number is
% missing (if the token is a known infix operator) or the token is
% simply invalid in floating point expressions.
% \end{itemize}
% Once a number is found, \cs{@@_parse_one:Nw} also finds an infix
% operator. This goes as follows.
% \begin{itemize}
% \item If the next token is a control sequence, it could be the
% special marker \cs{s_@@_mark}, and
% otherwise it is a case of juxtaposing numbers, such as
% |2\c_zero|, with an implied multiplication.
% \item If the next token is a letter, it is also a case of
% juxtaposition, as letters cannot be proper infix operators.
% \item Otherwise (including in the case of digits), if the token is a
% known infix operator, the appropriate
% |\__fp_infix_|\meta{operator}|:N| function is built, and if it
% does not exist, we complain. In particular, the juxtaposition
% |\c_zero 2| is disallowed.
% \end{itemize}
%
% In the above, we need to test whether a character token~|#1| is a
% digit:
% \begin{verbatim}
% \if_int_compare:w 9 < 1 \token_to_str:N #1 \exp_stop_f:
% is a digit
% \else:
% not a digit
% \fi:
% \end{verbatim}
% To exclude |0|, replace |9| by |10|. The use of
% \cs{token_to_str:N} ensures that a digit with any catcode is detected.
% To test if a character token is a letter, we need to work with its
% character code, testing if |`#1| lies in $[65,90]$ (uppercase letters)
% or $[97,112]$ (lowercase letters)
% \begin{verbatim}
% \if_int_compare:w \__fp_int_eval:w
% ( `#1 \if_int_compare:w `#1 > `Z - 32 \fi: ) / 26 = 3 \exp_stop_f:
% is a letter
% \else:
% not a letter
% \fi:
% \end{verbatim}
% At all steps, we try to accept all category codes: when |#1|~is kept
% to be used later, it is almost always converted to category code other
% through \cs{token_to_str:N}. More precisely, catcodes $\{3, 6, 7, 8,
% 11, 12\}$ should work without trouble, but not $\{1, 2, 4, 10, 13\}$,
% and of course $\{0, 5, 9\}$ cannot become tokens.
%
% Floating point expressions should behave as much as possible like
% \eTeX{}-based integer expressions and dimension expressions. In
% particular, \texttt{f}-expansion should be performed as the expression
% is read, token by token, forcing the expansion of protected macros,
% and ignoring spaces. One advantage of expanding at every step is that
% restricted expandable functions can then be used in floating point
% expressions just as they can be in other kinds of expressions.
% Problematically, spaces stop \texttt{f}-expansion: for instance, the
% macro~|\X| below would not be expanded if we simply performed
% \texttt{f}-expansion.
% \begin{verbatim}
% \DeclareDocumentCommand {\test} {m} { \fp_eval:n {#1} }
% \ExplSyntaxOff
% \test { 1 + \X }
% \end{verbatim}
% Of course, spaces typically do not appear in a code setting, but may very
% easily come in document-level input, from which some expressions may
% come. To avoid this problem, at every step, we do essentially what
% \cs{use:f} would do: take an argument, put it back in the input
% stream, then \texttt{f}-expand it. This is not a complete solution,
% since a macro's expansion could contain leading spaces which would stop
% the \texttt{f}-expansion before further macro calls are performed.
% However, in practice it should be enough: in particular, floating
% point numbers are correctly expanded to the underlying \cs{s_@@}
% \ldots{} structure. The \texttt{f}-expansion is performed by
% \cs{@@_parse_expand:w}.
%
% ^^A begin[todo]
%
% \subsection{Main auxiliary functions}
%
% \begin{macro}[rEXP]{\@@_parse_operand:Nw}
% \begin{syntax}
% \cs{exp:w} \cs{@@_parse_operand:Nw} \meta{precedence} \cs{@@_parse_expand:w}
% \end{syntax}
% Reads the \enquote{\ttfamily\ldots{}}, performing every computation
% with a precedence higher than \meta{precedence}, then expands to
% \begin{syntax}
% \meta{result} |@| |\__fp_parse_infix_|\meta{operation}|:N| \ldots{}
% \end{syntax}
% where the \meta{operation} is the first operation with a lower
% precedence, possibly \texttt{end}, and the
% \enquote{\ttfamily\ldots{}} start just after the \meta{operation}.
% \end{macro}
%
% \begin{macro}[EXP]{\@@_parse_infix_+:N}
% \begin{syntax}
% \cs{@@_parse_infix_+:N} \meta{precedence} \ldots{}
% \end{syntax}
% If |+|~has a precedence higher than the \meta{precedence}, cleans up
% a second \meta{operand} and finds the \meta{operation_2} which
% follows, and expands to
% \begin{syntax}
% |@| \cs{@@_parse_apply_binary:NwNwN} |+| \meta{operand} |@| \cs{@@_parse_infix_\meta{operation_2}:N} \ldots{}
% \end{syntax}
% Otherwise expands to
% \begin{syntax}
% |@| \cs{use_none:n} \cs{@@_parse_infix_+:N} \ldots{}
% \end{syntax}
% A similar function exists for each infix operator.
% \end{macro}
%
% \begin{macro}[EXP]{\@@_parse_one:Nw}
% \begin{syntax}
% \cs{@@_parse_one:Nw} \meta{precedence} \ldots{}
% \end{syntax}
% Cleans up one or two operands depending on how the precedence of the
% next operation compares to the \meta{precedence}. If the following
% \meta{operation} has a precedence higher than \meta{precedence},
% expands to
% \begin{syntax}
% \meta{operand_1} |@| \cs{@@_parse_apply_binary:NwNwN} \meta{operation} \meta{operand_2} |@| |\__fp_parse_infix_|\meta{operation_2}|:N| \ldots{}
% \end{syntax}
% and otherwise expands to
% \begin{syntax}
% \meta{operand} |@| \cs{use_none:n} |\__fp_parse_infix_|\meta{operation}|:N| \ldots{}
% \end{syntax}
% \end{macro}
%
% ^^A end[todo]
%
% \subsection{Helpers}
%
% \begin{macro}[rEXP]{\@@_parse_expand:w}
% \begin{syntax}
% \cs{exp:w} \cs{@@_parse_expand:w} \meta{tokens}
% \end{syntax}
% This function must always come within a \cs{exp:w} expansion.
% The \meta{tokens} should be the part of the expression that we have
% not yet read. This requires in particular closing all conditionals
% properly before expanding.
% \begin{macrocode}
\cs_new:Npn \@@_parse_expand:w #1 { \exp_end_continue_f:w #1 }
% \end{macrocode}
% \end{macro}
%
% \begin{macro}[EXP]{\@@_parse_return_semicolon:w}
% This very odd function swaps its position with the following
% \cs{fi:} and removes \cs{@@_parse_expand:w} normally responsible for
% expansion. That turns out to be useful.
% \begin{macrocode}
\cs_new:Npn \@@_parse_return_semicolon:w
#1 \fi: \@@_parse_expand:w { \fi: ; #1 }
% \end{macrocode}
% \end{macro}
%
% \begin{macro}[rEXP]
% {
% \@@_parse_digits_vii:N ,
% \@@_parse_digits_vi:N ,
% \@@_parse_digits_v:N ,
% \@@_parse_digits_iv:N ,
% \@@_parse_digits_iii:N ,
% \@@_parse_digits_ii:N ,
% \@@_parse_digits_i:N ,
% \@@_parse_digits_:N
% }
% These functions must be called within an \cs{int_value:w} or
% \cs{@@_int_eval:w} construction. The first token which follows must
% be \texttt{f}-expanded prior to calling those functions. The
% functions read tokens one by one, and output digits into the input
% stream, until meeting a non-digit, or up to a number of digits equal
% to their index. The full expansion is
% \begin{syntax}
% \meta{digits} |;| \meta{filling 0} |;| \meta{length}
% \end{syntax}
% where \meta{filling 0} is a string of zeros such that \meta{digits}
% \meta{filling 0} has the length given by the index of the function,
% and \meta{length} is the number of zeros in the \meta{filling 0}
% string. Each function puts a digit into the input stream and calls
% the next function, until we find a non-digit. We are careful to
% pass the tested tokens through \cs{token_to_str:N} to normalize
% their category code.
% \begin{macrocode}
\cs_set_protected:Npn \@@_tmp:w #1 #2 #3
{
\cs_new:cpn { @@_parse_digits_ #1 :N } ##1
{
\if_int_compare:w 9 < 1 \token_to_str:N ##1 \exp_stop_f:
\token_to_str:N ##1 \exp_after:wN #2 \exp:w
\else:
\@@_parse_return_semicolon:w #3 ##1
\fi:
\@@_parse_expand:w
}
}
\@@_tmp:w {vii} \@@_parse_digits_vi:N { 0000000 ; 7 }
\@@_tmp:w {vi} \@@_parse_digits_v:N { 000000 ; 6 }
\@@_tmp:w {v} \@@_parse_digits_iv:N { 00000 ; 5 }
\@@_tmp:w {iv} \@@_parse_digits_iii:N { 0000 ; 4 }
\@@_tmp:w {iii} \@@_parse_digits_ii:N { 000 ; 3 }
\@@_tmp:w {ii} \@@_parse_digits_i:N { 00 ; 2 }
\@@_tmp:w {i} \@@_parse_digits_:N { 0 ; 1 }
\cs_new:Npn \@@_parse_digits_:N { ; ; 0 }
% \end{macrocode}
% \end{macro}
%
% \subsection{Parsing one number}
%
% \begin{macro}[EXP]{\@@_parse_one:Nw}
% This function finds one number, and packs the symbol which follows
% in an \cs[no-index]{@@_parse_infix_\ldots{}} csname.
% |#1|~is the previous \meta{precedence},
% and |#2|~the first token of the operand. We distinguish four cases:
% |#2|~is equal to \cs{scan_stop:} in meaning, |#2|~is a different
% control sequence, |#2|~is a digit, and |#2|~is something else (this
% last case is split further later). Despite the earlier
% \texttt{f}-expansion, |#2|~may still be expandable if it was
% protected by \cs{exp_not:N}, as may happen with the \LaTeXe{} command
% \tn{protect}. Using a well placed \cs{reverse_if:N}, this case is
% sent to \cs{@@_parse_one_fp:NN} which deals with it robustly.
% \begin{macrocode}
\cs_new:Npn \@@_parse_one:Nw #1 #2
{
\if_catcode:w \scan_stop: \exp_not:N #2
\exp_after:wN \if_meaning:w \exp_not:N #2 #2 \else:
\exp_after:wN \reverse_if:N
\fi:
\if_meaning:w \scan_stop: #2
\exp_after:wN \exp_after:wN
\exp_after:wN \@@_parse_one_fp:NN
\else:
\exp_after:wN \exp_after:wN
\exp_after:wN \@@_parse_one_register:NN
\fi:
\else:
\if_int_compare:w 9 < 1 \token_to_str:N #2 \exp_stop_f:
\exp_after:wN \exp_after:wN
\exp_after:wN \@@_parse_one_digit:NN
\else:
\exp_after:wN \exp_after:wN
\exp_after:wN \@@_parse_one_other:NN
\fi:
\fi:
#1 #2
}
% \end{macrocode}
% \end{macro}
%
% \begin{macro}[EXP]
% {
% \@@_parse_one_fp:NN,
% \@@_exp_after_mark_f:nw,
% \@@_exp_after_?_f:nw
% }
% This function receives a \meta{precedence} and a control sequence
% equal to \cs{scan_stop:} in meaning. There are three cases.
% \begin{itemize}
% \item \cs{s_@@} starts a floating point number, and we call
% \cs{@@_exp_after_f:nw}, which |f|-expands after the floating
% point.
% \item \cs{s_@@_mark} is a premature end, we call
% \cs{@@_exp_after_mark_f:nw}, which triggers an |fp-early-end|
% error.
% \item For a control sequence not containing \cs[no-index]{s_@@}, we call
% \cs{@@_exp_after_?_f:nw}, causing a |bad-variable| error.
% \end{itemize}
% This scheme is extensible: additional types can be added by starting
% the variables with a scan mark of the form \cs[no-index]{s_@@_\meta{type}} and
% defining |\__fp_exp_after_|\meta{type}|_f:nw|. In all cases, we
% make sure that the second argument of \cs{@@_parse_infix:NN} is
% correctly expanded.
% A special case only enabled in \LaTeXe{} is that if \tn{protect} is
% encountered then the error message mentions the control sequence
% which follows it rather than \tn{protect} itself. The test for
% \LaTeXe{} uses \tn{@unexpandable@protect} rather than \tn{protect}
% because \tn{protect} is often \cs{scan_stop:} hence \enquote{does
% not exist}.
% \begin{macrocode}
\cs_new:Npn \@@_parse_one_fp:NN #1
{
\@@_exp_after_any_f:nw
{
\exp_after:wN \@@_parse_infix:NN
\exp_after:wN #1 \exp:w \@@_parse_expand:w
}
}
\cs_new:Npn \@@_exp_after_mark_f:nw #1
{
\int_case:nnF { \exp_after:wN \use_i:nnn \use_none:nnn #1 }
{
\c_@@_prec_comma_int { }
\c_@@_prec_tuple_int { }
\c_@@_prec_end_int
{
\exp_after:wN \c_@@_empty_tuple_fp
\exp:w \exp_end_continue_f:w
}
}
{
\__kernel_msg_expandable_error:nn { kernel } { fp-early-end }
\exp_after:wN \c_nan_fp \exp:w \exp_end_continue_f:w
}
#1
}
\cs_new:cpn { @@_exp_after_?_f:nw } #1#2
{
\__kernel_msg_expandable_error:nnn { kernel } { bad-variable } {#2}
\exp_after:wN \c_nan_fp \exp:w \exp_end_continue_f:w #1
}
%<*package>
\cs_set_protected:Npn \@@_tmp:w #1
{
\cs_if_exist:NT #1
{
\cs_gset:cpn { @@_exp_after_?_f:nw } ##1##2
{
\exp_after:wN \c_nan_fp \exp:w \exp_end_continue_f:w ##1
\str_if_eq:nnTF {##2} { \protect }
{
\cs_if_eq:NNTF ##2 #1 { \use_i:nn } { \use:n }
{ \__kernel_msg_expandable_error:nnn { kernel } { fp-robust-cmd } }
}
{ \__kernel_msg_expandable_error:nnn { kernel } { bad-variable } {##2} }
}
}
}
\exp_args:Nc \@@_tmp:w { @unexpandable@protect }
%</package>
% \end{macrocode}
% \end{macro}
%
% \begin{macro}[EXP]
% {
% \@@_parse_one_register:NN,
% \@@_parse_one_register_aux:Nw,
% \@@_parse_one_register_auxii:wwwNw,
% \@@_parse_one_register_int:www,
% \@@_parse_one_register_mu:www,
% \@@_parse_one_register_dim:ww,
% \@@_parse_one_register_wd:w,
% \@@_parse_one_register_wd:Nw,
% }
% This is called whenever~|#2| is a control sequence other than
% \cs{scan_stop:} in meaning. We special-case \tn{wd}, \tn{ht}, \tn{dp}
% (see later) and otherwise assume that it is a register, but
% carefully unpack it with \cs{tex_the:D} within braces. First, we
% find the exponent following~|#2|. Then we unpack~|#2| with
% \cs{tex_the:D}, and the \texttt{auxii} auxiliary distinguishes
% integer registers from dimensions/skips from muskips, according to
% the presence of a period and/or of |pt|. For integers, simply
% convert \meta{value}|e|\meta{exponent} to a floating point number
% with \cs{@@_parse:n} (this is somewhat wasteful). For other
% registers, the decimal rounding provided by \TeX{} does not
% accurately represent the binary value that it manipulates, so we
% extract this binary value as a number of scaled points with
% \cs{int_value:w} \cs{__dim_eval:w} \meta{decimal value} |pt|, and
% use an auxiliary of \cs{dim_to_fp:n}, which performs the
% multiplication by $2^{-16}$, correctly rounded.
% \begin{macrocode}
\cs_new:Npn \@@_parse_one_register:NN #1#2
{
\exp_after:wN \@@_parse_infix_after_operand:NwN
\exp_after:wN #1
\exp:w \exp_end_continue_f:w
\if_meaning:w \box_wd:N #2 \@@_parse_one_register_wd:w \fi:
\if_meaning:w \box_ht:N #2 \@@_parse_one_register_wd:w \fi:
\if_meaning:w \box_dp:N #2 \@@_parse_one_register_wd:w \fi:
\exp_after:wN \@@_parse_one_register_aux:Nw
\exp_after:wN #2
\int_value:w
\exp_after:wN \@@_parse_exponent:N
\exp:w \@@_parse_expand:w
}
\cs_new:Npx \@@_parse_one_register_aux:Nw #1
{
\exp_not:n
{
\exp_after:wN \use:nn
\exp_after:wN \@@_parse_one_register_auxii:wwwNw
}
\exp_not:N \exp_after:wN { \exp_not:N \tex_the:D #1 }
; \exp_not:N \@@_parse_one_register_dim:ww
\tl_to_str:n { pt } ; \exp_not:N \@@_parse_one_register_mu:www
. \tl_to_str:n { pt } ; \exp_not:N \@@_parse_one_register_int:www
\exp_not:N \q_stop
}
\exp_args:Nno \use:nn
{ \cs_new:Npn \@@_parse_one_register_auxii:wwwNw #1 . #2 }
{ \tl_to_str:n { pt } #3 ; #4#5 \q_stop }
{ #4 #1.#2; }
\exp_args:Nno \use:nn
{ \cs_new:Npn \@@_parse_one_register_mu:www #1 }
{ \tl_to_str:n { mu } ; #2 ; }
{ \@@_parse_one_register_dim:ww #1 ; }
\cs_new:Npn \@@_parse_one_register_int:www #1; #2.; #3;
{ \@@_parse:n { #1 e #3 } }
\cs_new:Npn \@@_parse_one_register_dim:ww #1; #2;
{
\exp_after:wN \@@_from_dim_test:ww
\int_value:w #2 \exp_after:wN ,
\int_value:w \__dim_eval:w #1 pt ;
}
% \end{macrocode}
% The \tn{wd}, \tn{dp}, \tn{ht} primitives expect an integer argument.
% We abuse the exponent parser to find the integer argument: simply
% include the exponent marker~|e|. Once that \enquote{exponent} is
% found, use \cs{tex_the:D} to find the box dimension and then copy
% what we did for dimensions.
% \begin{macrocode}
\cs_new:Npn \@@_parse_one_register_wd:w
#1#2 \exp_after:wN #3#4 \@@_parse_expand:w
{
#1
\exp_after:wN \@@_parse_one_register_wd:Nw
#4 \@@_parse_expand:w e
}
\cs_new:Npn \@@_parse_one_register_wd:Nw #1#2 ;
{
\exp_after:wN \@@_from_dim_test:ww
\exp_after:wN 0 \exp_after:wN ,
\int_value:w \__dim_eval:w
\exp_after:wN \use:n \exp_after:wN { \tex_the:D #1 #2 } ;
}
% \end{macrocode}
% \end{macro}
%
% \begin{macro}[EXP]{\@@_parse_one_digit:NN}
% A digit marks the beginning of an explicit floating point number.
% Once the number is found, we catch the case of overflow and
% underflow with \cs{@@_sanitize:wN}, then
% \cs{@@_parse_infix_after_operand:NwN} expands \cs{@@_parse_infix:NN}
% after the number we find, to wrap the following infix operator as
% required. Finding the number itself begins by removing leading
% zeros: further steps are described later.
% \begin{macrocode}
\cs_new:Npn \@@_parse_one_digit:NN #1
{
\exp_after:wN \@@_parse_infix_after_operand:NwN
\exp_after:wN #1
\exp:w \exp_end_continue_f:w
\exp_after:wN \@@_sanitize:wN
\int_value:w \@@_int_eval:w 0 \@@_parse_trim_zeros:N
}
% \end{macrocode}
% \end{macro}
%
% \begin{macro}[EXP]{\@@_parse_one_other:NN}
% For this function, |#2|~is a character token which is not a digit.
% If it is an \textsc{ascii} letter, \cs{@@_parse_letters:N} beyond this one and give
% the result to \cs{@@_parse_word:Nw}. Otherwise, the character is
% assumed to be a prefix operator, and we build
% |\__fp_parse_prefix_|\meta{operator}|:Nw|.
% \begin{macrocode}
\cs_new:Npn \@@_parse_one_other:NN #1 #2
{
\if_int_compare:w
\@@_int_eval:w
( `#2 \if_int_compare:w `#2 > `Z - 32 \fi: ) / 26
= 3 \exp_stop_f:
\exp_after:wN \@@_parse_word:Nw
\exp_after:wN #1
\exp_after:wN #2
\exp:w \exp_after:wN \@@_parse_letters:N
\exp:w
\else:
\exp_after:wN \@@_parse_prefix:NNN
\exp_after:wN #1
\exp_after:wN #2
\cs:w
@@_parse_prefix_ \token_to_str:N #2 :Nw
\exp_after:wN
\cs_end:
\exp:w
\fi:
\@@_parse_expand:w
}
% \end{macrocode}
% \end{macro}
%
% \begin{macro}[EXP]{\@@_parse_word:Nw}
% \begin{macro}[rEXP]{\@@_parse_letters:N}
% Finding letters is a simple recursion. Once \cs{@@_parse_letters:N}
% has done its job, we try to build a control sequence from the
% word~|#2|. If it is a known word, then the corresponding action is
% taken, and otherwise, we complain about an unknown word, yield
% \cs{c_nan_fp}, and look for the following infix operator. Note that
% the unknown word could be a mistyped function as well as a mistyped
% constant, so there is no way to tell whether to look for arguments;
% we do not.
% The standard requires \enquote{inf} and \enquote{infinity} and
% \enquote{nan} to be recognized regardless of case, but we probably
% don't want to allow every \pkg{l3fp} word to have an arbitrary
% mixture of lower and upper case, so we test and use a
% differently-named control sequence.
% \begin{macrocode}
\cs_new:Npn \@@_parse_word:Nw #1#2;
{
\cs_if_exist_use:cF { @@_parse_word_#2:N }
{
\cs_if_exist_use:cF { @@_parse_caseless_ \str_fold_case:n {#2} :N }
{
\__kernel_msg_expandable_error:nnn
{ kernel } { unknown-fp-word } {#2}
\exp_after:wN \c_nan_fp \exp:w \exp_end_continue_f:w
\@@_parse_infix:NN
}
}
#1
}
\cs_new:Npn \@@_parse_letters:N #1
{
\exp_end_continue_f:w
\if_int_compare:w