I use a sigil in a project with lots of plain SQL queries to mark them for
the editor to syntax highlight:
~q"SELECT * FROM users WHERE id = 42"
This still returns the string unchanged, but the edit can change the
highlighting rule inside the double quotes to SQL which makes these files
easier to work with. Obviously, the queries are more complicated than that,
and often presented in a heredoc.
LB
On Mon, 17 Feb 2020 at 23:49, Bruce Tate <br...@grox.io> wrote:
> 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
> <https://groups.google.com/d/msgid/elixir-lang-core/CAFXvW-7k9UQ1aRVNTUte%2B58HC19sr0cVuvLnFamEQetRSVT32Q%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/CAA2aWVTcZ3%3D3EVucmrpF8YjqBnBLxDgQQHUUc2NspeGQYzPPNA%40mail.gmail.com.
