Type definitions and function specifications
114 views
Skip to first unread message
Robert Virding
Nov 6, 2016, 6:33:21 PM11/6/16
to Lisp Flavoured Erlang
As many of you probably know I have been working to add types to LFE. Or rather to add type declarations and function specifications in an Erlang compatible way. I just want to report what is happening and how far I have gotten with the work.
So far:
- Defined a syntax which is very close to the erlang syntax, mainly the left parentheses have been moved to make a more lisp-like syntax. As far as I know everything you can write in the erlang works in LFE.
- Defined macros deftype, defopaque and defspec (with corresponding forms define-type, define-opaque-type and define-function-spec) for defining types and specs.
- You can add types to module metadata where it is checked and used as well as using the macros.
- You can add (spec ...) to defun (like with (doc ...)) and define-function metadata where it is accepted but as yet ignored.
- Including erlang .hrl files with type defs and function specs works.
- The type defs and function specs end up in the right place with the right syntax in the core erlang files so dialyzer should be able to handle them when I get around to cleaning up and releasing ldiayzer.
- Being able to have include files, both .lfe and .hrl, with type defs and func specs are why we need the define-XXX forms, though we could do without the type forms.
So what needs to be done now is:
- Extend the syntax so it can handle everything the erlang version can.
- Improve the lint to check the types/specs better.
- And, of course, fix ldialyzer so it will have some practical use.
Everything so far is in the 'dev-types' branch and is accessible. If you have pulled this branc before then delete it and do it again as I tend to use it as a store and have force pushed somethings. There is even a very basic doc file lfe_types which says a bit and gives some examples. Only some types are documented but this is mainly for showing how to do it, all the existing predefined erlang types shoudl work. To give some more help I include 2 pairs of files, a .hrl file with erlang syntax and a .lfe with the LFE equivalent: include_types for type defs, and include_specs for func specs.
Have fun,
Robert
So far:
- Defined a syntax which is very close to the erlang syntax, mainly the left parentheses have been moved to make a more lisp-like syntax. As far as I know everything you can write in the erlang works in LFE.
- Defined macros deftype, defopaque and defspec (with corresponding forms define-type, define-opaque-type and define-function-spec) for defining types and specs.
- You can add types to module metadata where it is checked and used as well as using the macros.
- You can add (spec ...) to defun (like with (doc ...)) and define-function metadata where it is accepted but as yet ignored.
- Including erlang .hrl files with type defs and function specs works.
- The type defs and function specs end up in the right place with the right syntax in the core erlang files so dialyzer should be able to handle them when I get around to cleaning up and releasing ldiayzer.
- Being able to have include files, both .lfe and .hrl, with type defs and func specs are why we need the define-XXX forms, though we could do without the type forms.
So what needs to be done now is:
- Extend the syntax so it can handle everything the erlang version can.
- Improve the lint to check the types/specs better.
- And, of course, fix ldialyzer so it will have some practical use.
Everything so far is in the 'dev-types' branch and is accessible. If you have pulled this branc before then delete it and do it again as I tend to use it as a store and have force pushed somethings. There is even a very basic doc file lfe_types which says a bit and gives some examples. Only some types are documented but this is mainly for showing how to do it, all the existing predefined erlang types shoudl work. To give some more help I include 2 pairs of files, a .hrl file with erlang syntax and a .lfe with the LFE equivalent: include_types for type defs, and include_specs for func specs.
Have fun,
Robert
Robert Virding
Nov 6, 2016, 7:31:31 PM11/6/16
to Lisp Flavoured Erlang
I just realised there is one thing I don't handle yet and that is binaries. Coming soon.
Robert
Robert
Robert Virding
Nov 13, 2016, 1:59:23 PM11/13/16
to Lisp Flavoured Erlang
Well actually we do support binaries and bitstrings but only the generic forms without specific lengths and not mixed. So
Robert
(binary) is any binary of bytes
(bitstring) is a bitstring of bits
Robert
Robert Virding
Dec 7, 2016, 6:56:43 PM12/7/16
to Lisp Flavoured Erlang
Work goes on. It now sort of works and has been merged into the develop branch but if you try remember it may change at any time.
One problem is getting it to work together with how erlang types work, and they have some idiosyncrasies. So type, opaque and spec are both special type-system attributes and normal attributes at the same time. So I can just define an attribute '-type(bert).' if I want to but it will be ignored later as the compiler does not include any type, opaque or spec attributes in the final code[*]. That is something we are stuck with.
For the typing information to be saved in the right way for dialyzer they must become attributes in the end, even if they disappear later. One way would be to keep the type/spec as metadata and any attributes with the same name just become "normal" attributes. You could then define them using deftype, defopaque and defspec and they would end up as metadata. It would then be hard to allow them in defmodule as it could separate them from the normal attributes. You could then also have specs in a defun as a special spec form before the code. If we wanted to be allowed to have them in defmodule then we would have to restrict them to only be used for typing so the macro could handle it[**].
Robert
[*] If you want to try something funny define an attribute -type({a,bad,type}). in an erlang module.
[**] The is no problem in define-module/extend-module where metadata is kept separate.
One problem is getting it to work together with how erlang types work, and they have some idiosyncrasies. So type, opaque and spec are both special type-system attributes and normal attributes at the same time. So I can just define an attribute '-type(bert).' if I want to but it will be ignored later as the compiler does not include any type, opaque or spec attributes in the final code[*]. That is something we are stuck with.
For the typing information to be saved in the right way for dialyzer they must become attributes in the end, even if they disappear later. One way would be to keep the type/spec as metadata and any attributes with the same name just become "normal" attributes. You could then define them using deftype, defopaque and defspec and they would end up as metadata. It would then be hard to allow them in defmodule as it could separate them from the normal attributes. You could then also have specs in a defun as a special spec form before the code. If we wanted to be allowed to have them in defmodule then we would have to restrict them to only be used for typing so the macro could handle it[**].
Robert
[*] If you want to try something funny define an attribute -type({a,bad,type}). in an erlang module.
[**] The is no problem in define-module/extend-module where metadata is kept separate.
Duncan McGreggor
Dec 8, 2016, 9:20:27 AM12/8/16
to lisp-flavo...@googlegroups.com
This is so great to hear, Robert! This is one of those features that's been on my wishlist for some time, and those it won't be ready by Christmas, I'm still going to consider it a 2016 Christmas present :-)
Thanks!d
--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
To post to this group, send email to lisp-flavoured-erlang@googlegroups.com.
Visit this group at https://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages