--
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 http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsubscri...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.
Both good points. In addition, I would also ideally like that LFE make binary the default representation for anything in double-quotes.
In other words, flip the default. This may impact some things like ++ or other dependencies on the with the VM, but most functions that take IoData will still be happy, and the few places where a list representation is desired can be explicitly bin_to_list'ed. I also admit that I don't fully understand all of this yet :-) so I don't know how practical the suggestion is.
Also, does LFE have reader macros? They will help further in making this a user/framework level choice instead of being built into the language. (And keep people like me from harassing you all :-)
--
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.
On Wed, Dec 3, 2014 at 11:57 AM, <anu...@cinova.co> wrote:Both good points. In addition, I would also ideally like that LFE make binary the default representation for anything in double-quotes.Huh, that's an interesting proposition. I like it.Robert, what do you think?In other words, flip the default. This may impact some things like ++ or other dependencies on the with the VM, but most functions that take IoData will still be happy, and the few places where a list representation is desired can be explicitly bin_to_list'ed. I also admit that I don't fully understand all of this yet :-) so I don't know how practical the suggestion is.Yeah, I'm not sure what the full implications would be, but perhaps a breaking-change would be acceptable as we move to the 1.x series for LFE :-)If we do that, though, I'd like to tack on a UX request: provide formatting for binary lists in the REPL similarly to what Erlang does in its shell. Instead of #B(int int int ...), display #B("...").Also, does LFE have reader macros? They will help further in making this a user/framework level choice instead of being built into the language. (And keep people like me from harassing you all :-)I don't believe so. I think Robert has discussed in the past some of the difficulties in doing that with LFE.
--
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 unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
Hi, I am on the road and have not had much time to respond. Here are some comments to your initial comments:
- Yes, the handling of errors in macros is not good and is on my list of things to do. My goal is to report what went wrong in the macro evaluation and the call macro call which caused the error.
- (macroexpand ...) in the shell by default only expands the pre-defined macros. To get it to expand other macros you need to add an extra argument which is the environment which contains macros you wish to use. In the shell $ENV is this environment so you can do (macroexpand ... $ENV) to expand all macros defined in the shell. Maybe this should be the default.
- I will take strings as lists later. I will just say that this is common in many functional languages and actually a very good way of representing strings, but different from what many are used to.
- What exactly are you after in the formatting. One problem I see with CL format is that is it contains too much junk, not just the kitchen sink but most of the the house as well.
--
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.
--
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 unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsub...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
A.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-erlang+unsubscri...@googlegroups.com.
To post to this group, send email to lisp-flavo...@googlegroups.com.
Visit this group at http://groups.google.com/group/lisp-flavoured-erlang.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.
#"utf8 binary"
#b("latin1 binary")
We can already input the second form as lists of positive integers are specially treated, though they are masked down to bytes so you can't use it for general unicode codepoints.
The question with strings is what do we mean by a latin1 string and a utf8 string? The string is just a list of integers and whether they are latin1 or unicode codepoints doesn't matter, in this respect they are the same. We never use utf8 encode strings, or at least never should, as there is no point. So we don't need any syntax for it
I know that OTP is slowly going towards having utf-8 strings and I think we should follow them. They are getting more BIFs which work with utf8 binaries and the module unicode.
#"utf8 binary"
#b("latin1 binary")I like this proposal.
We can already input the second form as lists of positive integers are specially treated, though they are masked down to bytes so you can't use it for general unicode codepoints.
The question with strings is what do we mean by a latin1 string and a utf8 string? The string is just a list of integers and whether they are latin1 or unicode codepoints doesn't matter, in this respect they are the same. We never use utf8 encode strings, or at least never should, as there is no point. So we don't need any syntax for itI am not sure I understand this fully. If I type in "å√å©" as a string in my source files (which are presumably utf8 encoded), is it automatically read as a list of unique code points, or is it a list of unsigned byte with the choice of how to interpret it left to the program.
For the binary string I think it is good, I thinking along those lines myself. I would extend it slightly with by having:
#"latin binary"
#u"utf8 binary"
#u8"utf8 binary"
#u16"utf16 binary"
#u32"utf32 binary"
The default is utf8 binary but the last three would allow you to be specific, and utf-16 and utf-32 are valid formats.
Just to be difficult: to flip the question do we actually need latin1 binary strings? We could always just go like this which mirrors erlang binary syntax:
#"utf8 binary"
#b("latin1 binary")
To unsubscribe from this group and stop receiving emails from it, send an email to lisp-flavoured-e...@googlegroups.com.