1compile(3)                 Erlang Module Definition                 compile(3)
2
3
4

NAME

6       compile - Erlang Compiler
7

DESCRIPTION

9       This  module  provides an interface to the standard Erlang compiler. It
10       can generate either a new file, which contains the object code, or  re‐
11       turn a binary, which can be loaded directly.
12

DATA TYPES

14       option() = term()
15
16              See file/2 for detailed description
17

EXPORTS

19       env_compiler_options()
20
21              Return  compiler  options  given  via  the  environment variable
22              ERL_COMPILER_OPTIONS. If the value is a list, it is returned  as
23              is. If it is not a list, it is put into a list.
24
25       file(File)
26
27              Is  the  same  as file(File, [verbose,report_errors,report_warn‐
28              ings]).
29
30       file(File, Options) -> CompRet
31
32              Types:
33
34                 CompRet = ModRet | BinRet | ErrRet
35                 ModRet = {ok,ModuleName} | {ok,ModuleName,Warnings}
36                 BinRet = {ok,ModuleName,Binary} | {ok,ModuleName,Binary,Warn‐
37                 ings}
38                 ErrRet = error | {error,Errors,Warnings}
39
40              Compiles  the  code  in the file File, which is an Erlang source
41              code file without the .erl extension. Options determine the  be‐
42              havior of the compiler.
43
44              Returns {ok,ModuleName} if successful, or error if there are er‐
45              rors. An object code file is created if the compilation succeeds
46              without  errors.  It  is considered to be an error if the module
47              name in the source code is not the same as the basename  of  the
48              output file.
49
50              Available options:
51
52                basic_validation:
53                  This option is a fast way to test whether a module will com‐
54                  pile successfully. This is useful for code  generators  that
55                  want  to  verify  the code that they emit. No code is gener‐
56                  ated. If warnings are enabled,  warnings  generated  by  the
57                  erl_lint  module  (such as warnings for unused variables and
58                  functions) are also returned.
59
60                  Use option strong_validation to generate all  warnings  that
61                  the compiler would generate.
62
63                strong_validation:
64                  Similar  to  option  basic_validation. No code is generated,
65                  but more compiler passes are run  to  ensure  that  warnings
66                  generated  by the optimization passes are generated (such as
67                  clauses that will not match, or expressions that are guaran‐
68                  teed to fail with an exception at runtime).
69
70                binary:
71                  The  compiler returns the object code in a binary instead of
72                  creating an object file. If successful, the compiler returns
73                  {ok,ModuleName,Binary}.
74
75                bin_opt_info:
76                  The  compiler  will emit informational warnings about binary
77                  matching optimizations (both successful  and  unsuccessful).
78                  For  more information, see the section about bin_opt_info in
79                  the Efficiency Guide.
80
81                {compile_info, [{atom(), term()}]}:
82                  Allows compilers built on top of  compile  to  attach  extra
83                  compilation metadata to the compile_info chunk in the gener‐
84                  ated beam file.
85
86                  It is advised for compilers to remove all  non-deterministic
87                  information  if the deterministic option is supported and it
88                  was supplied by the user.
89
90                compressed:
91                  The compiler will compress the generated object code,  which
92                  can be useful for embedded systems.
93
94                debug_info:
95
96
97                  Includes  debug  information in the form of  Erlang Abstract
98                  Format in the debug_info chunk of the compiled beam  module.
99                  Tools  such  as  Debugger, Xref, and Cover require the debug
100                  information to be included.
101
102                  Warning: Source code can be reconstructed from the debug in‐
103                  formation.  Use  encrypted  debug  information  (encrypt_de‐
104                  bug_info) to prevent this.
105
106                  For details, see beam_lib(3).
107
108                {debug_info, {Backend, Data}}:
109
110
111                  Includes custom debug information in the form of  a  Backend
112                  module  with  custom  Data  in the compiled beam module. The
113                  given module must implement a debug_info/4 function  and  is
114                  responsible  for  generating different code representations,
115                  as described in the debug_info under beam_lib(3).
116
117                  Warning: Source code can be reconstructed from the debug in‐
118                  formation.  Use  encrypted  debug  information  (encrypt_de‐
119                  bug_info) to prevent this.
120
121                {debug_info_key,KeyString}:
122
123
124                {debug_info_key,{Mode,KeyString}}:
125
126
127                  Includes debug information, but encrypts it so that it  can‐
128                  not  be  accessed without supplying the key. (To give option
129                  debug_info as well is allowed,  but  not  necessary.)  Using
130                  this  option is a good way to always have the debug informa‐
131                  tion available during testing,  yet  protecting  the  source
132                  code.
133
134                  Mode is the type of crypto algorithm to be used for encrypt‐
135                  ing the debug information. The default  (and  currently  the
136                  only) type is des3_cbc.
137
138                  For details, see beam_lib(3).
139
140                encrypt_debug_info:
141
142
143                  Similar  to  the  debug_info_key option, but the key is read
144                  from an .erlang.crypt file.
145
146                  For details, see beam_lib(3).
147
148                deterministic:
149                  Omit the options and source tuples in the list  returned  by
150                  Module:module_info(compile),  and  reduce the paths in stack
151                  traces to the module name alone. This option  will  make  it
152                  easier to achieve reproducible builds.
153
154                makedep:
155                  Produces  a  Makefile rule to track headers dependencies. No
156                  object file is produced.
157
158                  By default, this rule is written to  <File>.Pbeam.  However,
159                  if  option binary is set, nothing is written and the rule is
160                  returned in Binary.
161
162                  For example, if you have the following module:
163
164                -module(module).
165
166                -include_lib("eunit/include/eunit.hrl").
167                -include("header.hrl").
168
169                  The Makefile rule generated by this option looks as follows:
170
171                module.beam: module.erl \
172                  /usr/local/lib/erlang/lib/eunit/include/eunit.hrl \
173                  header.hrl
174
175                makedep_side_effect:
176                  The dependecies are created as a side effect to  the  normal
177                  compilation  process.  This  means that the object file will
178                  also be produced. This option override the makedep option.
179
180                {makedep_output, Output}:
181                  Writes generated rules to  Output  instead  of  the  default
182                  <File>.Pbeam. Output can be a filename or an io_device(). To
183                  write to stdout, use standard_io. However, if binary is set,
184                  nothing  is  written to Output and the result is returned to
185                  the caller with {ok, ModuleName, Binary}.
186
187                {makedep_target, Target}:
188                  Changes the name of the rule emitted to Target.
189
190                makedep_quote_target:
191                  Characters in Target special to make(1) are quoted.
192
193                makedep_add_missing:
194                  Considers missing headers as generated files and  adds  them
195                  to the dependencies.
196
197                makedep_phony:
198                  Adds a phony target for each dependency.
199
200                'P':
201                  Produces  a  listing of the parsed code, after preprocessing
202                  and parse transforms, in the file <File>.P. No  object  file
203                  is produced.
204
205                'E':
206                  Produces a listing of the code, after all source code trans‐
207                  formations have been performed, in the file <File>.E. No ob‐
208                  ject file is produced.
209
210                'S':
211                  Produces  a  listing  of  the  assembler  code  in  the file
212                  <File>.S. No object file is produced.
213
214                report_errors/report_warnings:
215                  Causes errors/warnings to be printed as they occur.
216
217                report:
218                  A short form for both report_errors and report_warnings.
219
220                return_errors:
221                  If this flag is set,  {error,ErrorList,WarningList}  is  re‐
222                  turned when there are errors.
223
224                return_warnings:
225                  If this flag is set, an extra field, containing WarningList,
226                  is added to the tuples returned on success.
227
228                warnings_as_errors:
229                  Causes warnings to be treated as errors. This option is sup‐
230                  ported since R13B04.
231
232                return:
233                  A short form for both return_errors and return_warnings.
234
235                verbose:
236                  Causes  more verbose information from the compiler, describ‐
237                  ing what it is doing.
238
239                {source,FileName}:
240                  Overrides  the  source  file  name  as  presented  in   mod‐
241                  ule_info(compile) and stack traces.
242
243                {outdir,Dir}:
244                  Sets a new directory for the object code. The current direc‐
245                  tory is used for output, except when a  directory  has  been
246                  specified with this option.
247
248                export_all:
249                  Causes all functions in the module to be exported.
250
251                {i,Dir}:
252                  Adds  Dir to the list of directories to be searched when in‐
253                  cluding a  file.  When  encountering  an  -include  or  -in‐
254                  clude_lib  directive, the compiler searches for header files
255                  in the following directories:
256
257                  * ".", the current working directory of the file server
258
259                  * The base name of the compiled file
260
261                  * The directories specified using option  i;  the  directory
262                    specified last is searched first
263
264                {d,Macro}:
265
266
267                {d,Macro,Value}:
268                  Defines  a  macro Macro to have the value Value. Macro is of
269                  type atom, and Value can be any term. The default  Value  is
270                  true.
271
272                {parse_transform,Module}:
273                  Causes the parse transformation function Module:parse_trans‐
274                  form/2 to be applied to the parsed code before the  code  is
275                  checked for errors.
276
277                from_asm:
278                  The  input  file  is  expected to be assembler code (default
279                  file suffix ".S"). Notice that the format of assembler files
280                  is not documented, and can change between releases.
281
282                from_core:
283                  The  input  file  is  expected to be core code (default file
284                  suffix ".core"). Notice that the format of core files is not
285                  documented, and can change between releases.
286
287                no_spawn_compiler_process:
288                  By default, all code is compiled in a separate process which
289                  is terminated at  the  end  of  compilation.  However,  some
290                  tools,  like Dialyzer or compilers for other BEAM languages,
291                  may already manage their own worker processes  and  spawning
292                  an extra process may slow the compilation down. In such sce‐
293                  narios, you can pass this option to stop the  compiler  from
294                  spawning an additional process.
295
296                no_strict_record_tests:
297                  This option is not recommended.
298
299                  By    default,    the    generated    code   for   operation
300                  Record#record_tag.field verifies that the tuple  Record  has
301                  the  correct size for the record, and that the first element
302                  is the tag record_tag. Use this option to omit the verifica‐
303                  tion code.
304
305                no_error_module_mismatch:
306                  Normally the compiler verifies that the module name given in
307                  the source code is the same as the base name of  the  output
308                  file  and  refuses  to generate an output file if there is a
309                  mismatch. If you have a good reason (or  other  reason)  for
310                  having  a  module  name  unrelated to the name of the output
311                  file, this option disables that verification (there will not
312                  even be a warning if there is a mismatch).
313
314                {no_auto_import,[{F,A}, ...]}:
315                  Makes  the  function  F/A no longer being auto-imported from
316                  the erlang module, which resolves BIF name clashes. This op‐
317                  tion must be used to resolve name clashes with BIFs auto-im‐
318                  ported before R14A, if it is needed to call the local  func‐
319                  tion with the same name as an auto-imported BIF without mod‐
320                  ule prefix.
321
322            Note:
323                As from R14A and forward, the compiler resolves calls  without
324                module  prefix  to  local  or imported functions before trying
325                with auto-imported BIFs. If the BIF is to be called,  use  the
326                erlang  module prefix in the call, not {no_auto_import,[{F,A},
327                ...]}.
328
329
330                  If this option is written in the source code, as a  -compile
331                  directive,  the syntax F/A can be used instead of {F,A}, for
332                  example:
333
334                -compile({no_auto_import,[error/1]}).
335
336                no_auto_import:
337                  Do not auto-import any functions from erlang module.
338
339                no_line_info:
340                  Omits line number information to produce a slightly  smaller
341                  output file.
342
343                {extra_chunks, [{binary(), binary()}]}:
344                  Pass  extra chunks to be stored in the .beam file. The extra
345                  chunks must be a list of tuples with a four byte  binary  as
346                  chunk name followed by a binary with the chunk contents. See
347                  beam_lib for more information.
348
349              If warnings are turned on (option report_warnings described ear‐
350              lier),  the following options control what type of warnings that
351              are generated. Except from {warn_format,Verbosity}, the  follow‐
352              ing options have two forms:
353
354                * A warn_xxx form, to turn on the warning.
355
356                * A nowarn_xxx form, to turn off the warning.
357
358              In the descriptions that follow, the form that is used to change
359              the default value are listed.
360
361                {warn_format, Verbosity}:
362                  Causes warnings to be emitted for malformed  format  strings
363                  as arguments to io:format and similar functions.
364
365                  Verbosity selects the number of warnings:
366
367                  * 0 = No warnings
368
369                  * 1 = Warnings for invalid format strings and incorrect num‐
370                    ber of arguments
371
372                  * 2 = Warnings also when the validity cannot be checked, for
373                    example, when the format string argument is a variable.
374
375                  The default verbosity is 1. Verbosity 0 can also be selected
376                  by option nowarn_format.
377
378                nowarn_bif_clash:
379                  This option is removed, it generates a fatal error if used.
380
381            Warning:
382                As from beginning with R14A, the compiler no longer calls  the
383                auto-imported  BIF if the name clashes with a local or explic‐
384                itly imported function, and a  call  without  explicit  module
385                name  is  issued.  Instead,  the local or imported function is
386                called. Still accepting nowarn_bif_clash would make  a  module
387                calling  functions  clashing  with  auto-imported BIFs compile
388                with both the old and new compilers, but with completely  dif‐
389                ferent semantics. This is why the option is removed.
390
391                The  use  of  this option has always been discouraged. As from
392                R14A, it is an error to use it.
393
394                To resolve BIF clashes,  use  explicit  module  names  or  the
395                {no_auto_import,[F/A]} compiler directive.
396
397
398                {nowarn_bif_clash, FAs}:
399                  This option is removed, it generates a fatal error if used.
400
401            Warning:
402                The  use  of  this option has always been discouraged. As from
403                R14A, it is an error to use it.
404
405                To resolve BIF clashes,  use  explicit  module  names  or  the
406                {no_auto_import,[F/A]} compiler directive.
407
408
409                nowarn_export_all:
410                  Turns  off  warnings  for uses of the export_all option. De‐
411                  fault is to emit a warning  if  option  export_all  is  also
412                  given.
413
414                warn_export_vars:
415                  Emits  warnings  for  all  implicitly exported variables re‐
416                  ferred to after the primitives where  they  were  first  de‐
417                  fined.  By default, the compiler only emits warnings for ex‐
418                  ported variables referred to in a pattern.
419
420                nowarn_shadow_vars:
421                  Turns off warnings for "fresh" variables in  functional  ob‐
422                  jects  or list comprehensions with the same name as some al‐
423                  ready defined variable. Default is to emit warnings for such
424                  variables.
425
426                nowarn_unused_function:
427                  Turns off warnings for unused local functions. Default is to
428                  emit warnings for all local functions that  are  not  called
429                  directly or indirectly by an exported function. The compiler
430                  does not include unused local  functions  in  the  generated
431                  beam  file,  but  the  warning  is  still useful to keep the
432                  source code cleaner.
433
434                {nowarn_unused_function, FAs}:
435                  Turns  off  warnings  for  unused   local   functions   like
436                  nowarn_unused_function  does, but only for the mentioned lo‐
437                  cal functions. FAs is a tuple {Name,Arity} or a list of such
438                  tuples.
439
440                nowarn_deprecated_function:
441                  Turns  off  warnings  for calls to deprecated functions. De‐
442                  fault is to emit warnings for every call to a function known
443                  by  the  compiler to be deprecated. Notice that the compiler
444                  does not know about attribute -deprecated(), but uses an as‐
445                  sembled  list of deprecated functions in Erlang/OTP. To do a
446                  more general check, the Xref tool  can  be  used.  See  also
447                  xref(3)  and  the function xref:m/1, also accessible through
448                  the function c:xm/1.
449
450                {nowarn_deprecated_function, MFAs}:
451                  Turns off warnings for calls to  deprecated  functions  like
452                  nowarn_deprecated_function  does, but only for the mentioned
453                  functions. MFAs is a tuple {Module,Name,Arity} or a list  of
454                  such tuples.
455
456                nowarn_deprecated_type:
457                  Turns  off  warnings for use of deprecated types. Default is
458                  to emit warnings for every use of a type known by  the  com‐
459                  piler to be deprecated.
460
461                nowarn_removed:
462                  Turns off warnings for calls to functions that have been re‐
463                  moved. Default is to emit warnings for every call to a func‐
464                  tion  known  by  the  compiler to have been recently removed
465                  from Erlang/OTP.
466
467                {nowarn_removed, ModulesOrMFAs}:
468                  Turns off warnings for calls to modules  or  functions  that
469                  have  been  removed.  Default  is to emit warnings for every
470                  call to a function known by the compiler to  have  been  re‐
471                  cently removed from Erlang/OTP.
472
473                nowarn_obsolete_guard:
474                  Turns  off warnings for calls to old type testing BIFs, such
475                  as pid/1 and list/1. See the Erlang Reference Manual  for  a
476                  complete  list  of  type  testing BIFs and their old equiva‐
477                  lents. Default is to emit warnings for  calls  to  old  type
478                  testing BIFs.
479
480                warn_unused_import:
481                  Emits  warnings for unused imported functions. Default is to
482                  emit no warnings for unused imported functions.
483
484                nowarn_unused_vars:
485                  By default, warnings are emitted for unused  variables,  ex‐
486                  cept  for  variables  beginning  with an underscore ("Prolog
487                  style warnings"). Use this option to turn off this  kind  of
488                  warnings.
489
490                nowarn_unused_record:
491                  Turns  off  warnings  for unused record types. Default is to
492                  emit warnings for unused locally defined record types.
493
494                nowarn_nif_inline:
495                  By default, warnings are emitted when inlining is enabled in
496                  a  module that may load NIFs, as the compiler may inline NIF
497                  fallbacks by accident. Use this option to turn off this kind
498                  of warnings.
499
500              Another  class  of  warnings is generated by the compiler during
501              optimization and code generation. They warn about patterns  that
502              will  never  match (such as a=b), guards that always evaluate to
503              false, and expressions that always fail (such as atom+42).
504
505              Those warnings cannot be disabled (except by disabling all warn‐
506              ings).
507
508          Note:
509              The  compiler does not warn for expressions that it does not at‐
510              tempt to optimize. For example, the compiler tries  to  evaluate
511              1/0,  detects that it will cause an exception, and emits a warn‐
512              ing. However, the compiler is silent about the  similar  expres‐
513              sion,  X/0,  because  of  the variable in it. Thus, the compiler
514              does not even try to evaluate and therefore it  emits  no  warn‐
515              ings.
516
517
518          Warning:
519              The  absence of warnings does not mean that there are no remain‐
520              ing errors in the code.
521
522
523          Note:
524              All options, except the include  path  ({i,Dir}),  can  also  be
525              given  in the file with attribute -compile([Option,...]). Attri‐
526              bute -compile() is allowed after the function definitions.
527
528
529          Note:
530              Before OTP 22, the option {nowarn_deprecated_function, MFAs} was
531              only  recognized  when  given  in  the file with attribute -com‐
532              pile(). (The option {nowarn_unused_function,FAs} was incorrectly
533              documented to only work in a file, but it also worked when given
534              in the option list.) Starting from OTP 22, all options that  can
535              be given in the file can also be given in the option list.
536
537
538              For debugging of the compiler, or for pure curiosity, the inter‐
539              mediate code generated by each compiler pass can  be  inspected.
540              To  print  a complete list of the options to produce list files,
541              type compile:options() at the Erlang shell prompt.  The  options
542              are  printed  in the order that the passes are executed. If more
543              than one listing option is used, the one representing the earli‐
544              est pass takes effect.
545
546              Unrecognized options are ignored.
547
548              Both WarningList and ErrorList have the following format:
549
550              [{FileName,[ErrorInfo]}].
551
552              ErrorInfo  is  described  later in this section. The filename is
553              included here, as the compiler  uses  the  Erlang  pre-processor
554              epp,  which allows the code to be included in other files. It is
555              therefore important to know to which file the line number of  an
556              error or a warning refers.
557
558       forms(Forms)
559
560              Is  the same as forms(Forms, [verbose,report_errors,report_warn‐
561              ings]).
562
563       forms(Forms, Options) -> CompRet
564
565              Types:
566
567                 Forms = [Form]
568                 CompRet = BinRet | ErrRet
569                 BinRet = {ok,ModuleName,BinaryOrCode} |  {ok,ModuleName,Bina‐
570                 ryOrCode,Warnings}
571                 BinaryOrCode = binary() | term()
572                 ErrRet = error | {error,Errors,Warnings}
573
574              Analogous  to  file/1,  but takes a list of forms (in the Erlang
575              abstract format representation) as first argument. Option binary
576              is  implicit,  that is, no object code file is produced. For op‐
577              tions that normally produce a listing file, such as 'E', the in‐
578              ternal  format  for  that compiler pass (an Erlang term, usually
579              not a binary) is returned instead of a binary.
580
581       format_error(ErrorDescriptor) -> chars()
582
583              Types:
584
585                 ErrorDescriptor = errordesc()
586
587              Uses an ErrorDescriptor and returns a deep  list  of  characters
588              that  describes  the  error. This function is usually called im‐
589              plicitly when an ErrorInfo structure (described in section Error
590              Information) is processed.
591
592       output_generated(Options) -> true | false
593
594              Types:
595
596                 Options = [term()]
597
598              Determines  whether  the compiler generates a beam file with the
599              given options. true means that a beam file is  generated.  false
600              means  that  the compiler generates some listing file, returns a
601              binary, or merely checks the syntax of the source code.
602
603       noenv_file(File, Options) -> CompRet
604
605              Works like file/2, except that the environment variable ERL_COM‐
606              PILER_OPTIONS is not consulted.
607
608       noenv_forms(Forms, Options) -> CompRet
609
610              Works   like  forms/2,  except  that  the  environment  variable
611              ERL_COMPILER_OPTIONS is not consulted.
612
613       noenv_output_generated(Options) -> true | false
614
615              Types:
616
617                 Options = [term()]
618
619              Works like output_generated/1, except that the environment vari‐
620              able ERL_COMPILER_OPTIONS is not consulted.
621

DEFAULT COMPILER OPTIONS

623       The  (host  operating system) environment variable ERL_COMPILER_OPTIONS
624       can be used to give default compiler options. Its value must be a valid
625       Erlang  term.  If the value is a list, it is used as is. If it is not a
626       list, it is put into a list.
627
628       The list is appended to any options given to file/2, forms/2, and  out‐
629       put_generated/2.    Use   the   alternative   functions   noenv_file/2,
630       noenv_forms/2, or noenv_output_generated/2 if you do not want the envi‐
631       ronment  variable  to be consulted, for example, if you are calling the
632       compiler recursively from inside a parse transform.
633
634       The list can be retrieved with env_compiler_options/0.
635

INLINING

637       The compiler can do function inlining within an Erlang module. Inlining
638       means that a call to a function is replaced with the function body with
639       the arguments replaced with the actual values. The semantics  are  pre‐
640       served,  except if exceptions are generated in the inlined code. Excep‐
641       tions are reported as occurring in the function the  body  was  inlined
642       into.   Also,  function_clause  exceptions  are  converted  to  similar
643       case_clause exceptions.
644
645       When a function is inlined, the original function is kept if it is  ex‐
646       ported  (either  by  an explicit export or if the option export_all was
647       given) or if not all calls to the function are inlined.
648
649       Inlining does not necessarily improve running time. For example, inlin‐
650       ing  can increase Beam stack use, which probably is detrimental to per‐
651       formance for recursive functions.
652
653       Inlining is never default. It must be explicitly enabled  with  a  com‐
654       piler option or a -compile() attribute in the source module.
655
656       To  enable  inlining,  either use the option inline to let the compiler
657       decide which functions to  inline,  or  {inline,[{Name,Arity},...]}  to
658       have  the  compiler inline all calls to the given functions. If the op‐
659       tion is given inside a compile directive in an Erlang module, {Name,Ar‐
660       ity} can be written as Name/Arity.
661
662       Example of explicit inlining:
663
664       -compile({inline,[pi/0]}).
665
666       pi() -> 3.1416.
667
668
669       Example of implicit inlining:
670
671       -compile(inline).
672
673       The option {inline_size,Size} controls how large functions that are al‐
674       lowed to be inlined. Default is 24, which keeps the size of the inlined
675       code  roughly the same as the un-inlined version (only relatively small
676       functions are inlined).
677
678       Example:
679
680       %% Aggressive inlining - will increase code size.
681       -compile(inline).
682       -compile({inline_size,100}).
683

INLINING OF LIST FUNCTIONS

685       The compiler can also inline various list manipulation  functions  from
686       the module list in STDLIB.
687
688       This  feature  must  be  explicitly enabled with a compiler option or a
689       -compile() attribute in the source module.
690
691       To enable inlining of list functions, use option inline_list_funcs.
692
693       The following functions are inlined:
694
695         * lists:all/2
696
697         * lists:any/2
698
699         * lists:foreach/2
700
701         * lists:map/2
702
703         * lists:flatmap/2
704
705         * lists:filter/2
706
707         * lists:foldl/3
708
709         * lists:foldr/3
710
711         * lists:mapfoldl/3
712
713         * lists:mapfoldr/3
714

PARSE TRANSFORMATIONS

716       Parse transformations are used when a programmer wants  to  use  Erlang
717       syntax  but  with different semantics. The original Erlang code is then
718       transformed into other Erlang code.
719

ERROR INFORMATION

721       The ErrorInfo mentioned earlier is the  standard  ErrorInfo  structure,
722       which is returned from all I/O modules. It has the following format:
723
724       {ErrorLine, Module, ErrorDescriptor}
725
726       ErrorLine  is  the atom none if the error does not correspond to a spe‐
727       cific line, for example, if the source file does not exist.
728
729       A string describing the error is obtained with the following call:
730
731       Module:format_error(ErrorDescriptor)
732

SEE ALSO

734       epp(3), erl_id_trans(3), erl_lint(3), beam_lib(3)
735
736
737
738Ericsson AB                    compiler 7.6.9.1                     compile(3)
Impressum