I use sigils as sugar for clearly representing concepts that are awkward with regular Elixir syntax.
A few examples. String escaping: html = ~s(<p id="note-quotation-mark">) -> "<p id=\"note-quotation-mark\">" The result is a string that can easily include quotes on one line, making string escaping much easier and less error prone. A list of words: iex(21)> ~w[one two three] -> ["one", "two", "three"] The result is a list that's much easier to read, especially long one. Or atoms: ~w[one two three]a -> [:one, :two, :three] The result is much less syntax between words, smoothing out the experience of reading a long list of atoms. Or regular expressions: ~r<\\//> -> ~r/\\\/\// To me this proposal fits right in. It's not about saving characters; it's about constructs that aid in readability and reduce errors. -bt On Sun, Feb 16, 2020 at 3:00 PM Stefan Chrobot <ste...@chrobot.io> wrote: > What is the problem that these new sigils attempt to solve? They're just a > few characters away from .parse/1. Is the intention here to change the > implementation of the inspect protocol, like so: > > iex> Version.parse!("0.0.1") > ~Version<0.0.1> > > If yes, then it looks like a great change. Otherwise I don't see the > benefits. > > Best, > > Stefan > > > niedz., 16 lut 2020 o 16:07 José Valim <jose.va...@dashbit.co> napisał(a): > >> 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 <fertap...@gmail.com> >> 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 <allen.c.mad...@gmail.com> >>>> 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 <jose.va...@dashbit.co> >>>>> 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 <woj...@wojtekmach.pl> >>>>>> 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 elixir-lang-core+unsubscr...@googlegroups.com. >>>>>>> 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 elixir-lang-core+unsubscr...@googlegroups.com. >>>>>> 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 elixir-lang-core+unsubscr...@googlegroups.com. >>>>> 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 >>>> br...@grox.io >>>> 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 elixir-lang-core+unsubscr...@googlegroups.com. >>> 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 elixir-lang-core+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LPVkSdGUCJQ%2B2Vnj8rMy6ybfFg1NcOsyDdTaiP2eS4ZA%40mail.gmail.com >> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4LPVkSdGUCJQ%2B2Vnj8rMy6ybfFg1NcOsyDdTaiP2eS4ZA%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 elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CACzMe7YE5SGrKhALD3A7Qm-%2BYDAOvrRbWakcMwNNwCZux54o_w%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CACzMe7YE5SGrKhALD3A7Qm-%2BYDAOvrRbWakcMwNNwCZux54o_w%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 br...@grox.io 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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAFXvW-7k9UQ1aRVNTUte%2B58HC19sr0cVuvLnFamEQetRSVT32Q%40mail.gmail.com.