Fernando, yes. The reason I like this proposal is exactly because it steers multi-letter sigils away from aliases - which we have tried before and it introduced a bunch of separate issues with them.
On Sun, Feb 16, 2020 at 2:57 PM Fernando Tapia Rico <[email protected]> wrote: > (Related to Allen's comment) > > Sigils would be independent of aliases, right? > > For example, if Decimal provides sigil_Decimal and an alias is defined as > alias > Decimal, as: D then the sigil would still be used as ~Decimal<...> and > not ~D<...>. > > On Saturday, February 15, 2020 at 10:34:01 PM UTC+1, Bruce Tate wrote: >> >> I love this proposal. It takes a construct that was formerly limited and >> opens it up with very little cost in readability. >> >> -bt >> >> On Sat, Feb 15, 2020 at 4:04 PM Allen Madsen <[email protected]> >> wrote: >> >>> +1 >>> >>> I think if sigil names with dots is allowed, it should be based on the >>> fully qualified name of the module the sigil is defined in or it's alias. >>> For example: >>> >>> module Date >>> defmacro sigil_Range(range, _flags) do >>> #... >>> end >>> end >>> >>> require Date >>> alias Date, as: D >>> ~Date.Range<...> >>> ~D.Range<...> >>> >>> Allen Madsen >>> http://www.allenmadsen.com >>> >>> >>> On Sat, Feb 15, 2020 at 10:11 AM José Valim <[email protected]> >>> wrote: >>> >>>> I believe this is the best proposal on the topic so far. I agree with >>>> trade-offs too (disclaimer: we have talked about those trade-offs privately >>>> before). I would suggest two amendments: >>>> >>>> 1. Limit multi-letter sigils only to uppercase sigils for now >>>> 2. Include "only: :sigils" as part of the initial implementation >>>> >>>> >>>> On Sat, Feb 15, 2020 at 2:52 PM Wojtek Mach <[email protected]> >>>> wrote: >>>> >>>>> Currently sigils are single letter which means there can be only 2 x >>>>> 26 of them and some of them >>>>> are already taken by the standard library. As mentioned in [1] it's >>>>> not clear if there should be >>>>> for example a `~P` and if so, whether it should be for PID or Port. >>>>> Similarly, there couldn't be an >>>>> `~R` sigil for Reference given the symbol is already taken by Regex. >>>>> >>>>> I'd like to propose to extend sigils to support multiple letters. For >>>>> example, to define a >>>>> `~Port` sigil we'd write a `sigil_Port` function/macro and to use it >>>>> it would have to be either >>>>> local to the module or be imported. After the first letter, we could >>>>> only use US-ASCII letters >>>>> (a-z, A-Z). If a sigil starts with a lower-case letter it's >>>>> interpolated, otherwise it is not. >>>>> >>>>> As part of this proposal I'd like to introduce the following sigils to >>>>> the Kernel module: >>>>> >>>>> - `~Port<0.6>` >>>>> - `~PID<0.108.0>` >>>>> - `~Reference<0.2489367154.3551002625.84263>` >>>>> - `~Version<1.0.0>` >>>>> - `~URI<https://elixir-lang.org>` >>>>> >>>>> But worth mentioning that the primary goal of this proposal is allow >>>>> the community to build sigils >>>>> like these: >>>>> >>>>> - `~Decimal<3.14>` >>>>> - `~Complex<0+1i>` >>>>> - `~Ratio<1/3>` >>>>> - `~Money<100 USD>` >>>>> - `~Geo<SRID=4326;POINT(30 -90)>` >>>>> etc >>>>> >>>>> basically whenever there's some piece of structured data with compact >>>>> string representation it'd >>>>> be a good candidate for a sigil. >>>>> >>>>> Notice, I have chosen the same delimiter, `<`, for all proposed >>>>> sigils. Different ones for >>>>> different sigils could be of course chosen as the "cannonical" >>>>> (returned from the Inspect >>>>> implementation.) >>>>> >>>>> Below I'd like to discuss some limitations of this proposal. >>>>> >>>>> Given we already have sigils that correspond to structs like `~D`, >>>>> `~T`, `~N`, `~U`, `~R`, should >>>>> we deprecate them in favour of `~Date`, `~Time`, `~NaiveDateTime`, >>>>> `~DateTime`, `~Regex`? I'd >>>>> arbitrarily say we **should not** and instead keep them as is. >>>>> (Personally I wouldn't mind using >>>>> all of these except for maybe `~NaiveDateTime` which is rather long.) >>>>> >>>>> The longest possible sigil name would be 249 letters (which along with >>>>> 6 letters in `sigil_` make >>>>> 255 characters which is the atom length limit). A shorter maximum name >>>>> length could be chosen. >>>>> >>>>> As mentioned in [2], we run into technical limitations when >>>>> implementing a ~MapSet sigil, given >>>>> sigils work on string and not the AST. This could be emulated with >>>>> some caveats [3]. I'd argue >>>>> that given single letter sigils have exactly the same problem, perhaps >>>>> it's not a deal-breaker, >>>>> just one of consequence of the original design. >>>>> >>>>> Given multi-letter sigils may (but of course don't have to) correspond >>>>> to module names, what about >>>>> modules with dots like `Date.Range` and `Version.Requirement`? This is >>>>> especially relevant for >>>>> user provided sigils, e.g. `~MyApp.Money`. Turns out it's very easy to >>>>> support these too, instead >>>>> of `def sigil_Date.Range` which would be a syntax error, we would do >>>>> `def >>>>> unquote(:"sigil_Date.Range")`. But then the other parts of the system >>>>> don't quite work either, >>>>> e.g. instead of `iex> h sigil_Date.Range` currently we would have to >>>>> do >>>>> `iex> h Kernel."sigil_Date.Range"`. For what it's worth it's not very >>>>> different than the `./2` >>>>> macro [4] which has similar caveats. In any case, as much as I'd >>>>> personally like to see >>>>> `~Date.Range` in particular, I concede we probably should stick to >>>>> just supporting letters for >>>>> now. >>>>> >>>>> Worth mentioning that sigils need to be manually imported into the >>>>> current scope (unless they are >>>>> already there by default, like the ones on Kernel). Thus, to use >>>>> ~Decimal, users would have to do: >>>>> `import Decimal, only: [sigil_Decimal: 2]`. A convenience like `import >>>>> Decimal, only: :sigils` >>>>> could be added in the future but it's not the topic of this proposal. >>>>> >>>>> Limitations aside, here's a proof-of-concept! >>>>> >>>>> https://github.com/elixir-lang/elixir/compare/master...wojtekmach:wm-long-sigil >>>>> >>>>> - [1] >>>>> https://groups.google.com/forum/#!topic/elixir-lang-core/C7-QgKKu1Mw, >>>>> - [2] >>>>> https://github.com/elixir-lang/elixir/pull/9640#issuecomment-564022856 >>>>> - [3] >>>>> https://gist.github.com/wojtekmach/7d4b5dc2f45a4708ce04d19e7c381360 >>>>> - [4] >>>>> https://github.com/elixir-lang/elixir/blob/v1.10.1/lib/elixir/lib/kernel/special_forms.ex#L492 >>>>> >>>>> -- >>>>> 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/E4F9858D-7019-4E2E-A463-9FEDAFA52B0E%40wojtekmach.pl >>>>> . >>>>> >>>> -- >>>> 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%2B8fjp8Y%2Bubx5vcq5m-Qwg3DgBsYp_ijqCsVB9vfP58tg%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2B8fjp8Y%2Bubx5vcq5m-Qwg3DgBsYp_ijqCsVB9vfP58tg%40mail.gmail.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/CAK-y3CthjZ0WW7S6p1QzOFfeE93XT2OrUOvT0%3DT12GZptghnTQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3CthjZ0WW7S6p1QzOFfeE93XT2OrUOvT0%3DT12GZptghnTQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> >> Regards, >> Bruce Tate >> CEO >> >> >> <https://bowtie.mailbutler.io/tracking/hit/f8218219-d2a8-4de4-9fef-1cdde6e723f6/c7c97460-016e-45fb-a4ab-0a70318c7b97> >> >> Groxio, LLC. >> 512.799.9366 >> [email protected] >> grox.io >> > -- > 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/b1e27881-902b-42c3-b347-6106535e9954%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/b1e27881-902b-42c3-b347-6106535e9954%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/CAGnRm4LPVkSdGUCJQ%2B2Vnj8rMy6ybfFg1NcOsyDdTaiP2eS4ZA%40mail.gmail.com.
