92 lines
3.9 KiB
XML
92 lines
3.9 KiB
XML
<!-- $NetBSD: chap.future.xml,v 1.3 2006/06/29 17:02:32 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>
|