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
|
<!-- $NetBSD: chap.future.xml,v 1.1 2015/11/25 16:42:21 rillig Exp $ -->
<chapter id="future">
<title>Future directions</title>
<sect1 id="future.tokenize">
<title>Tokenizing the input</title>
<para>For providing more exact diagnostics, it would be nice if
&pkglint; could point the user to the exact character position
of the smallest problematic text in a file. To do this, the
file's contents has to be splitted into tokens.</para>
<para>Doing this is nontrivial, since the tokenizing scheme
depends on the context in which the tokens are used. For
example, the <varname>COMMENT</varname> variable may contain
arbitrary characters (including <literal>'</literal> and
<literal>"</literal>), whereas in many other contexts these are
parts of quoted shell words.</para>
</sect1>
<sect1 id="future.ast">
<title>Working on abstract syntax trees (AST)</title>
<para>When the tokenizing above is done, the tokens could be
parsed by a grammar to form abstract syntax trees. These would
consist mainly of function application so that pkglint can infer
types and valid values over these trees. The following functions
are likely to appear.</para>
<table id="future.ast.func">
<title>Functions in the abstract syntax trees</title>
<tgroup cols="2">
<thead><row><entry>Function</entry><entry>Purpose</entry></row></thead>
<tbody>
<row><entry><function>quote</function>(Val)</entry><entry>The <literal>:Q</literal> modifier</entry></row>
<row><entry><function>append</function>(Val, Val)</entry><entry>The <literal>+=</literal> operator</entry></row>
<row><entry><function>concat</function>(Val, Val)</entry><entry>The direct concatenation of two values</entry></row>
<row><entry><function>subst</function>(Val, Subst)</entry><entry>The <literal>:S</literal> and <literal>:C</literal> modifiers</entry></row>
<row><entry><function>shell</function>(Val)</entry><entry>The <literal>!=</literal> operator and the <literal>:sh</literal> modifier</entry></row>
<row><entry><function>literal</function>(Val)</entry><entry>Introduces literal values</entry></row>
</tbody>
</tgroup>
</table>
<para>Examples:</para>
<programlisting>
WRKSRC= ${WRKDIR}
SUBST_SED.pkglint+= -e s\|@DATADIR@\|${PREFIX:Q}/share/pkglint\|g
</programlisting>
<para>The first line would be parsed as
<literal>assign(var("WRKSRC"), varuse("WRKDIR"))</literal>. The
second line would be parsed as
<literal>assign(var("SUBST_SED.pkglint"),
append(varuse("SUBST_SED.pkglint"), concat(concat(str("-e
s\\|@DATADIR@\\|"), quote(varuse("PREFIX"))),
str("/share/pkglint\\|g"))))</literal>.</para>
<para>At this point, unification together with a pattern matcher
on tree structures would come in handy, to allow the parser for
the shell commands to still operate on this parse tree. This
might eventually enable cross-language type inference.</para>
</sect1>
<sect1 id="future.vars">
<title>Even more restricted variables</title>
<para>Currently there are mainly two restrictions for variables:
What values they may contain (data types) and where they may be
defined and used, on a per-file basis.</para>
<para>The <filename>makevars.map</filename> file already
contains annotations to distinguish user-defined from
system-defined variables, but they are currently only used as
abbreviations and not further exploited. Based on these
definitions, sequence points may be defined in the pkgsrc
infrastructure where the values of these variables must have
certain properties, like being defined or being fixed (which
means that the variable will not change further).</para>
<para>For example, user-defined variables may then be specified
as follows. They are given default values in
<filename>mk/defaults/mk.conf</filename>, may be overridden by
any file that is included inside <varname>MAKECONF</varname>,
and after that, their value is fixed. They may then be used at
both load and run time.</para>
</sect1>
</chapter>
|
