[erlang-questions] atoms with newlines
Valentin Micic
valentin@REDACTED
Thu Feb 27 11:09:57 CET 2014
On 27 Feb 2014, at 4:02 AM, Richard A. O'Keefe wrote:
>
> On 27/02/2014, at 1:33 PM, Valentin Micic wrote:
>>
>> I do see your point (and feel your frustration), however, you are using a logical fallacy to reinforce your argument as you making an appeal to authority -- others are using it, thus it has to be right.
>
> You have completely misunderstood.
Suppose you're right, and I did misunderstand you. Where would that leave this debate?
I can go ahead and reply "bullet-by-bullet" (arguably from a position of someone that made a wrong conclusion due to the misunderstanding of the original argument), however, considering that there are more "typing to be done" around issues with no direct reference to the original argument, this will only take us further away from the topic.
Alternatively, I may have (or at least believe that I have) understood you just fine, which may compel me to assert my position vis-a-vis your clarifications, but that will just as well drawn the original topic.
In my view, the moment one has to "clarify" what he/she has said, the nature of debate is changing and I sincerely apologize for making statements that compelled you to clarify your position (as you've done below by shouting NEVER, BECAUSE, THEREFORE and AND).
My (I desire) last word on the original topic is that the atom construction rules as implemented in Erlang make sense to me, and since no-one else have complained about it (*), this may lead me to believe that this rule made sense to other people as well.
If this assumption is correct, it would be reasonable to expect that some of the people may have even taken an advantage of this behaviour.
And if that is the case, how would change that you're suggesting affect them?(**)
With this in mind I've made my suggestion, to which you've objected to on two counts, etc. (see, now I have to clarify my position).
Kind regards
V/
(*) I may be wrong, but I cannot recall seeing a similar complaint
(**) Contrast that to possibly one program (possibly not in a production at this point) that you may have to change to solve your problem. Now, that would be a very pragmatic thing to do.
> In this debate,
> I have *NEVER* argued that any treatment of \n is *RIGHT* and
> I have *NEVER* appealed to authority.
>
> I am making a purely PRAGMATIC argument:
>
> BECAUSE
> We can already insert a newline character into the
> value of a quoted atom or quoted string using
> either a bare newline or \n or \^<newline>
> THEREFORE
> Having \<newline> do so as well does not add
> much to utility. (It's not *WRONG*, just *USELESS*.)
>
> BECAUSE
> Many Erlang programmers have experience in other languages
> and those other languages use \<newline> for a seamless
> join
> AND
> The present behaviour is not documented in the
> reference manual so that those programmers will not have
> their expectations corrected by documentation
> THEREFORE
> many Erlang programmers will be SURPRISED by the actual
> behaviour of Erlang.
>
> BECAUSE
> The backslash newline combination is silently accepted
> by the compiler
> THEREFORE
> The unpleasant surprise will be when the code is tested,
> if then, not when the code is edited or compiled.
>
> Contrast Erlang with Common Lisp here.
> I have never argued that \<newline> should vanish in
> Common Lisp, because Common Lisp has documented the
> behaviour of \ very clearly. (In section 2.1.4.6 and
> 2.1.4.5 and 2.4.5.) It doesn't matter how many other
> languages do what; Common Lisp is explicit about what
> *IT* does.
>
> Oh, and Common Lisp doesn't _need_ string pasting because
> it has #.(concatenate "foo" "bar") .
>
> BECAUSE
> It is useful to be able to write a string or a quoted
> atom that extends over multiple lines without thereby
> being forced to include newline characters in the
> value denoted
> THEREFORE
> it would be useful to adopt some convention such as
> C's to allow unwanted newlines to be elided.
>
> This is not an appeal to AUTHORITY, it is an appeal to
> UTILITY.
>
> It's worth pointing out here that (O'CAML, F#) and the
> C family do slightly different things. After
> \<newline>, O'CAML and F# will ignore leading spaces
> and tabs; the C family will not. Some Prolog systems
> support \c as well as \<newline>, the \c having been
> ultimately inspired by the \c feature of echo(1).
>
> I really don't see any appeal to authority here.
>
>> Also, even if we assume that your argument may be valid for a particular context, say, strings in Python, it would not make much sense to consider it in this situation, for you know very well that strings and atoms are not the same thing.
>
> Yes, but ***SO WHAT***? Strings and atoms are not the same
> thing in Prolog or Mercury either. What of that? They may
> both be _notated_ similarly.
>
> It is not the case that Erlang does something sensible with
> \<newline> in strings and something stupid with \<newline>
> in atoms. It does the *SAME* thing in both contexts, and
> it is equally dangerous in both.
>
>> Using similar reasoning people may also expect that:
>>
>> A = 1,
>> A = A + 1
>>
>> should not crash a program
>
> This claim is invalid, because my reasoning makes an
> *essential* appeal to the fact that the behaviour of
> backslash+newline is *UNDOCUMENTED* in Erlang.
>
> The behaviour here is *DOCUMENTED*.
>
> See the difference?
>
> [Skipping]
>>
>> I think you are making an assumption this was "an implementation accident".
>
> Yes, I am. BECAUSE IT IS NOT DOCUMENTED!
>>
>> I am making an assumption that this was a well considered and deliberate effort.
>
> Why would a "well considered and deliberate effort"
> - provide a redundant way to do something we have *THREE*
> other ways to do
> - deliberately create a hazard
> - FAIL TO DOCUMENT the decision?
>
>> In both cases we are talking about assumptions, why present them as facts then?
>
> When did I do that?
>>
>>>
>>> It would be excusable to make backslash+newline an
>>> always-reported syntax error. People would get a nasty
>>> surprise, but at least they wouldn't silently get the
>>> wrong value in their program. In fact I think that
>>> *every* \<char> combination that is not explicitly
>>> documented should be reported as a syntax error.
>>
>> Why is it that you're ignoring the fact that the intent behind usage of apostrophes in atom construction is documented.
>
> Because I am *NOT* ignoring that, and you have no grounds
> for suggesting otherwise.
>
>> Also, if you place a new-line during the construction of an atom without apostrophes, the syntax error will be indeed reported.
>
> So what? That's totally off-topic. In fact
> if<newline>a =:= b ...
> is *NOT* a syntax error and *WON'T* be reported.
> It just isn't one atom, that's all.
>
>>
>>>
>>> Second, it is currently the case that backslash has a
>>> special meaning in Erlang *ONLY* inside quoted literals
>>> (counting $\t as a quoted literal). Your "less confusing
>>> (or even more consistent)" proposal introduces a new
>>> thing that *looks* like an operator but *isn't* one.
>>
>> As opposed to not introducing a new operator, but definitely behaving like there was one (e.g. one that eliminates new-line character altogether)?
>
> There are no operators inside strings or atoms.
> Backslash+newline is not described as or treated as or thought as
> in any way resembling an operator in languages that define it.
> A backlash+newline that stands for the empty sequence is no more
> an operator than a backslash+newline that stands for a non-empty
> sequence. (If you have a programming language with
> byte strings, a Unicode escape \u2022 might stand for more than
> one byte. It wouldn't be an operator either.)
>
>>> (*) In my view, it is nothing more than a historical incident (or a whim of someone in a position of authority a long time ago) that yielded an elimination of new-line character when preceded by a backslash, whilst in any other case it is a backslash that is eliminated.
>
> What? In a sequence like \t, neither character is eliminated.
> The *whole* escape sequence is replaced by another character
> sequence.
>
>> For example:
>>
>> \" results in a double quote -- backslash is eliminated;
>> \\ results in a backslash (having first backslash eliminated);
>> \002 results in a integer value of two -- backslash is eliminated;
>
> Only if you want to say that the 0, the second 0, and the 2 are
> also "eliminated".
>
>> \n results in integer value of 0x0a -- backslash is eliminated;
>
> And so is the n. "Elimination" just is not a helpful way to
> talk about the replacement of (entire) escape sequences by
> other character sequences (which might or might not have unit
> length).
>
> "Elimination" *would* be a useful way to talk about
> single-escape processing in Common Lisp. But Erlang is not Lisp.
> (LFE is another matter.)
>>
>> Why should then a sequence such:
>>
>> "This is a test \ 0x0a
>> string"
>
> Remember my demand that UNDOCUMENTED escape sequences
> (like backslash+space or backslash+tab) should be explicit
> compile-time errors. If backslash+space or backslash+tab
> were to be documented as doing something, no matter how
> useless, then that is would they would do. Until then,
> this should be a compile-time error.
>
>
>> Result in a string "This is test string" with both backslash and new-line eliminated.
>
> It should not. (The only newline I see is the one after 0x0a,
> and nobody is saying _that_ should go.)
>
>> And yet:
>>
>> "This is a test\n string"
>>
>> Would result in insertion of a new-line character:
>
> Because that's what backslash+n is defined to do.
>
> Escape processing in quoted literals
> replaces <escape SEQUENCES> with <character SEQUENCES>
> which might contain no characters, 1 character, or many
> characters. Whatever the replacement is, is whatever
> the documentation says it is.
>
> Undefined escape sequences should be errors.
> In fact, in R16B03-1, most undefined escape sequences
> *are* errors.
>
> Here's an example of the trouble that unchecked
> undocumented escape sequences can get you into.
> In R16B03-1, "\x{20}" uses a documented escape
> sequence to get a space character " ". Trying it in
> an older release gave me "x{20}".
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list