Jose,
Thank you for the patient explanatory response. I didn't doubt for
a second that the compiler was "correct". My conundrum was twofold,
however. 1) is there some documentation or specification of the
language that I could have read that would have explained this to me,
and 2) Is it necessary that the compiler behave this way and this the
way that we'd want the language to work at all?
Regarding #1 - I just couldn't find it. I understand Elixir is a
young language but I think such an "annotated reference" of the
language will become more and more important if it doesn't yet exist.
No doubt this is further complicated by it's attachment to Erlang. But
I'm hoping I just missed something that you could point me to.
Regarding #2 - Without a clearer understanding of the formal
specification of the language (ala #1) that tells me otherwise, I
still think (your corrected) Version #1 should be legal Elixir but
perhaps just requires a different mechanism for identifying when the
Module/Struct is fully defined. A two pass system could absolutely
still work this way. More importantly, perhaps, is don't you think
Example #1 is a much clearer way for the programmer to express his
intent and shouldn't that be a strong consideration when balancing the
design of a programming language?
You speak as if this is already a settled issue and I completely
understand if I'm just late in the game. (There are other interesting
bits in the language I note but this is one of the more obvious ones
that I think new devs would encounter.) That's why I'm so interested
in #1 so I can get a more formal understanding of Elixir and be a
better contributor. Language design is a concern near & dear to my
heart and Elixir is fraught with potential, cool insights, and
occasional frustrations. Of course if you can't name 10 things you
hate about your favorite language then you certainly don't know it
well enough. More importantly is then knowing why those warts exist
and what tradeoffs were made that got them that way in the first
place. Languages like C++ have some mind twisting "features" and
syntax but one can absolutely trace each one back to first principles
and clearly understand how they got there (irrespective of whether or
not one agrees with them) by reading existing documentation on the
subject. Java and javascript, for example, have no such core
beliefs/principles and suffer greatly as a result.
I'd like to see Elixir's development be more like the former than
the latter. If documentation that satisfies #1 does not yet exist, how
would you recommend someone start to get familiar with the compiler
(and the most relevant aspects of the Erlang/BEAM target) in order to
most effectively familiarize themselves with how the language is
specified (at least in terms of code, which sometimes confuse intent
with practicalities) and implemented?
I see Elixir as the most promising language introduced since
python (of which I am also a great advocate). I could definitely see
it displacing Java, Python, Ruby, & C# while introducing much stronger
anti-fragile abstractions to the industry. I'd like to help as much as
possible in seeing it reach its full potential.
many thanx,
-- Ben Scherrey
On Sat, Jul 16, 2016 at 10:05 PM, José Valim
<[email protected]> wrote:
>> I believe the following code examples are all identically equivalent.
>
>
> Well, the compiler is explicitly telling you that they are not. :)
>
> There are two concepts to understand in the examples you posted: one of
> aliasing and the other one is about compile time expansion. In particular,
> remember that structs are expanded at compilation time.
>
>>
>> Version 1:
>> defmodule Demo do
>> defmodule Demo.Embed do
>> defstruct local: 0
>> end
>>
>> defstruct name: "", embed: %Embed{}
>> end
>
>
> In this example, you are actually defining a struct named Demo.Demo.Embed.
> In this case, when you try to expand %Embed{}, it doesn't see an Embed alias
> and then it tries to expand the "root" Embed which does not exist. That's
> *not* the error message you reported though. So I am assuming you mixed
> something up either when copying the code or the error message.
>
> If we fix the code:
>
>> defmodule Demo do
>> defmodule Embed do
>> defstruct local: 0
>> end
>>
>> defstruct name: "", embed: %Embed{}
>> end
>
>
> Then the error is the one you reported:
>
>> == Compilation error on file lib/demo.ex ==
>> ** (CompileError) lib/demo.ex:7: cannot access struct Demo.Embed, the
>> struct was not yet defined or the struct is being accessed in the same
>> context that defines it
>> (elixir) src/elixir_map.erl:58: :elixir_map.translate_struct/4
>> (stdlib) lists.erl:1353: :lists.mapfoldl/3
>> (stdlib) lists.erl:1354: :lists.mapfoldl/3
>
>
> And then:
>
>> This: "the struct is being accessed in the same context that defines
>> it" is a pretty big hint but I disagree with it. By time line 7 is
>> being compiled the Embed struct is already fully defined.
>
>
> The compiler is correct, regardless of how much you disagree with it. :)
> Remember that structs are expanded at compile time so when you try to expand
> %Embed{}, the defmodule macro was also expanded but the module contents was
> not yet executed/defined.
>
> You can effectively think of your code as running twice: one goes through
> all the source, doing all the compiler time work, then when you execute it
> does another pass, running all of the expanded code.
>
> Version 2 will fail since you can't use a struct before you defined it. The
> next two examples are correct.
>
> --
> You received this message because you are subscribed to the Google Groups
> "elixir-lang-core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JF6BK1MkZ_bOUuXH33ranJrWnJGo6KV9wLwPKy%2BTcfTQ%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CACo3ShjFQJXG%3DKgHt-z%2BjkR05wdZexAQV%3Dj%3Dnrk5C1V%2B86BfZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
