Allowing functions on primitives

[felixangell]

We were discussing this on the IRC, and me and sorta @kiljacken both agree that they could be really convenient. For instance in the string library, to compare a string the code is:

func compare(a: string, b: string) -> bool;

Which is used as follows:

compare(foo, bar);

This is okay, but it would be much cleaner to allow for having methods on primitive types for cleaner, flexible code:

func (a: string) compare(b: string) -> bool;

Which is used as:

foo.compare(bar);

There are some obvious flaws, most of which are relevant to the module system. Another thing I could picture being quite... strange is the following would technically be valid:

"foo".compare("bar");

Though we could disallow this behaviour with literals? I'm not sure about any other flaws, but if this feature is useful, then perhaps we could discuss either why it should not be implemented, or perhaps how we would resolve these flaws (without making huge changes to the compiler or language).

[SamTebbs33]

Surely allowing this on literals isn't a bad thing?

[felixangell]

Personally I think it's kind of inconsistent with the syntax, calling a function on literal just looks really strange. I'm not sure though, and I guess if others like it I can learn to live with it :smile:

[SamTebbs33]

I personally don't see any inconsistency. The function has to be called on some expression of type string, which "foo" is :)

[raoulvdberge]

It's possible in Java I think? :p

[felixangell]

@SamTebbs33 I mean inconsistency in the syntax more than the semantics of the language. In terms of the semantics its very consistent, though its kind of weird seeing a method being applied to a literal

[felixangell]

@raoulvdberge I think so, but that's due to their weird generic thing

[raoulvdberge]

It's weird indeed, but it's consistent at least.

[felixangell]

Yeah, I don't mind if everyone thinks we should allow for it.

[felixangell]

Paging @kiljacken & @MovingtoMars

[kiljacken]

LGTM, the local methods on primitives will be a bit of work, but probably not that bad.

[SamTebbs33]

@raoulvdberge @0xbadb002 Yeah it's possible in Java but not due to generics, it's just that because a string literal is an expression of type String, just like a string variable is of type String.

[felixangell]

@SamTebbs33 Ah yeah, I was thinking they had some weird wrapper for every primitive for their generics or something.

@kiljacken What do you think on allowing calls on literals? "foo".compare("bar")?

[kiljacken]

I said lgtm lol

On Wed, Mar 2, 2016, 17:34 Felix Angell notifications@github.com wrote:

@SamTebbs33 https://github.com/SamTebbs33 Ah yeah, I was thinking they had some weird wrapper for every primitive for their generics or something.

@kiljacken https://github.com/kiljacken What do you think on allowing calls on literals? "foo".compare("bar")?

— Reply to this email directly or view it on GitHub https://github.com/ark-lang/ark/issues/716#issuecomment-191316469.

[felixangell]

@kiljacken Oh, I thought that was generally on the concept :stuck_out_tongue:

[felixangell]

I would say this is approved then, leaving this open for implementation.

[MovingtoMars]

I think we should only have methods on the string type.

[kiljacken]

It's either for all or none of the primitives imo, the other will introduce even more special casing than just doing it for all the primitives.

[felixangell]

Agreed, otherwise it becomes a weird obscure feature that has one use case and probably no one will use other than us for the standard library.

[MovingtoMars]

I mean, we should define methods on string in the runtime, not allow defining arbitary methods on primitives (which would be hell for complexity. just use a normal function).