character names not lispy enough

[ds26gte]

#\newline returns the value for #\n rather than for the newline character.  Analogous things happen for #\space #\tab #\return etc.

How does one refer to these "non-graphic" characters in LFE (other than memorizing their integer codes)?  Vanilla Erlang does offer a way with $\n $\s $\t $\r which are different from $n $s $t $r. 

The Lisp equivalents of these would be #\newline #\space #\tab #\return.  There are some more too (formfeed?).

Thanks,

--d

[rvirding]

Yes, there is some work to do here, the question is what? Now LFE basically meant to have the same conventions as vanilla erlang but with a different prefix to characters. It works in strings where you can write "line 1\nline 2". But I also see that it doesn't quite work with character constants where you can write #\n as in CL to get an 'n' but you can't get one newline (linefeed) character.

I have looked at the CL book that says VERY little about character and string syntax. For example nothing at all about quoting in characters or strings, just a few predefined constants for characters. None of the other lisp books I have say more, apparently characters and strings aren't important. Scheme is no better.

So i don't really know what to do. And I would prefer to have something worked out properly before adding more hacks to what we got. So I am open to suggestion about a char/string syntax which can handle at least as much as vanilla erlang.

Robert

[ds26gte]

I guess you want the representation for a character literal to be reusable within a string with simply the prefix lopped off.  The Lisp #\ prefix is not analogous to vanilla Erlang $: Lisp tends to use 

#\c to stand for c (for any single, "graphic" character c, where "graphic" roughly means it makes a black mark against white paper).

For space and non-graphic characters like newline, tab etc Lisp uses 

#\chardescription (where chardescription is a word of more than one character, like: Newline Space Rubout Page Tab Backspace Return Linefeed).  This list I got from http://www.lispworks.com/documentation/HyperSpec/Body/13_ag.htm.

(For some reason, Lisp treats Space as a graphic char but also gives it a representation more in tune with the non-graphics.  Thus, it can be represented as both #\   and #\space.)

I guess trying to emulate all this in LFE will reduce interop with vanilla Erlang?  In which case, I would agree it isn't worth the candle.  My concern is that this would mean the user has to be aware of the numeric values of Newline Space and the like in order to do character manipulation with non-graphic characters.  This is probably less of a problem these days now that ASCII does reign supreme by now for the first 128 characters, so at least we don't have to worry about the numeric values being incompatible across hosts.

I am ok with the status quo.

--dorai

p.s.  I did try to see if, following your #\ $ equivalence, #\\n #\\t in LFE (i.e. with TWO backslashes) corresponded to Vanilla E's $\n $\t.  They are both read as #\\, just like #\newline is read as #\n.

So, LFE #\ isn't really a strict transliteration of Vanilla $. 

[Robert Virding]

After your mail I tried for myself #\\n and found it returned '\'. :-)

One thing which I think would be reasonable would be to fix #\ so that
it can handle the the extra backquote and return something sensible.
Like the $ in vanilla Erlang. So #\\n will return 10. We should
probably fix its current strangeness of always only grabbing only
*one* character (or perhaps *two* with the \ fix) and leaving the rest
to the next token. So writing (1 #\23) results in the list (1 50 3).
It would make more sense for it to grab everything up-to a delimiter
and parse that. $ in vanilla behaves the same way as #\ currently does
but will usually generate a syntactic error because of a missing
separator, which is often unnecessary in CL so it looks funny.

When I was looking through the scanner I noticed that some of the
rules are taken from scheme and not CL. I will fix that at the same
time. Another property is that the CL parser is described in parsing
*one* step while I do the parsing in to steps, first tokenisation and
then parsing. This make it easier, especially for using tools, but it
means that it is very difficult to get it to work in exactly the same
way. For example CL's nested #| ... |# block quotes you mentioned
earlier.

For the time being I will cleanup I what we have now but leave it as it is.

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
> http://groups.google.com/group/lisp-flavoured-erlang?hl=en-US.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Duncan McGreggor]

I've bumped into this a bunch since I first started using LFE. While it's a bummer to have to type ASCII codes, it's not really a big deal ...

However, while working on http://lfex.github.io/hyperpolyglot/, I'm putting myself into the shoes of new users, and I'd now vote for coming up with a sensible, dev-friendly solution to this. At the very least, it would be nice if the following returned the ASCII codes for the given control characters:

#\\b #\\t #\\n #\\v #\\f #\\r #\\e #\\s #\\d

For pudding, it would be fantastic to have something like this, too:

#\space #\newline #\backspace #\tab #\linefeed #\page #\return #\rubout

Understanding how that would require a lot of additional special casing in the parser, maybe something like this would be manageable:

#\(space) #\(newline) #\(backspace) #\(tab) #\(linefeed) #\(page) #\(return) #\(rubout)

I'm definitely *not* a fan of CL's use of capitalisation for these...

Do you think this is this something we could get fixed up for a 1.0 release?

d

P.S. Yes, you may call me the mail list thread necromancer ...

> email to lisp-flavoured-erlang+unsub...@googlegroups.com.

[Adam Krupicka]

> P.S. Yes, you may call me the mail list thread necromancer ...

Be that as it may be, having more pudding would be a wonderful thing :)

> #\space #\newline #\backspace #\tab #\linefeed #\page #\return
> #\rubout

This would be fantastic to have indeed, though I am not a fan of the
parenthesised version. But I think #\\n and others works nice as well.


Adam