Fails to parse Core Erlang generated with OTP18+
This (empty) example module,
-module(example).
with 17.5, c(example, to_core) gives
module 'example' ['module_info'/0,
'module_info'/1]
attributes []
'module_info'/0 =
fun () ->
call 'erlang':'get_module_info'
('example')
'module_info'/1 =
fun (_cor0) ->
call 'erlang':'get_module_info'
('example', _cor0)
end
But with 18, we get
module 'example' ['module_info'/0,
'module_info'/1]
attributes []
'module_info'/0 =
( fun () ->
( call ( 'erlang'
-| ['compiler_generated'] ):( 'get_module_info'
-| ['compiler_generated'] )
(( 'example'
-| ['compiler_generated'] ))
-| ['compiler_generated'] )
-| ['compiler_generated'] )
'module_info'/1 =
( fun (( _cor0
-| ['compiler_generated'] )) ->
( call ( 'erlang'
-| ['compiler_generated'] ):( 'get_module_info'
-| ['compiler_generated'] )
(( 'example'
-| ['compiler_generated'] ), ( _cor0
-| ['compiler_generated'] ))
-| ['compiler_generated'] )
-| ['compiler_generated'] )
end
and this library is not able to parse that. (I think what I am really asking here, though, is: Is this still in use and maintained?)
Thanks for all the work you've put into this, by the way 🎉
I don't think this sees heavy use in production or what have you. Just one-off tools and experiments. I took over maintenance at one point to fix a bug, plus occasional minor changes to keep it building. (Which I've been slacking on lately.)
That said, huh. A bug in the top-level annotations? There's been no revision of the core_erlang-1.0.3.pdf spec, so I'll reproduce and try to fix things this week.
@amtal: Thanks! Your response is good news, I'd have thought this might have been abandoned.
There's been no revision of the core_erlang-1.0.3.pdf spec
I'm afraid so, yes...
Looks like Var variable names are just type-aliased strings without annotations. As a result ((_cor0 -| ['compiler_generated'])), valid in the spec, isn't handled by the parser or final representation. This probably isn't the only place the syntax doesn't match the spec.
Erlang/OTP 20 no longer produces compiler_generated tags on toy examples. It's still present in the compiler's test suite and some of its code, such as v3_core.erl.
I'm loathe to break the type API on obscure code that tends to be hacked on, poorly version pinned, and forgotten. Will look where else the spec doesn't match Language.CoreErlang.Syntax, and see if it's worth generalizing the pattern rather than case-by-casing it.