head	1.4;
access;
symbols
	pkgsrc-2015Q3:1.3.0.80
	pkgsrc-2015Q3-base:1.3
	pkgsrc-2015Q2:1.3.0.78
	pkgsrc-2015Q2-base:1.3
	pkgsrc-2015Q1:1.3.0.76
	pkgsrc-2015Q1-base:1.3
	pkgsrc-2014Q4:1.3.0.74
	pkgsrc-2014Q4-base:1.3
	pkgsrc-2014Q3:1.3.0.72
	pkgsrc-2014Q3-base:1.3
	pkgsrc-2014Q2:1.3.0.70
	pkgsrc-2014Q2-base:1.3
	pkgsrc-2014Q1:1.3.0.68
	pkgsrc-2014Q1-base:1.3
	pkgsrc-2013Q4:1.3.0.66
	pkgsrc-2013Q4-base:1.3
	pkgsrc-2013Q3:1.3.0.64
	pkgsrc-2013Q3-base:1.3
	pkgsrc-2013Q2:1.3.0.62
	pkgsrc-2013Q2-base:1.3
	pkgsrc-2013Q1:1.3.0.60
	pkgsrc-2013Q1-base:1.3
	pkgsrc-2012Q4:1.3.0.58
	pkgsrc-2012Q4-base:1.3
	pkgsrc-2012Q3:1.3.0.56
	pkgsrc-2012Q3-base:1.3
	pkgsrc-2012Q2:1.3.0.54
	pkgsrc-2012Q2-base:1.3
	pkgsrc-2012Q1:1.3.0.52
	pkgsrc-2012Q1-base:1.3
	pkgsrc-2011Q4:1.3.0.50
	pkgsrc-2011Q4-base:1.3
	pkgsrc-2011Q3:1.3.0.48
	pkgsrc-2011Q3-base:1.3
	pkgsrc-2011Q2:1.3.0.46
	pkgsrc-2011Q2-base:1.3
	pkgsrc-2011Q1:1.3.0.44
	pkgsrc-2011Q1-base:1.3
	pkgsrc-2010Q4:1.3.0.42
	pkgsrc-2010Q4-base:1.3
	pkgsrc-2010Q3:1.3.0.40
	pkgsrc-2010Q3-base:1.3
	pkgsrc-2010Q2:1.3.0.38
	pkgsrc-2010Q2-base:1.3
	pkgsrc-2010Q1:1.3.0.36
	pkgsrc-2010Q1-base:1.3
	pkgsrc-2009Q4:1.3.0.34
	pkgsrc-2009Q4-base:1.3
	pkgsrc-2009Q3:1.3.0.32
	pkgsrc-2009Q3-base:1.3
	pkgsrc-2009Q2:1.3.0.30
	pkgsrc-2009Q2-base:1.3
	pkgsrc-2009Q1:1.3.0.28
	pkgsrc-2009Q1-base:1.3
	pkgsrc-2008Q4:1.3.0.26
	pkgsrc-2008Q4-base:1.3
	pkgsrc-2008Q3:1.3.0.24
	pkgsrc-2008Q3-base:1.3
	cube-native-xorg:1.3.0.22
	cube-native-xorg-base:1.3
	pkgsrc-2008Q2:1.3.0.20
	pkgsrc-2008Q2-base:1.3
	cwrapper-base:1.3
	cwrapper:1.3.0.18
	pkgsrc-2008Q1:1.3.0.16
	pkgsrc-2008Q1-base:1.3
	pkgsrc-2007Q4:1.3.0.14
	pkgsrc-2007Q4-base:1.3
	pkglint-current:1.3
	pkgsrc-2007Q3:1.3.0.12
	pkgsrc-2007Q3-base:1.3
	pkgsrc-2007Q2:1.3.0.10
	pkgsrc-2007Q2-base:1.3
	pkgsrc-2007Q1:1.3.0.8
	pkgsrc-2007Q1-base:1.3
	pkgsrc-2006Q4:1.3.0.6
	pkgsrc-2006Q4-base:1.3
	pkgsrc-2006Q3:1.3.0.4
	pkgsrc-2006Q3-base:1.3
	pkgsrc-2006Q2:1.3.0.2
	pkgsrc-2006Q2-base:1.3;
locks; strict;
comment	@# @;


1.4
date	2015.11.25.13.29.08;	author rillig;	state dead;
branches;
next	1.3;
commitid	wTE9Uc9JWdmhBtKy;

1.3
date	2006.06.29.17.02.32;	author rillig;	state Exp;
branches;
next	1.2;

1.2
date	2006.06.29.16.40.53;	author rillig;	state Exp;
branches;
next	1.1;

1.1
date	2006.05.23.08.10.37;	author rillig;	state Exp;
branches;
next	;


desc
@@


1.4
log
@Updated pkglint to 5.0

Notable changes include:
* The whole code has been rewritten in Go
* It is much faster, especially in recursive mode
* The code has unit tests, providing examples of use
* Some new explanations for existing warnings
* Some adjustments to previous warnings
@
text
@<!-- $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>
@


1.3
log
@Added examples for the (future) parser in pkglint.
@
text
@d1 1
a1 1
<!-- $NetBSD: chap.future.xml,v 1.2 2006/06/29 16:40:53 rillig Exp $ -->
@


1.2
log
@Some ideas for further restricting the definition and use of variables.
@
text
@d1 1
a1 1
<!-- $NetBSD: chap.future.xml,v 1.1 2006/05/23 08:10:37 rillig Exp $ -->
d46 20
@


1.1
log
@The "future directions" chapter gives a vision of what pkglint may do if
I find too much time.
@
text
@d1 1
a1 1
<!-- $NetBSD$ -->
d47 2
d50 21
@