Significant newlines

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Significant newlines

Soni "They/Them" L.
In Lua, you can't put a line break in the middle of a string. However,
ever since Lua 5.2, newlines are equivalent to whitespace everywhere else.

$ lua
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
 > "test
 >> test"
stdin:1: unfinished string near '"test'

vs

$ lua
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
 > do
 >> print("x")
 >> (print)("test")
 >> end
x
stdin:2: attempt to call a nil value
stack traceback:
     stdin:2: in main chunk
     [C]: in ?

Note that I'm asking for multiline strings that support escapes, not the
removal of raw strings.

(I'm fine with line comments the way they are, tho)

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Sam Putman


On Wed, Aug 31, 2016 at 10:38 AM, Soni L. <[hidden email]> wrote:
In Lua, you can't put a line break in the middle of a string. However, ever since Lua 5.2, newlines are equivalent to whitespace everywhere else.


This is incorrect. Newlines are not equivalent to whitespace *in strings*. Whitespace is significant *in strings*.

This is a feature, not a bug.

 
$ lua
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
> "test
>> test"
stdin:1: unfinished string near '"test'

vs

$ lua
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
> do
>> print("x")
>> (print)("test")
>> end
x
stdin:2: attempt to call a nil value
stack traceback:
    stdin:2: in main chunk
    [C]: in ?

Note that I'm asking for multiline strings that support escapes, not the removal of raw strings.

(I'm fine with line comments the way they are, tho)

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.



Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Martin
In reply to this post by Soni "They/Them" L.
On 16-08-31 10:38 AM, Soni L. wrote:
> In Lua, you can't put a line break in the middle of a string. However,
> ever since Lua 5.2, newlines are equivalent to whitespace everywhere else.

There is no such problem with long-quoted strings.

For short-quoted-string there is magical escape sequence "\" <LF>.

If apply your proposal
1) "\" <LF> sequence becomes redundant
2) Possible tails space truncations after saving
"three_tail_spaces...
next_line"

Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Soni "They/Them" L.
In reply to this post by Sam Putman


On 31/08/16 02:56 PM, Sam Putman wrote:

>
>
> On Wed, Aug 31, 2016 at 10:38 AM, Soni L. <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     In Lua, you can't put a line break in the middle of a string.
>     However, ever since Lua 5.2, newlines are equivalent to whitespace
>     everywhere else.
>
>
> This is incorrect. Newlines are not equivalent to whitespace *in
> strings*. Whitespace is significant *in strings*.
>
> This is a feature, not a bug.

This is neither a bug nor a feature. It's a legacy feature.

Whitespace is *kept* in strings, but whitespace doesn't break a string.

$ lua
Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
 > "This is a valid string"
This is a valid string

While newlines break the string.

I'm proposing treating newlines in strings the same way whitespace is
treated: keep it as it is.

With the exception of ASCII NUL, no other character breaks strings. Also
multiline strings don't support escapes and it'd be nice to have an
alternative that does.

>
>     $ lua
>     Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
>     > "test
>     >> test"
>     stdin:1: unfinished string near '"test'
>
>     vs
>
>     $ lua
>     Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
>     > do
>     >> print("x")
>     >> (print)("test")
>     >> end
>     x
>     stdin:2: attempt to call a nil value
>     stack traceback:
>         stdin:2: in main chunk
>         [C]: in ?
>
>     Note that I'm asking for multiline strings that support escapes,
>     not the removal of raw strings.
>
>     (I'm fine with line comments the way they are, tho)
>
>     --
>     Disclaimer: these emails may be made public at any given time,
>     with or without reason. If you don't agree with this, DO NOT REPLY.
>
>
>

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Sam Putman


On Wed, Aug 31, 2016 at 11:21 AM, Soni L. <[hidden email]> wrote:

With the exception of ASCII NUL, no other character breaks strings. Also multiline strings don't support escapes and it'd be nice to have an alternative that does.


Sure would, allow me to offer you such an alternative:

mystring = "Hi Soni. I'm a multi-line string!\n"
             ..  "I'm convenient, \t offer escapes, and more!\n"
             ..  "By the way, do you have a repo or something?\n"
             ..  "Because I'm starting to wonder whether you write software,\n"
             ..  "Or just write *about* software...\n"

You're welcome!

Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Soni "They/Them" L.


On 31/08/16 07:22 PM, Sam Putman wrote:

>
>
> On Wed, Aug 31, 2016 at 11:21 AM, Soni L. <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>     With the exception of ASCII NUL, no other character breaks
>     strings. Also multiline strings don't support escapes and it'd be
>     nice to have an alternative that does.
>
>
> Sure would, allow me to offer you such an alternative:
>
> mystring = "Hi Soni. I'm a multi-line string!\n"
>              ..  "I'm convenient, \t offer escapes, and more!\n"
>              ..  "By the way, do you have a repo or something?\n"
>              ..  "Because I'm starting to wonder whether you write
> software,\n"
>              ..  "Or just write *about* software...\n"

mystring = "Hi Sam. I'm also a multi-line string!\n\z
             except I'm better! I take less bytes to type,\n\z
             and still provide the same newlineness!\n\z
             However, I cannot be used in the REPL, as it doesn't like
me.\n\z
             This is also nowhere near as nice as Rust's strings.\n\z
             But yes, I do have a github, it's SoniEx2. I don't use it
anymore, BitBucket is better.\n"

>
> You're welcome!
>

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Sam Putman


On Wed, Aug 31, 2016 at 4:53 PM, Soni L. <[hidden email]> wrote:


On 31/08/16 07:22 PM, Sam Putman wrote:


On Wed, Aug 31, 2016 at 11:21 AM, Soni L. <[hidden email] <mailto:[hidden email]>> wrote:


    With the exception of ASCII NUL, no other character breaks
    strings. Also multiline strings don't support escapes and it'd be
    nice to have an alternative that does.


Sure would, allow me to offer you such an alternative:

mystring = "Hi Soni. I'm a multi-line string!\n"
             ..  "I'm convenient, \t offer escapes, and more!\n"
             ..  "By the way, do you have a repo or something?\n"
             ..  "Because I'm starting to wonder whether you write software,\n"
             ..  "Or just write *about* software...\n"

mystring = "Hi Sam. I'm also a multi-line string!\n\z
            except I'm better! I take less bytes to type,\n\z
            and still provide the same newlineness!\n\z
            However, I cannot be used in the REPL, as it doesn't like me.\n\z
            This is also nowhere near as nice as Rust's strings.\n\z
            But yes, I do have a github, it's SoniEx2. I don't use it anymore, BitBucket is better.\n"


So, that indentation in the above code... 

is it part of the string?

neither of the two possible answers is satisfactory. 

That's half the reason why this is a bad idea.

The other half is localizing error detection in the parser.

The third half is that less bytes of typing has never been a core value of Lua. If you want to play code golf, there's Perl. 

I look forward to the next non-problem. Personally I favor a mellow aqua for the side of the bikeshed...

(what possible reason could you have had for making half your newlines escaped and the other half literal? \z isn't even a valid escape sequence >.< )
 

You're welcome!


--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.



Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Sean Conner
In reply to this post by Soni "They/Them" L.
It was thus said that the Great Soni L. once stated:

> In Lua, you can't put a line break in the middle of a string. However,
> ever since Lua 5.2, newlines are equivalent to whitespace everywhere else.
>
> $ lua
> Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
> > "test
> >> test"
> stdin:1: unfinished string near '"test'
>
> vs
>
> $ lua
> Lua 5.3.3  Copyright (C) 1994-2016 Lua.org, PUC-Rio
> > do
> >> print("x")
> >> (print)("test")
> >> end
> x
> stdin:2: attempt to call a nil value
> stack traceback:
>     stdin:2: in main chunk
>     [C]: in ?
>
> Note that I'm asking for multiline strings that support escapes, not the
> removal of raw strings.
>
> (I'm fine with line comments the way they are, tho)

  Section 3.1 of the Lua 5.3 manual:

        Literal strings can be delimited by matching single or double
        quotes, and can contain the following C-like escape sequences: '\a'
        (bell), '\b' (backspace), '\f' (form feed), '\n' (newline), '\r'
        (carriage return), '\t' (horizontal tab), '\v' (vertical tab), '\\'
        (backslash), '\"' (quotation mark [double quote]), and '\''
        (apostrophe [single quote]). A backslash followed by a real newline
                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        results in a newline in the string. The escape sequence '\z' skips
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        the following span of white-space characters, including line breaks;
        it is particularly useful to break and indent a long literal string
        into multiple lines without adding the newlines and spaces into the
        string contents.

So, one could do:

test = "Hi.  I'm Soni, \
The manual does indeed answer this question.\
Is that not nifty?"

print(test)

The '\z' escape sequence also works back to Lua 5.2.  You might then want to
experiment with various forms of '\<literal newline>' and '\z' to see the
effect they have on strings.

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Sean Conner
In reply to this post by Soni "They/Them" L.
It was thus said that the Great Soni L. once stated:

> On 31/08/16 07:22 PM, Sam Putman wrote:
> >On Wed, Aug 31, 2016 at 11:21 AM, Soni L. <[hidden email]
> ><mailto:[hidden email]>> wrote:
> >
> >    With the exception of ASCII NUL, no other character breaks
> >    strings. Also multiline strings don't support escapes and it'd be
> >    nice to have an alternative that does.
> >
> >Sure would, allow me to offer you such an alternative:
> >
> >mystring = "Hi Soni. I'm a multi-line string!\n"
> >             ..  "I'm convenient, \t offer escapes, and more!\n"
> >             ..  "By the way, do you have a repo or something?\n"
> >             ..  "Because I'm starting to wonder whether you write software,\n"
> >             ..  "Or just write *about* software...\n"
>
> mystring = "Hi Sam. I'm also a multi-line string!\n\z
>             except I'm better! I take less bytes to type,\n\z
>             and still provide the same newlineness!\n\z
>             However, I cannot be used in the REPL, as it doesn't like me.\n\z
>             This is also nowhere near as nice as Rust's strings.\n\z
>             But yes, I do have a github, it's SoniEx2. I don't use it anymore, BitBucket is better.\n"

  This tells me

        1) you already knew about \z and how it works, or
        2) you read Martin's reply and didn't mention it.

  Either one shows just how annoying replying to you can get.  You *just*
solved your issue.  Now, it may be that you do not *like* this particular
answer (because Rust does it The Right Way According To You, but Lua *is
not* Rust; nor is it Javascript, Ruby, Python or Perl).  Instead, if you had
questioned:

        Why does a literal newline break non-raw strings?  I would like to
        have multiline strings that *do* process escapes.

then perhaps a good conversation could be had.  One reason *not* to allow
literal newlines in a non-raw string is the following code:

        attrib = 'title"
        title  = 'This is the Title of this Object"

        add_attribute(attrib,title)

  A bug like this might go a long time before being discovered (and yes, it
is a bit contrived, but it does show a problem with your proposal).  There
could be other reasons why it wasn't done (even "it's never been done that
way before").

  -spc


Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Sean Conner
It was thus said that the Great Sean Conner once stated:
>
> attrib = 'title"
> title  = 'This is the Title of this Object"

  Before Soni replies that will will give an error before taking some
moments to think about it, let me change the example a tiny bit:

        attrib = 'title"
        title  = "This is the Title of this Object'

        add_attribute(attrib,title)

  And yes, mismatched quotes bite me quite often in Lua code.

  -spc (Sigh---a bug in the sample bug)


Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Soni "They/Them" L.


On 31/08/16 10:35 PM, Sean Conner wrote:

> It was thus said that the Great Sean Conner once stated:
>> attrib = 'title"
>> title  = 'This is the Title of this Object"
>    Before Soni replies that will will give an error before taking some
> moments to think about it, let me change the example a tiny bit:
>
> attrib = 'title"
> title  = "This is the Title of this Object'
>
> add_attribute(attrib,title)
>
>    And yes, mismatched quotes bite me quite often in Lua code.
>
>    -spc (Sigh---a bug in the sample bug)
>
>
Assuming a proper add_attribute that doesn't accept nils (it really
shouldn't), you get a runtime error!

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Sean Conner
It was thus said that the Great Soni L. once stated:

>
>
> On 31/08/16 10:35 PM, Sean Conner wrote:
> >It was thus said that the Great Sean Conner once stated:
> >> attrib = 'title"
> >> title  = 'This is the Title of this Object"
> >   Before Soni replies that will will give an error before taking some
> >moments to think about it, let me change the example a tiny bit:
> >
> > attrib = 'title"
> > title  = "This is the Title of this Object'
> >
> > add_attribute(attrib,title)
> >
> >   And yes, mismatched quotes bite me quite often in Lua code.
> >
> >   -spc (Sigh---a bug in the sample bug)
> >
> >
> Assuming a proper add_attribute that doesn't accept nils (it really
> shouldn't), you get a runtime error!

Quoting Lorenzo Donati, just in case you didn't see it:

> This nonetheless, I think you are a bit deaf on what people tell you
> (besides strict technical matters), so you end up looking like a
> sophist. Sophism can be good food for thought sometimes, but too much of
> it decreases the signal-to-noise ratio of this list in a way most people
> here would find fatiguing or even annoying.
>
> That's why (I suspect) you get such a bunch of "off-topic" answers to an
> interesting question like the one you started this thread with.

  -spc (https://en.wikipedia.org/wiki/Plonk_(Usenet))


Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Sean Conner
In reply to this post by Soni "They/Them" L.
It was thus said that the Great Soni L. once stated:

> On 31/08/16 10:35 PM, Sean Conner wrote:
> >It was thus said that the Great Sean Conner once stated:
> >> attrib = 'title"
> >> title  = 'This is the Title of this Object"
> >   Before Soni replies that will will give an error before taking some
> >moments to think about it, let me change the example a tiny bit:
> >
> > attrib = 'title"
> > title  = "This is the Title of this Object'
> >
> > add_attribute(attrib,title)
> >
> >   And yes, mismatched quotes bite me quite often in Lua code.
> >
> >   -spc (Sigh---a bug in the sample bug)
> >
> >
> Assuming a proper add_attribute that doesn't accept nils (it really
> shouldn't), you get a runtime error!

  I can't just let this go.  Sigh.

  Should a function called "add_attribute()" accept nils?  That's debatable.
HTML 4 allowed for non-value attributes:

        <input type="checkbox" checked>

Or it could be that the usecase for this function is that an attribute that
is given a nil value should just quietly be ignored.  YOU DON'T KNOW!
Especially since this is an example to show how mismatched quotes for
strings that can accept embedded newlines might not be a good idea.

  Three stories from work:  we process phone calls.  As a phone call is
being made, we get notification (via the phone network over SS7 and via the
Internet via SIP) that 505-555-1000 is calling 505-555-2000 [1].  It came to
pass that we were receiving notifications like 505-555-1000 is calling
505-555-1000.  This is something we were NOT expecting, and we weren't
handling it correctly (it was, in fact, really messing things up).  Turns
out that it's a valid case, and one we need to not do our thing---that case
is 505-555-1000 is checking voice mail.  Regardless of whether you (Soni)
think this is stupid or not, it is what it is.  It wasn't our call (pun
unintended) to say otherwise.

  Second story:  one of our components sends a special query to another
service (that returns a name for a given phone number---caller name ID)
every few seconds to ensure it's still up and running.  The reason for the
special query is that we don't get charged for it [2].  The unexpected
happened---the special query was removed from the service, so it kept
returning "record not found."  OUR code was a bit ... sloppy (let's say) in
checking the return code and the "record not found" was treated as "we never
heard back from the service, so it must be down."  That in turn caused our
component to shut down, which in turn caused other components to shut down
and pretty soon we weren't doing the job the Monopolistic Phone Companies
were paying us to do.  The original developer just assumed that this case,
the special query, would never be deleted.  Bad mistake on our part.

  Third story:  I'm writing code to parse SIP messages.  I have a bunch of
code to validate the message and return errors for certain problems---wrong
version of SIP, missing fields in required headers, etc.  My manager
override my concerns and forced me to ignore such errors as long as we could
proceed.  In most cases, yes, we could proceed but I didn't like the
decision.  At that point it wasn't my call.  I had to shup up and accept
potentially bad data.  

  Now the point of these three stores are---mistakes happen and we're not
always in control over everything.  Should add_attribute() error on nils?
Maybe, maybe not.  Should add_attribute() reject an attribute named:

        title
     title  = "This is the Title of this Object

  Again, maybe, maybe not.  Depends on many factors, *some of which may be
out of my control*.

  Also, saying "[a]ssuming a proper add_attribute ..." is missing the point
*entirely*  It's a FUCKING EXAMPLE!  It shows a potential problem, and one
that, depending on how code *might* be written (and certainly not how you
demand code be written) could hide a bug for a long time.  How hard is that
to get through your skull?  There are times when something you think should
never happen (a phone calling itself) does.  There are times when you botch
the logic and bad things happen.  And there are times where you are forced
to do things you don't necessarily agree with (code wise).  

  That you continally *miss* the point is what is so frustrating in your
messages.

  -spc (Okay, now *plonk*)

[1] In the North American Numbering Plan, any exchange of 555 is
        reserved for examples, much like 'example.net' and 'example.com' is
        reserved for examples.  These are not real phone numbers.

[2] It's a very small charge, something on the order of a hundredth of a
        cent thereabouts, but it does add up.  Also, these are The
        Monopolistic Phone Companies we're talking about---they charge for
        *everything* coming or going.  This is yet another it is what it is.

Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Soni "They/Them" L.


On 01/09/16 01:03 AM, Sean Conner wrote:
> [snip]
>    That you continally *miss* the point is what is so frustrating in your
> messages.

I don't miss the point. Every issue you have with this proposal can be
simulated with [[ and ]].

local title = [[title"
local attribute = "attribute]]

But you won't do that. Why's it different for ' and "? If you do mess it
up, chances are most of the time you'll get a compile error. If not,
you'll probably get a runtime error. If not, then you're in the < 1% of
the cases that do actually run but don't work properly. The benefits of
this proposal far outweigh the risks.

>
>    -spc (Okay, now *plonk*)
>
> [1] In the North American Numbering Plan, any exchange of 555 is
> reserved for examples, much like 'example.net' and 'example.com' is
> reserved for examples.  These are not real phone numbers.
>
> [2] It's a very small charge, something on the order of a hundredth of a
> cent thereabouts, but it does add up.  Also, these are The
> Monopolistic Phone Companies we're talking about---they charge for
> *everything* coming or going.  This is yet another it is what it is.
>

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Pierre-Yves Gérardy
On Thu, Sep 1, 2016 at 1:44 PM, Soni L. <[hidden email]> wrote:
> Every issue you have with this proposal can be
> simulated with [[ and ]].
>
> local title = [[title"
> local attribute = "attribute]]

You may not know it but " and ' live on the same key on QWERTY
keyboards (" is shift + '), and next to each other on French AZERTY,
which makes it an easy typo.

Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Soni "They/Them" L.


On 01/09/16 11:12 AM, Pierre-Yves Gérardy wrote:

> On Thu, Sep 1, 2016 at 1:44 PM, Soni L. <[hidden email]> wrote:
>> Every issue you have with this proposal can be
>> simulated with [[ and ]].
>>
>> local title = [[title"
>> local attribute = "attribute]]
> You may not know it but " and ' live on the same key on QWERTY
> keyboards (" is shift + '), and next to each other on French AZERTY,
> which makes it an easy typo.
>
I use QWERTY. I never had the problem you're talking about. So yes, it's
an easy typo, but it's also orders of magnitude more likely to cause a
compile or runtime error than actually work.

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.


Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Ką Mykolas
In reply to this post by Pierre-Yves Gérardy
On the side note, no such a thing on British QWERTY. Which I personally prefer for programming.

On Thu, Sep 1, 2016 at 5:12 PM, Pierre-Yves Gérardy <[hidden email]> wrote:
You may not know it but " and ' live on the same key on QWERTY
keyboards (" is shift + '), and next to each other on French AZERTY,
which makes it an easy typo.


Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Viacheslav Usov
The complete syntax of Lua in the reference manual uses LiteralString, whose description is said to be given in 3.1.

3.1 says: "Any byte in a literal string not explicitly affected by the previous rules represents itself." The newline byte (decimal value 10 in ASCII and UTF-8) is explicitly mentioned in three places in the preceding text:

(1) A backslash followed by a real newline results in a newline in the string. 

(2) The escape sequence '\z' skips the following span of white-space characters, including line breaks

(3) Any kind of end-of-line sequence (carriage return, newline, carriage return followed by newline, or newline followed by carriage return) is converted to a simple newline.

(3) is given only in the context of long strings. Therefore, in a literal string delimited by single or double quotes, the newline byte has a special meaning only when it follows the backslash or is within a span of white-space characters following \z; and it represents itself otherwise. The same is true for the carriage return bytes (decimal value 13 in ASCII and UTF-8). So, per "the official definition of the Lua language" newlines and carriage returns should just work without being escaped in either kind of string, albeit with subtle platform-dependent differences in non-long strings. 

But we know that the official implementation produces error "unfinished string" when a non-long string has a newline. So at least one of the two is wrong and ought to be fixed.

Personally, I see no reason why the implementation cannot treat newline and carriage return bytes as described in the manual. As far as I can see, llex.c already has a special case just to emit that error message:

case '\n':
case '\r':
        lexerror(ls, "unfinished string", TK_STRING);


That special case code can be trivially changed to match the officially description. We can also define the behaviour of newline and carriage returns to be the same in both kinds of string literals, thus eliminating the platform-dependent differences mentioned above; then it is even more trivial to change that special case (this is because (1) given above is not followed exactly by the implementation, which handles not just "a real newline" but any of the four possible \n and \r combinations, apparently to eliminate those same platform-dependent differences).

The "typo" arguments given earlier, I do not find them convincing. The treat-unknown-as-global rule is far more dangerous when it comes to types, yet we somehow live with that.

But fundamentally, we should eliminate the discrepancy in some way. Saying one thing and doing something completely different is bad.

Cheers,
V.

Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Pierre-Yves Gérardy
In reply to this post by Ką Mykolas
On Fri, Sep 2, 2016 at 10:18 AM, Ką Mykolas <[hidden email]> wrote:
> On Thu, Sep 1, 2016 at 5:12 PM, Pierre-Yves Gérardy <[hidden email]>
> wrote:
>> You may not know it but " and ' live on the same key on QWERTY
>> keyboards (" is shift + '), and next to each other on French AZERTY,
>> which makes it an easy typo.
> On the side note, no such a thing on British QWERTY. Which I personally
> prefer for programming.

Oh, then it's the similarity is an Apple-only thing (I tried the Apple
UK layout before sending the GP, the only difference with the US
layout is £ vs # (I did't try Alt+x chords)).

—Pierre-Yves

Reply | Threaded
Open this post in threaded view
|

Re: Significant newlines

Lorenzo Donati-3
In reply to this post by Sean Conner
On 01/09/2016 06:03, Sean Conner wrote:
[snip]

>   Also, saying "[a]ssuming a proper add_attribute ..." is missing the point
> *entirely*  It's a FUCKING EXAMPLE!  It shows a potential problem, and one
> that, depending on how code *might* be written (and certainly not how you
> demand code be written) could hide a bug for a long time.  How hard is that
> to get through your skull?  There are times when something you think should
> never happen (a phone calling itself) does.  There are times when you botch
> the logic and bad things happen.  And there are times where you are forced
> to do things you don't necessarily agree with (code wise).

That's where the fun for the mathematicians (or computer scientists)
ends and where the pa... *ahem* ... fun for the (software) engineers
begins (Murphy was an engineer)! [1]

:-)


>
>   That you continally *miss* the point is what is so frustrating in your
> messages.
>

"When the wise man point at the moon, the fo... *ahem* ... the misguided
man looks at the finger!" :-)

>   -spc (Okay, now *plonk*)

[snip]

Cheers!

-- Lorenzo


[1] Sorry, I couldn't resist posting an undergraduate-like cross-faculty
joke ("mathematicians vs. engineers", a la "gorilla vs. shark" [2] )!
It's therapeutic! :-D

Disclaimers: (1) Yes, I'm an engineer; (2) Some of my best friends are
mathematicians! :-)

[2] https://blog.stackoverflow.com/2011/08/gorilla-vs-shark/

12