> even enabling people to use metaprograming to do some really interesting
things (shorter_maps for example could be able to do `~MyStruct{id}`
instead of `~M{%MyStruct id}`)
*Maybe*. Sigils follow the rules for strings, so they are not really good
for handling code and this was one of the lessons learned by the
shorter_maps project. For example, imagine you want to do this:
~Project{id ~Manager{id}}
It doesn't really work because you have to escape the closing } inside the
manager. Sure, you could alternate {...} with <...> or something else, but
that's precisely the point. Sigils are strings, and they are not structured
text, so you have to escape and handle delimiters accordingly.
The other issue is that sigils are currently lexical, so you would have to
import the lexical sigil for every struct before your shorter maps
proposal. So I really don't think this feature would be usable with sigils.
> I mean, I know the benefits we take from not allowing interpolation for
some sigils (I suppose it might make a huge difference for some cases), but
in the end it is just a convention and people are already allowed to break
it right?
No, they are enforced by the language.
*José Valim*
www.plataformatec.com.br
Founder and Director of R&D
On Fri, Oct 25, 2019 at 1:32 AM Kelvin Raffael Stinghen <
[email protected]> wrote:
> > I agree with the idea in principle but I may be a symptom of a bigger
> problem, which is how to represent data constructors generally.
>
> Yep, I totally agree.
>
> > We could of course introduce two or three letter sigils (or remove the
> restriction altogether)
>
> I like the idea of no limit for sigil names, I think this is really a good
> direction, even enabling people to use metaprograming to do some really
> interesting things (shorter_maps for example could be able to do
> `~MyStruct{id}` instead of `~M{%MyStruct id}`)
>
> > how we would want to handle the casing in said situations
>
> Well, IMO the convention adopted now is interesting but not very
> reasonable. I mean, I know the benefits we take from not allowing
> interpolation for some sigils (I suppose it might make a huge difference
> for some cases), but in the end it is just a convention and people are
> already allowed to break it right? What if we just don’t care about that at
> all and let people create sigils however they want? I don’t think we should
> change the current convention though, I think we must leave it as it is for
> one letter sigils and leave it open for more.
>
> Best,
> Kelvin Stinghen
> [email protected]
>
> On Oct 24, 2019, at 17:47, Wojtek Mach <[email protected]> wrote:
>
> So this is a separate discussion but what I'd rather see is another sigil
> like mechanism for structs that would make these valid:
>
> URI[https://elixir-lang.org]
> Decimal[1]
> Complex[0, 1]
> Ratio[1, 3]
> MapSet[1, 2, 3]
> Money[100 USD]
> Date.Range[2019-01-01/12-31]
>
> Having such mechanism doesn't address your concern but if such exists I
> feel like at least sigils become less scarce because I feel like people
> would reach out for them.
> If there's appetite for something like this, let me know. Off the bat
> there's a huge difference semantically between Decimal[1] and Complex[0, 1]
> but maybe there's a way to reconcile it.
> (Btw, it happens so that `Decimal[1]` is _syntactically_ correct but
> `Complex[0, 1]` isn't :))
>
> --
> 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/c7d345e5-b1df-4014-b683-ff499a1fada5%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/c7d345e5-b1df-4014-b683-ff499a1fada5%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
> --
> 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/6B80ED07-814E-4FA0-8E5D-FB846AC5983C%40gmail.com
> <https://groups.google.com/d/msgid/elixir-lang-core/6B80ED07-814E-4FA0-8E5D-FB846AC5983C%40gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAGnRm4%2BMEh%3DOmwZn8du%2Bj%3Do9J_349AY5o9Gb%2BGM5hS3WtZrqAA%40mail.gmail.com.
