\chapter{Non Supported Features of SB-Prolog version 3.1}

In this appendix we indicate some key features (sic) of \ourprolog\
that may affect the users at some point in their interaction with 
the system.  

\begin{itemize} 
\item	In \ourprolog\, there is no distinction between compiled and 
	interpreted code.  Predicates {\tt consult/[1,2], reconsult/[1,2]} 
	always compile the files that are given as their arguments instead 
	of interpreting them.  Interpreted code is only generated when
	using predicates {\tt assert/1, asserta/1}, and {\tt assertz/1}, or
	the standard predicate {\tt load\_dyn/1} and library predicate
	{\tt load\_dync/1}.
\item	The user cannot specify the name of the byte code file during 
	compilation.  The name of the byte code file is obtained in the way 
	explained in Section~\ref{compiler_invoking}, and object files for
	modules cannot be renamed.
\item	The byte code files produced by the compiler cannot be concatenated 
	together to produce other byte code files.  This happens because
	of the module system.  The byte code generated by the compiler,
	even for non-modules, contains information that indicates the fact
	that it is (it is not) a module and the name of the module.
\item	There is no assembler in the sense of the SB-Prolog assembler 
	described in Section~8.3 of the SB-Prolog manual~\cite{sbprolog}.
	However, assembly files are either generated by the compiler 
	(see Section~\ref{sec:CompilerOptions}), or can be produced by 
	disassembling object code files using the {\tt -d} command line
	option of the emulator (see Section~\ref{sec:EmuOptions}).
\end{itemize}
