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.
