[Proposal] Create a sigil_P for PIDs, and use it for inspection

[Kelvin Raffael Stinghen]

I find very useful sometimes to copy and paste the item from a result of a query for example, and as for today, PID's are printed like `#PID<0.106.0>`, my proposal would be to add a `sigil_P` to `Kernel` module, so we could use `~P[0.106.0]` (pretty much like `Date`s are today), and also put that as the result for `Inspect.PID.inspect/2`.

If the proposal gets approved, I would be more than happy to send a PR for it.

Thanks!

[Kelvin Raffael Stinghen]

Maybe also, instead of using `[]` as delimiters we could use `<>`, so it’s close to how it was before and also close to how erlang represent them on `:erlang.pid_to_list`.

Best,
Kelvin Stinghen
kelvin....@me.com

--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/0c7807e6-d832-4853-8a70-5999789ef380%40googlegroups.com.

[Allen Madsen]

I'm +1 for this.

Allen Madsen
http://www.allenmadsen.com

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/DFC222C8-A8F3-4D4F-A502-AB2FFD88D53A%40gmail.com.

[Sven Gehring]

Definitely support this! Sure there's c.pid/3 but it would be awesome, if pid's were copy-paste-able

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3Cu2C_vfmyWU13rAsHM3xy-KEBTUd-ey78Uj0JdC-3xg1Q%40mail.gmail.com.

[Andrea Leopardi]

We would have to introduce a sigil for refs as well. Note that this is primarily for the shell tough, so Im not sure it's an addition that we want in the language.

Andrea

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3Cu2C_vfmyWU13rAsHM3xy-KEBTUd-ey78Uj0JdC-3xg1Q%40mail.gmail.com.

--

Andrea Leopardi

an.le...@gmail.com

[Wojtek Mach]

In general I'm keen on adding inspect implementations (and corresponding sigils) and have proposed a few myself. (e.g. ~U was accepted and #URI<> wasn't.)

**Personally** I didn't have a need for a pid literal often enough. The times I did, it was pretty much always in an IEx session where I could do: `pid("0.106.0")` which seemed good enough.

Given there can be only 26 possible sigils (we can "overwrite" them of course but still), it's hard to draw a line. Why is there ~P for PID but not for Port? We can't have one for Ref because ~R is for Regex.

But I totally get where your are coming from with this and I've been there so to speak :)

[José Valim]

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.

Sigils have served us well so far but we only have 26 of them. Doing both ~P (PID) and ~R (Ref) would reveal a conflict with regex. There is also a conflict between ~U (for UTC DateTime) and URIs (which could be sigil based).

We could of course introduce two or three letter sigils (or remove the restriction altogether), but we may want to think closely if that's the direction we want to go and how we would want to handle the casing in said situations: should it all be uppercase or all lowercase? or only the first letter matters?

José Valim

www.plataformatec.com.br

Founder and Director of R&D

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2B%2B%3DKjAuxjvaMiGArGpf4KvCNcvmXcOoBPfBo6HbxqG6mw%40mail.gmail.com.

[Wojtek Mach]

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 :))

[Kelvin Raffael Stinghen]

> 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
kelvin....@me.com

--
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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/c7d345e5-b1df-4014-b683-ff499a1fada5%40googlegroups.com.

[José Valim]

> 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

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/6B80ED07-814E-4FA0-8E5D-FB846AC5983C%40gmail.com.

[Kelvin Raffael Stinghen]

> So I really don't think this feature would be usable with sigils.

Yeah, sure, I was just trying to think of examples of the top of my head, I’m sure it would still have a lot of limitations, but I think it would be worth the try.

> No, they are enforced by the language.

I see. I vote for only caring for the first letter then.

> 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]]

Why not actually using sigils for that? With multi letter sigils we could do that. Would you want to automatically import that? If that’s the case, maybe a better syntax for the feature would be something like: `%URI”https://elixir-lang.org”`, so that would delegate the construction to a `from_string` function (or macro) on the module for example. 

Anyway, I like your idea too, but as you mentioned, that would not address my concern, as PIDs are not structs, so I think that multi letter sigils would be the way to go for that, since it looks like adding one more one letter sigil for it will not get accepted.

Best,
Kelvin Stinghen
kelvin....@me.com

[Ben Olive]

I really like the idea of a syntax that delegates to a module! 

That would make a pid something like `%Process<0.55.0>` or `%Process.Pid<0.55.0>` which is't a big stretch from the current `#PID<0.55.0>`

--
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-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/6ACCD0A4-30C6-4E47-852F-FC4A16EB5CB3%40gmail.com.

[Ben Olive]

Thinking about it more, sigils already support `{}` as delimiters, so using `%` could conflict with struct creation. 

I don't think it could be `~` either since that would be ambiguous between sigils and single character atoms.

[OvermindDL1]

I've always thought that structs could use a 'constructor' format like `%URI("https://elixirforums.com/")`, and it would just be rewritten in code to be `URI.create("https://elixirforums.com/")` *with* auto-requiring of it so macro's work out-right (though that could of course be optional in an actual spec perhaps).  I could imagine a Pid being like `%Process.Pid(0, 55, 0)` or so.

However, I'm not sure it really gains much to the language. Sure I don't like the `#...` inspections of things like `PID`'s, but I still wouldn't add the above.  Instead I'd standardize on inspections being a representative object, so PID's instead of printing like `#PID<...>` they should print 'as' the fully construction as however they should be constructed, even if it is an IEX only style constructor.

On Friday, October 25, 2019 at 7:56:57 AM UTC-6, Ben Olive wrote:

I really like the idea of a syntax that delegates to a module! 

That would make a pid something like `%Process<0.55.0>` or `%Process.Pid<0.55.0>` which is't a big stretch from the current `#PID<0.55.0>`

On Fri, Oct 25, 2019 at 8:49 AM Kelvin Raffael Stinghen <kelvin....@gmail.com> wrote:

> So I really don't think this feature would be usable with sigils.

Yeah, sure, I was just trying to think of examples of the top of my head, I’m sure it would still have a lot of limitations, but I think it would be worth the try.

> No, they are enforced by the language.

I see. I vote for only caring for the first letter then.

> 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]]

Why not actually using sigils for that? With multi letter sigils we could do that. Would you want to automatically import that? If that’s the case, maybe a better syntax for the feature would be something like: `%URI”https://elixir-lang.org”`, so that would delegate the construction to a `from_string` function (or macro) on the module for example. 

Anyway, I like your idea too, but as you mentioned, that would not address my concern, as PIDs are not structs, so I think that multi letter sigils would be the way to go for that, since it looks like adding one more one letter sigil for it will not get accepted.

Best,
Kelvin Stinghen
kelvin....@me.com

On Oct 25, 2019, at 04:00, José Valim <jose...@plataformatec.com.br> wrote:

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.

--
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-l...@googlegroups.com.

[Wojtek Mach]

For anyone interested I published a proof-of-concept for this here: https://github.com/elixir-lang/elixir/pull/9640