Added name and keyword functions to core

[schuster-rainer]

Added to hy.core.language. Both functions will replace _ with - in what ever it is thrown at. If it isn't something stringy they will try to get the name magic. And fall back to just convert to string if not possible

[paultag]

Pretty neat idea. Not sure where I am right now on this - it looks like we should consider exposing some of the internals for this -- but neat!

Do you have some awesome code I can meditate on with this? I usually resort to macros when I need to dynamically create symbols; dynamically creating them in functions sounds neat :)

[paultag]

Nice work, @schuster-rainer !

[schuster-rainer]

Some code to meditate on ... I used this functions in clojure for reading a csv. But anything dynamic doing IO is the target of this function. Another approach is to create a shim wrapper for APIs with strings but using keywords. Or creating more abstract functions and not using strings for parameters where I only pass them on the lower level, existing APIs but keywords, or the other way round... To create keywords, where an Python API (with dicts or what ever you can imagine of) is returned but I wanna have a more clojuresque approach. I like using keywords over strings as I can use them as function to the map for the lookup. I like keywords in general more than using strings. So I think there are even more use cases. As I always try yo use a function first this is my approach. Obviously no macro needed (maybe for performance optimisation). I'm open for suggestions to massage and improve the code.

[schuster-rainer]

As this is only the first draft feel free to make suggestions for improvement. I only added the use cases obvious to me.

[paultag]

@olasd think we can find a way to unify this with the lexer internals?

[paultag]

I really needed this the other day, I'm in favor :)

Only thing I'm not sure about is the name function name - seems like that's commonly - other ideas for function names, @hylang/core ?

[tuturto]

I like keywords for the very same reason @schuster-rainer explained. After playing a bit with name and keyword in REPL, I can see how this is useful. name is very generic name though, keyword-name would not be so generic, but it's already a mouthful.

[agentultra]

IMO this doesn't need HYIFY in order to work (and may be confusing ultimately). Consider the CL alternative:

CL-USER> (make-keyword (name)
           (values (intern name "KEYWORD")))
CL-USER> (make-keyword "foo_barest bar")
:|foo_barest bar|

The function to consider is INTERN which retrieves a name from the current package or creates one if it doesn't exist (the optional parameter we pass is a package name, which by CL convention is the package where keyword symbols are interned). Notice how it doesn't manipulate the contents of name.

I think the same applies here... there's no reason we cannot accept an arbitrary string and if the user wants to manipulate it before creating the keyword symbol they can do so on their own before passing it to KEYWORD.

I don't agree that the name need be any more specific. It is a constructor for a Hy type and is not far from the Pythonic convention of lower-cased names for constructors of types (ie: int(), str(), float(), etc)

[agentultra]

Except NAME... should be KEYWORD-NAME or some such as it applies to a specific object.

[algernon]

While working on HumpY, I really wanted name, and thought this got merged already. Since it didn't, here's a bump to @hylang/core! Can we have something like these for 0.10.1 (#622)?

[schuster-rainer]

Anything I should change in this patch to get accepted? Or will you derive or completely replace my work by something already existing? Would like to have this name and keyword thing in.

I disagree on KEYWORD-NAME, really should be name. Maybe I have to add more code the implementation to satisfy the specification.

https://clojuredocs.org/clojure_core/clojure.core/name
https://clojuredocs.org/clojure_core/clojure.core/keyword

I know that name already exists in python. But basically that should be the names for the functions.

[paultag]

Hrurm.

What's consensus here? I'm really afraid of a common name like "name" causing trouble to users.

We need this functionality.

What are our options here?

[algernon]

I think both name and keyword are fine. name could apply to all kinds of stuff (symbols, keywords, functions, etc), and do the right thing. There was no question about keyword, was there?

[algernon]

In other words, +1 for both functions from me, as is.

What kind of trouble would name cause? As far as I see, it does not exist yet, neither in python, nor in hy... (and applies to more than just keywords).

[schuster-rainer]

Oh, you are right ... Don't know why I'm confusing everyone. For me it absolutely makes sense, as functions and objects already have a name attribute, which I'm accessing in the implementation. It's more than need for the purpose I intended, but I wanted a pythonic approach, so when im passing in the a function or object there should be some meaningful result. Its a generic function that works on every type of thing you are throwing at it. Another good thing I love in clojure. The generic functions for every type of data structure. I think keyword-name would limit its use to only keywords. I don't really care about its data type (fact to the dynamic nature of what we are using, luckily). What I'm really interessted in is the name of "some thing". Don't know what it is. I may be in a generic algorythm, function. So testing/sensing would always apply. Why not the put it into a function that is doing it for me by convention? Less typing, less code, less errors.

Regarding make-keyword:
Thats exactly the reason why I created the functions. using make-keyword is more verbose ... therefore error prone, and tedious if I use this keyword all the time. You may not run into this problem, but most of the time I'm exclusively using maps and lists as my datastructure, no classes at all.
Being explicit all the time is good for configuration. For behaviour I'm not so sure. So while I'm used to _ in python I don't like it. The - does an excellent job. So how would you call into python function which expects an underscored version of a war, but want to use keywords with '-' of course. Imagine of using the keyword :my-special-keyword all the time in your code...

That's was my intention for using this 2 functions. So you may disagree and. That's also fine. I think we should discuss the semantics. Whether I got this right. I don't see any problem in using name. What would be confusing to a user when using name? Maybe its now clearer what the intention was after my explanation.

Further considerations, ideas or suggestions?

[schuster-rainer]

And as I'm not reinventing the wheel here, similar stuff for java interop, as you already know. Just to mention for everyones reference.

[paultag]

It's not that I disagree that there's precedent and that it makes sense,
it's that name is a really common variable name, and I could see people
tripping over that once in a while.

I guess that's not much different than using reduce or hash or id as
a variable name.

On Thu, Jul 31, 2014 at 10:20 AM, Rainer Schuster [email protected]
wrote:

And as I'm not reinventing the wheel here, similar stuff for java interop,
as you already know. Just to mention for everyones reference.

—
Reply to this email directly or view it on GitHub
#525 (comment).

:wq

[schuster-rainer]

So consensus over the whole thread right now is keyword. The discussion point as I understand it is 'name' vs. 'keyword-name'. Maybe @agentultra didn't read the implementation carefully, as the code should be really generic, as he supposed KEYWORD-NAME. I'm fine expanding the implementation to match the needed criteria for being name a first class citizen.

[paultag]

keyword is great :)

On Thu, Jul 31, 2014 at 10:23 AM, Rainer Schuster [email protected]
wrote:

So consensus over the whole thread right now is keyword. The discussion
point as I understand it is 'name' vs. 'keyword-name'. Maybe @agentultra
https://github.com/agentultra didn't read the implementation carefully,
as the code should be really generic, as he supposed KEYWORD-NAME. I'm fine
expanding the implementation to match the needed criteria for being name a
first class citizen.

—
Reply to this email directly or view it on GitHub
#525 (comment).

:wq

[schuster-rainer]

oh you mean due to conflicts shadowing a variable called name ...

[paultag]

That's right, everything else is amazing.

On Thu, Jul 31, 2014 at 10:25 AM, Rainer Schuster [email protected]
wrote:

oh you mean due to conflicts shadowing a variable called name ...

—
Reply to this email directly or view it on GitHub
#525 (comment).

:wq

[schuster-rainer]

So I guess you would also disagree with key as a function name. I wanted to stay to the clojure impl. But lets consider to just use something else ... how about 'name-of'. Or another plain postfix. 'name->' as name attribute accessor. just 'name-' ... Maybe you get a better idea. I still think name is the most appropriate... but I'm fine using some short postfix... which adds to its nature of being a function which returns the name 'name'. What I dislike, but would be better than just using KEYWORD-NAME is 'get-name' ... something else you would consider usefull?

[paultag]

Let's get this in the next release. This is a blocker for #622

[tianon]

Any chance we could get a little blurb in the docs about what this is and how to use it? (Note, I'm just an interested user here, not Hy core or anything. This looks neat!)

[tianon]

Also (and coming as a real green Hy user, so keep my comments in perspective here), I don't think it's at all a problem that if people use a non-descriptive variable like name that it shadows this. This problem already exists for other bits of the language, and this is just a case where you can't both use such a bad name, and use this cool new core function, from my point of view. 👍

[paultag]

We can always check against 'foo, which is technically slightly more correct; but this is fine :)

[paultag]

Let's roll with these names, in that case. Seems fine. Let's go with it.

@hylang/core Let's get some eyes on this. Looks good to me. I'll ACK it in a second when I can sit down with it.

[berkerpeksag]

We could move this to hy/models/keyword.py (or to a better location)

[berkerpeksag]

LGTM. The patch lacks documentation, but that can be done in a separate pull request.

[rcarmo]

bump This is holding up 0.10.1, right? I want to use (defmain) :)

[paultag]

LGTM

[paultag]

Yikes merge conflict. Can someone do this merge? I'm in time debt D:

[paultag]

hy/core/language.hy and tests/native_tests/language.hy both seem like straightforward changes