aboutsummaryrefslogtreecommitdiffstats
path: root/erts/doc/src/absform.xml
AgeCommit message (Collapse)Author
2016-04-28erts: Add exact association types to the abstract format docHans Bolinder
2016-03-04erts: Use 'bit string' in The Abstract Format documentHans Bolinder
2016-01-20erts: Improve readability of The Abstract FormatHans Bolinder
More verbose, but hopefully more readable than before.
2016-01-20erts: Improve the documentation of the abstract formatHans Bolinder
2015-12-09Merge branch 'maint'Hans Bolinder
* maint: erts: Correct the types section in The Abstract Format document
2015-12-09erts: Correct the types section in The Abstract Format documentHans Bolinder
Fixed a mistake in commit 23885a.
2015-12-07Merge branch 'maint'Hans Bolinder
* maint: doc: Fix some minor issues in Types and Function Specifications erts: Remove CDATA from The Abstract Format document erts: Correct the types section in The Abstract Format document stdlib: Correct pretty-printing of map types stdlib: Pretty-print constraints as 'V :: T' Conflicts: erts/doc/src/absform.xml
2015-12-07erts: Remove CDATA from The Abstract Format documentHans Bolinder
2015-12-07erts: Correct the types section in The Abstract Format documentHans Bolinder
The Types section is more consistent with Kostis' text in The Reference Manual.
2015-10-08Take out automatic insertion of 'undefined' from typed record fieldsKostis Sagonas
Background ----------- In record fields with a type declaration but without an initializer, the Erlang parser inserted automatically the singleton type 'undefined' to the list of declared types, if that value was not present there. I.e. the record declaration: -record(rec, {f1 :: float(), f2 = 42 :: integer(), f3 :: some_mod:some_typ()}). was translated by the parser to: -record(rec, {f1 :: float() | 'undefined', f2 = 42 :: integer(), f3 :: some_mod:some_typ() | 'undefined'}). The rationale for this was that creation of a "dummy" #rec{} record should not result in a warning from dialyzer that e.g. the implicit initialization of the #rec.f1 field violates its type declaration. Problems --------- This seemingly innocent action has some unforeseen consequences. For starters, there is no way for programmers to declare that e.g. only floats make sense for the f1 field of #rec{} records when there is no `obvious' default initializer for this field. (This also affects tools like PropEr that use these declarations produced by the Erlang parser to generate random instances of records for testing purposes.) It also means that dialyzer does not warn if e.g. an is_atom/1 test or something more exotic like an atom_to_list/1 call is performed on the value of the f1 field. Similarly, there is no way to extend dialyzer to warn if it finds record constructions where f1 is not initialized to some float. Last but not least, it is semantically problematic when the type of the field is an opaque type: creating a union of an opaque and a structured type is very problematic for analysis because it fundamentally breaks the opacity of the term at that point. Change ------- To solve these problems the parser will not automatically insert the 'undefined' value anymore; instead the user has the option to choose the places where this value makes sense (for the field) and where it does not and insert the | 'undefined' there manually. Consequences of this change ---------------------------- This change means that dialyzer will issue a warning for all places where records with uninitialized fields are created and those fields have a declared type that is incompatible with 'undefined' (e.g. float()). This warning can be suppressed easily by adding | 'undefined' to the type of this field. This also adds documentation that the user really intends to create records where this field is uninitialized.
2015-08-28Add missing behavior/behaviours to absform docsLoïc Hoguin
2015-06-18Change license text to APLv2Bruce Yinhe
2015-06-12Update the documentation of the abstract formatHans Bolinder
The parenthesized type with tag 'paren_type' is no longer created by the Erlang Parser as of OTP 18.0. The tag 'user_type' is used for user defined types as of OTP 18.0. In releases before commit 7ad783 'type' is used.
2015-06-12Document abstract format of type-related treesAnthony Ramine
2014-01-31Document maps-related abstract syntax treesAnthony Ramine
{map,Loc,Fields} {map,Loc,Argument,Fields} {map_field_assoc,Loc,Name,Value} {map_field_exact,Loc,Name,Value}
2013-12-12Document named fun expressionsAnthony Ramine
2013-04-19Convert XML files to UTF-8Hans Bolinder
2013-01-25Update copyright yearsBjörn-Egil Dahlberg
2013-01-16Remove support for the query keyword and query expressionsLoïc Hoguin
2011-12-09Update copyright yearsBjörn-Egil Dahlberg
2011-11-07EEP-23: Allow variables in fun M:F/ABjörn Gustavsson
Currently, the external fun syntax "fun M:F/A" only supports literals. That is, "fun lists:reverse/1" is allowed but not "fun M:F/A". In many real-life situations, some or all of M, F, A are not known until run-time, and one is forced to either use the undocumented erlang:make_fun/3 BIF or to use a "tuple fun" (which is deprecated). EEP-23 suggests that the parser (erl_parse) should immediately transform "fun M:F/A" to "erlang:make_fun(M, F, A)". We have not followed that approach in this implementation, because we want the abstract code to mirror the source code as closely as possible, and we also consider erlang:make_fun/3 to be an implementation detail that we might want to remove in the future. Instead, we will change the abstract format for "fun M:F/A" (in a way that is not backwards compatible), and while we are at it, we will move the translation from "fun M:F/A" to "erlang:make_fun(M, F, A)" from sys_pre_expand down to the v3_core pass. We will also update the debugger and xref to use the new format. We did consider making the abstract format backward compatible if no variables were used in the fun, but decided against it. Keeping it backward compatible would mean that there would be different abstract formats for the no-variable and variable case, and tools would have to handle both formats, probably forever. Reference: http://www.erlang.org/eeps/eep-0023.html
2009-11-20The R13B03 release.OTP_R13B03Erlang/OTP