Lispifying erlang atoms

[Robert Virding]

One issue that crops up occasionally is if there is some way we could make typically Erlang atoms/names look more lispy. Why can't we write multiple-word-atoms instead of the Erlang camel_case or the even more horrendous OO inspired camelCase? Can't the parser/printer fix this for us?

Well yes, it could and it actually isn't that difficult. We fix the parser/printer so a '-' in an LFE atom becomes '_' in the Erlang and vice-versa. So we write/see in LFE handle-info <==> handle_info in Erlang. Easy. What if we actually *want* a '-' in the atom? Again easy, we just prefix it with a '\' we get handle\-info <==> 'handle-info' which is again pretty straight-forward and (almost) understandable. But now it starts getting difficult. What if we actually want to see '_'in the LFE atom? Well as it stands if we just write it in the LFE atom it will also end up in the Erlang atom but when it is printed we see the '-' instead so:

> 'with_underscore
with-underscore

which is not too good. We could always just flip them so '-'<==> '_' but that would be really confusing.

And the solution breaks the WYSIWYG. Hence we don't do anything and put up with it as it is.

Of course we can always write our LFE code so the names are nice and lispy. I have a plan to rename all the LFE modules with their functions and constants to have lispy names. This will help a bit. The only thing we can't do is have a '-' in an application name, it just doesn't work.

Robert

[Duncan McGreggor]

On Mon, Mar 14, 2016 at 9:05 PM, Robert Virding <rvir...@gmail.com> wrote:

One issue that crops up occasionally is if there is some way we could make typically Erlang atoms/names look more lispy. Why can't we write multiple-word-atoms instead of the Erlang camel_case or the even more horrendous OO inspired camelCase? Can't the parser/printer fix this for us?

Well yes, it could and it actually isn't that difficult. We fix the parser/printer so a '-' in an LFE atom becomes '_' in the Erlang and vice-versa. So we write/see in LFE handle-info <==> handle_info in Erlang. Easy. What if we actually *want* a '-' in the atom? Again easy, we just prefix it with a '\' we get handle\-info <==> 'handle-info' which is again pretty straight-forward and (almost) understandable. But now it starts getting difficult. What if we actually want to see '_'in the LFE atom? Well as it stands if we just write it in the LFE atom it will also end up in the Erlang atom but when it is printed we see the '-' instead so:

> 'with_underscore
with-underscore

which is not too good. We could always just flip them so '-'<==> '_' but that would be really confusing.

And the solution breaks the WYSIWYG. Hence we don't do anything and put up with it as it is.

Yeah, I've wrestled with this over and over -- should we or shouldn't we? And I always end up where you said: don't break WYSIWYG.

But I wrap the heck out of things :-) (automatically, of course)

I think my thoughts are as follows:

- encourage LFE devs to use proper Lisp style when writing LFE; use Erlang style when writing Erlang

- if Erlangers want to use LFE libs in their code, they'll simply have to deal with quoting our atoms (unless you can nicely fit mods and funcs into single words)

- don't do any behind-the-scenes hacking to make function calls do character-level conversions

- instead, if you want to call an Erlang function and have it look Lispy, write (or generate) a function that wraps the Erlang one (nothing gets changed, and it's still WYSIWYG)

 

Of course we can always write our LFE code so the names are nice and lispy.

:-)
 

I have a plan to rename all the LFE modules with their functions and constants to have lispy names.

Yay! I've been wanting that from the very first day I started using LFE. Is this going in LFE 1.0??? :-)))

 

This will help a bit. The only thing we can't do is have a '-' in an application name, it just doesn't work.

Yeah, that one bit me pretty hard for a long time. I think that's how we discovered it ... it's too bad that Erlang's not flexible on that one; other than that, a good job has been done to allow for all sorts of quoted atoms in Erlang. Makes it nice for us :-)

d

 

Robert

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at https://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

[Robert Virding]

On Tuesday, 15 March 2016 03:21:57 UTC+1, Duncan McGreggor wrote:

 

I have a plan to rename all the LFE modules with their functions and constants to have lispy names.

Yay! I've been wanting that from the very first day I started using LFE. Is this going in LFE 1.0??? :-)))

Nope, no more stuff in 1.0 except bug-fixes. Otherwise there will never be a 1.0. "Jag skall bara ..." :-)

Robert

[Duncan McGreggor]

Ohhhh, alright ;-)

I can't wait for 1.1 now, though!

d

[H Durer]

2016-03-15 2:05 GMT+00:00 Robert Virding <rvir...@gmail.com>:

One issue that crops up occasionally is if there is some way we could make typically Erlang atoms/names look more lispy. Why can't we write multiple-word-atoms instead of the Erlang camel_case or the even more horrendous OO inspired camelCase? Can't the parser/printer fix this for us?

Well yes, it could and it actually isn't that difficult. We fix the parser/printer so a '-' in an LFE atom becomes '_' in the Erlang and vice-versa. So we write/see in LFE handle-info <==> handle_info in Erlang. Easy. What if we actually *want* a '-' in the atom? Again easy, we just prefix it with a '\' we get handle\-info <==> 'handle-info' which is again pretty straight-forward and (almost) understandable. But now it starts getting difficult. What if we actually want to see '_'in the LFE atom? Well as it stands if we just write it in the LFE atom it will also end up in the Erlang atom but when it is printed we see the '-' instead so:

> 'with_underscore
with-underscore

which is not too good. We could always just flip them so '-'<==> '_' but that would be really confusing.

And the solution breaks the WYSIWYG. Hence we don't do anything and put up with it as it is.

I don't think the gain in readability is worth the cost of greater distance to the Erlang workd and having to do the mental translation when going back to other beam based environments.

 

Of course we can always write our LFE code so the names are nice and lispy. I have a plan to rename all the LFE modules with their functions and constants to have lispy names. This will help a bit. The only thing we can't do is have a '-' in an application name, it just doesn't work.

You state that you'll do this after 1.0.  Does that mean that we don't consider the LFE modulex part of the public LFE interface or will that be done in a 2.0 release when we can break backwards compatibility again?

  Holger

[Eric Bailey]

+1 to all this. I've actually had moderate success with hyphens in LFE app names, via some code path hacks. I've often considered submitting a patch to OTP...

Re: breaking changes. I think either 2.0 or providing backward compatible _ aliases in a 1.1 would be fine. We could mention in 1.1 how the _ variants are deprecated and will be removed.

Eric

[Robert Virding]

I will preserve backward compatibility for the old _ versions of module and function names after the new - versions have been introduced. It will kept simple by just providing interface modules with the old names.

Robert

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
To post to this group, send email to lisp-flavoured-erlang@googlegroups.com.

[Feng Hou]

Hi Robert,

Would you implement this feature before 1.0 release?

 (import (prefix mod mod-prefix))              - NYI

Regards,

Feng

[Robert Virding]

I hadn't intended to do this one now. I am also dubious to its value. And to make matters worse if I do it I just might call it

  (alias mod mod-prefix)

instead. To be honest the whole import thing is a bit off as it allows you to hide the fact that you are calling functions in other modules, which is not really a good thing. Maybe deprecating it and replacing it with an alias which allows you to give modules short names locally is a better thing.

Are you interested in using it?

Robert

[Feng Hou]

Yes, I'd much prefer this than (import (from ...) (rename ...)). Allowing short alias but module qualified functions will be great for leveraging elixir modules as they typically have long module names.

Use case exmaple, (alias 'Elixer.Stream exstream)

This can even hot reload module if the alias mechinsim expands short name at compile time, correct?

Congratulation on 1.0 release!!!

Regards,

Feng

[Duncan McGreggor]

+1 on the (alias ...) feature.

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.

[Robert Virding]

I will add alias and phase out import. No, this doesn't actually go out and check the module in any way, the inter-module calls will be the standard intermodule calls. It will just allow you to use short module names.

Robert

[Feng Hou]

Hi Robert,

This is great. To clarify, I wasn't expecting (alias ...) go out and check the module in any way. 

Just curious if I do

(alias 'Elixir.long.name.module exm)

then load new underlaying module in lfe repl like

(l 'Elixir.long.modname)

whether aliased call sites (exm:...) will pick up new module code or not.

Either way, lfe is awesome!!!

Regards,

Feng

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.

To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at https://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Lisp Flavoured Erlang" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.

[TR NS]

Could underscore translate to double underscore?

[Robert Virding]

How do you mean? In which direction? I think the problem is that an underscore does not feel lispy so my original question was if we could in LFE see the underscore in an erlang atom as a -. This is technically not a problem as it would be enough to change the LFE parser and printer. My problem with it is that you so longer see what you really have.

[TR NS]

On Friday, October 7, 2016 at 8:56:21 AM UTC-4, Robert Virding wrote:How do you mean? In which direction? I think the problem is that an underscore does not feel lispy so my original question was if we could in LFE see the underscore in an erlang atom as a -. This is technically not a problem as it would be enough to change the LFE parser and printer. My problem with it is that you so longer see what you really have.

> What if we actually want to see '_'in the LFE atom? Well as it stands if we just write it in the LFE atom it will also end up in the Erlang atom but when it is printed we see the

'-' instead so:

Maybe I misunderstood, but I just thought that it could "end up in the Erlang atom" as a double underscore. Then it doesn't have to translate back as "-".

[Robert Virding]

Sorry, I still don't quite get what you mean. Could you explicitly show me how the LFE atom and erlang would look?

Robert

[TR NS]

On Saturday, October 8, 2016 at 8:32:39 AM UTC-4, Robert Virding wrote:

Sorry, I still don't quite get what you mean. Could you explicitly show me how the LFE atom and erlang would look?

Robert

Sure. Say from the Erlang you get `atoms_rule`, which in LFE becomes `atoms-rule`, nice and lispy. And in LFE `atoms-rule` would translate back to `atoms_rule`. But if you need a `_` in the LFE atom, e.g. `erlangy_atom`, we can't just translate that to Erlang as is, b/c it would come back to LFE as `erlangy-atom`. So instead `erlangy_atom` can translate to Erlang as `erlangy__atom`, and LFE can see the two underscores and know to translate it back to LFE as just one.



[Robert Virding]

That would definitely work. The trouble is that all normal erlang atoms only have single underscores which we would see with a '-' and our LFE erlangy atoms would look strange in erlang. So I still think that if we want to do this then the '-' in an LFE should be translated to a straight '_' in the actual atom. We could quote it with a '\' if we actually wanted a '-' in the atom.

foo-bar  ==> foo_bar
foo\-bar ==> 'foo-bar'