- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
>mkdir
Thu, 2011-01-20, 23:40
Surprisingly, this works well. What surprised me is that it works with or without a space between > and mkdir…
val > = DefaultShell;
>mkdir "dir1"
http://github.com/razie/scalafs/blob/master/src/main/scala/razie/fs/proto1/Sf1App.scala
$ scala
Welcome to Scala version 2.8.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.
6.0_22).
Type in expressions to have them evaluated.
Type :help for more information.
scala> val > = System.out
>: java.io.PrintStream = java.io.PrintStream@24f90b1a
scala> >println ("well, hello there")
well, hello there
scala>
Fri, 2011-01-21, 02:37
#2
Re: >mkdir
In your example, > is a method. In Razvan's, it's a val.
If you think the distinction is comes from the lexer, then you expect no difference. If you expect it's at the level of the parser, then you expect a difference.
It's the same sort of thing with
"Hi".length
"Hi" length
"Hi"length
If you believe that the separation is at the level of the lexer, you think the third is the same as the first two. If you think it's at the parser level, then the third seems like it could be different (e.g. fail to work).
Similarly,
4.toLong
4 toLong
4toLong
gives different expectations depending on what you think is being handled by the lexer and what is handled by the parser.
--Rex
P.S. "Hi"length works. 4toLong doesn't. So I'm not sure there's any super-obvious expectation for how these things ought to behave. If you think about it for a while, you can probably come up with some rationalizations.
On Thu, Jan 20, 2011 at 7:48 PM, Jim Balter <Jim@balter.name> wrote:
If you think the distinction is comes from the lexer, then you expect no difference. If you expect it's at the level of the parser, then you expect a difference.
It's the same sort of thing with
"Hi".length
"Hi" length
"Hi"length
If you believe that the separation is at the level of the lexer, you think the third is the same as the first two. If you think it's at the parser level, then the third seems like it could be different (e.g. fail to work).
Similarly,
4.toLong
4 toLong
4toLong
gives different expectations depending on what you think is being handled by the lexer and what is handled by the parser.
--Rex
P.S. "Hi"length works. 4toLong doesn't. So I'm not sure there's any super-obvious expectation for how these things ought to behave. If you think about it for a while, you can probably come up with some rationalizations.
On Thu, Jan 20, 2011 at 7:48 PM, Jim Balter <Jim@balter.name> wrote:
How is that different from 2>1 and 2 > 1 working same?
-- Jim
On Thu, Jan 20, 2011 at 2:40 PM, Razvan Cojocaru <pub@razie.com> wrote:
Surprisingly, this works well. What surprised me is that it works with or without a space between > and mkdir…
val > = DefaultShell;
>mkdir "dir1"
http://github.com/razie/scalafs/blob/master/src/main/scala/razie/fs/proto1/Sf1App.scala
$ scala
Welcome to Scala version 2.8.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.
6.0_22).
Type in expressions to have them evaluated.
Type :help for more information.
scala> val > = System.out
>: java.io.PrintStream = java.io.PrintStream@24f90b1a
scala> >println ("well, hello there")
well, hello there
scala>
Fri, 2011-01-21, 03:27
#3
Re: >mkdir
On Thu, Jan 20, 2011 at 5:24 PM, Rex Kerr <ichoran@gmail.com> wrote:
Of course, but that's about as far from relevant as one can get. It would be a rather arcane language that treated operator characters as delimited from letters and digits in infix position but not in unary position, let alone that made the sort of distinction you refer to.
-- Jim
In your example, > is a method. In Razvan's, it's a val.
Of course, but that's about as far from relevant as one can get. It would be a rather arcane language that treated operator characters as delimited from letters and digits in infix position but not in unary position, let alone that made the sort of distinction you refer to.
-- Jim
Fri, 2011-01-21, 07:07
#4
RE: >mkdir
Hmm, this looks unfair, although logical and… arcane?
scala> val >p = System.out
<console>:1: error: illegal start of simple pattern
val >p = System.out
^
Not regular, hence surprising…
This explains it though – I was under the impression that operator names can be any combination… my bad!
scala> class G { def >>print { >print "hehe" } }
<console>:1: error: '=' expected but identifier found.
class G { def >>print { >print "hehe" } }
^
<console>:1: error: illegal start of simple expression
class G { def >>print { >print "hehe" } }
^
From: jqbalter@gmail.com [mailto:jqbalter@gmail.com] On Behalf Of Jim Balter
Sent: January-20-11 9:14 PM
To: Rex Kerr
Cc: Razvan Cojocaru; scala-user@listes.epfl.ch
Subject: Re: [scala-user] >mkdir
On Thu, Jan 20, 2011 at 5:24 PM, Rex Kerr <ichoran@gmail.com> wrote:
In your example, > is a method. In Razvan's, it's a val.
Of course, but that's about as far from relevant as one can get. It would be a rather arcane language that treated operator characters as delimited from letters and digits in infix position but not in unary position, let alone that made the sort of distinction you refer to.
-- Jim
Fri, 2011-01-21, 07:57
#5
Re: >mkdir
On Thu, Jan 20, 2011 at 10:05 PM, Razvan Cojocaru <pub@razie.com> wrote:
There's a language spec that determines what should be compilable and that's what the compiler accepts (modulo compiler bugs). If the code violates the spec, then the compiler should point out that it's a mistake. If it doesn't violate the spec, then there is no way for the compiler to know that it's a mistake. But I'm not clear on what you think is a mistake in what you gave previously. Why should >mkdir be a mistake if > mkdir isn't, or v.v.?
How is it not regular (or unfair, or even arcane)?
val p q = System.out
yields the same error message; in both cases there are two identifiers between val and =. As far as Scala is concerned, > and p are both perfectly acceptable identifiers. This is unusual compared to some other languages, but one very venerable language has similar rules, and it is a powerful feature of Scala because it eliminates the distinction between operators and method names and increases the ability to create DSLs.
But that obviously cannot be, as my 2>1 example pointed out. Identifiers in Scala are either a sequence of operator characters or a letter followed by a sequence of letters, digits, underscores, or dollar signs. They can't be mixed, with the exception that the latter sequence can be followed by an underscore and a sequence of operator characters, e.g.: unary_+ or frob1_$_^*&#*^#
In both cases you have two identifiers in a row. As before,
class G { def qq print { q print "hehe" } }
gets the same errors.
-- Jim
There's a language spec that determines what should be compilable and that's what the compiler accepts (modulo compiler bugs). If the code violates the spec, then the compiler should point out that it's a mistake. If it doesn't violate the spec, then there is no way for the compiler to know that it's a mistake. But I'm not clear on what you think is a mistake in what you gave previously. Why should >mkdir be a mistake if > mkdir isn't, or v.v.?
Hmm, this looks unfair, although logical and… arcane?
scala> val >p = System.out
<console>:1: error: illegal start of simple pattern
val >p = System.out
^
Not regular, hence surprising…
How is it not regular (or unfair, or even arcane)?
val p q = System.out
yields the same error message; in both cases there are two identifiers between val and =. As far as Scala is concerned, > and p are both perfectly acceptable identifiers. This is unusual compared to some other languages, but one very venerable language has similar rules, and it is a powerful feature of Scala because it eliminates the distinction between operators and method names and increases the ability to create DSLs.
This explains it though – I was under the impression that operator names can be any combination… my bad!
But that obviously cannot be, as my 2>1 example pointed out. Identifiers in Scala are either a sequence of operator characters or a letter followed by a sequence of letters, digits, underscores, or dollar signs. They can't be mixed, with the exception that the latter sequence can be followed by an underscore and a sequence of operator characters, e.g.: unary_+ or frob1_$_^*&#*^#
scala> class G { def >>print { >print "hehe" } }
<console>:1: error: '=' expected but identifier found.
class G { def >>print { >print "hehe" } }
^
<console>:1: error: illegal start of simple expression
class G { def >>print { >print "hehe" } }
^
In both cases you have two identifiers in a row. As before,
class G { def qq print { q print "hehe" } }
gets the same errors.
-- Jim
From: jqbalter@gmail.com [mailto:jqbalter@gmail.com] On Behalf Of Jim Balter
Sent: January-20-11 9:14 PM
To: Rex Kerr
Cc: Razvan Cojocaru; scala-user@listes.epfl.ch
Subject: Re: [scala-user] >mkdir
On Thu, Jan 20, 2011 at 5:24 PM, Rex Kerr <ichoran@gmail.com> wrote:
In your example, > is a method. In Razvan's, it's a val.
Of course, but that's about as far from relevant as one can get. It would be a rather arcane language that treated operator characters as delimited from letters and digits in infix position but not in unary position, let alone that made the sort of distinction you refer to.
-- Jim
Fri, 2011-01-21, 08:07
#6
Re: >mkdir
On Thu, Jan 20, 2011 at 10:47 PM, Jim Balter <Jim@balter.name> wrote:
Sorry, I misstated this. It's actually a letter followed by a sequence of letters or digits, where underscore and dollar sign are considered to be letters. The difference is that my previous formulation doesn't include identifiers starting with an underscore or dollar sign.
-- Jim
Identifiers in Scala are either a sequence of operator characters or a letter followed by a sequence of letters, digits, underscores, or dollar signs.
Sorry, I misstated this. It's actually a letter followed by a sequence of letters or digits, where underscore and dollar sign are considered to be letters. The difference is that my previous formulation doesn't include identifiers starting with an underscore or dollar sign.
-- Jim
Fri, 2011-01-21, 13:17
#7
Re: >mkdir
Not only underscore and dollar sign are considered to be letters, though the dollar sign is reserved for the compiler and should not be used, but they are considered uppercase letters! :-)
On Fri, Jan 21, 2011 at 04:53, Jim Balter <Jim@balter.name> wrote:
--
Daniel C. Sobral
I travel to the future all the time.
On Fri, Jan 21, 2011 at 04:53, Jim Balter <Jim@balter.name> wrote:
On Thu, Jan 20, 2011 at 10:47 PM, Jim Balter <Jim@balter.name> wrote:
Identifiers in Scala are either a sequence of operator characters or a letter followed by a sequence of letters, digits, underscores, or dollar signs.
Sorry, I misstated this. It's actually a letter followed by a sequence of letters or digits, where underscore and dollar sign are considered to be letters. The difference is that my previous formulation doesn't include identifiers starting with an underscore or dollar sign.
-- Jim
--
Daniel C. Sobral
I travel to the future all the time.
Fri, 2011-01-21, 13:37
#8
Re: >mkdir
And also stuff like this:
val x_: Int = 1
sucking in operators into the identifier stopped me trailing my variable names with underscore real quick.
Cheers,
-John
On 21 January 2011 17:53, Jim Balter <Jim@balter.name> wrote:
val x_: Int = 1
sucking in operators into the identifier stopped me trailing my variable names with underscore real quick.
Cheers,
-John
On 21 January 2011 17:53, Jim Balter <Jim@balter.name> wrote:
On Thu, Jan 20, 2011 at 10:47 PM, Jim Balter <Jim@balter.name> wrote:
Identifiers in Scala are either a sequence of operator characters or a letter followed by a sequence of letters, digits, underscores, or dollar signs.
Sorry, I misstated this. It's actually a letter followed by a sequence of letters or digits, where underscore and dollar sign are considered to be letters. The difference is that my previous formulation doesn't include identifiers starting with an underscore or dollar sign.
-- Jim
Fri, 2011-01-21, 15:17
#9
Re: >mkdir
Now see why my impression and then surprise? In my mind at the time, there was no difference between 4mkdir and >mkdir.
Thanks,Razvan
On 2011-01-21, at 7:28 AM, John Ky <newhoggy@gmail.com> wrote:
Thanks,Razvan
On 2011-01-21, at 7:28 AM, John Ky <newhoggy@gmail.com> wrote:
And also stuff like this:
val x_: Int = 1
sucking in operators into the identifier stopped me trailing my variable names with underscore real quick.
Cheers,
-John
On 21 January 2011 17:53, Jim Balter < (Jim [at] balter [dot] name> wrote:
On Thu, Jan 20, 2011 at 10:47 PM, Jim Balter < (Jim [at] balter [dot] name> wrote:
Identifiers in Scala are either a sequence of operator characters or a letter followed by a sequence of letters, digits, underscores, or dollar signs.
Sorry, I misstated this. It's actually a letter followed by a sequence of letters or digits, where underscore and dollar sign are considered to be letters. The difference is that my previous formulation doesn't include identifiers starting with an underscore or dollar sign.
-- Jim
Fri, 2011-01-21, 16:37
#10
Re: >mkdir
Yes, I can understand that surprise coming from other languages. It's a neat side-corner of scala. I still recommend (in my personal style-guide at least) that you put separation before and after 'operator-notation' methods.
As an aside, I'm not sure why this argument became so heated but I hope it is not a trend that continues on the mailing list. Someone expressed surprise at something someone unfamiliar with Scala's formal definition would surprised about, especially coming from other languages. Let's be careful with how we word our responses.
- Josh
On Fri, Jan 21, 2011 at 9:15 AM, Razvan Cojocaru <pub@razie.com> wrote:
As an aside, I'm not sure why this argument became so heated but I hope it is not a trend that continues on the mailing list. Someone expressed surprise at something someone unfamiliar with Scala's formal definition would surprised about, especially coming from other languages. Let's be careful with how we word our responses.
- Josh
On Fri, Jan 21, 2011 at 9:15 AM, Razvan Cojocaru <pub@razie.com> wrote:
Now see why my impression and then surprise? In my mind at the time, there was no difference between 4mkdir and >mkdir.
Thanks,Razvan
On 2011-01-21, at 7:28 AM, John Ky <newhoggy@gmail.com> wrote:And also stuff like this:
val x_: Int = 1
sucking in operators into the identifier stopped me trailing my variable names with underscore real quick.
Cheers,
-John
On 21 January 2011 17:53, Jim Balter <Jim@balter.nameJim@balter.name> wrote:
On Thu, Jan 20, 2011 at 10:47 PM, Jim Balter <Jim@balter.nameJim@balter.name> wrote:
Identifiers in Scala are either a sequence of operator characters or a letter followed by a sequence of letters, digits, underscores, or dollar signs.
Sorry, I misstated this. It's actually a letter followed by a sequence of letters or digits, where underscore and dollar sign are considered to be letters. The difference is that my previous formulation doesn't include identifiers starting with an underscore or dollar sign.
-- Jim
Sat, 2011-01-22, 18:17
#11
Re: >mkdir
4mkdir simply isn't a legal token ... although I believe that may be a bug. AFAICS, there is nothing in the SLS that says that it should not be the two tokens 4 and mkdir. Not that I think it should, but then the SLS should say something about digits followed immediately by identifier characters being illegal except as explicitly allowed (e.g., 4L, 4e1).
-- Jim
P.S. On "heat", I didn't see any.
On Fri, Jan 21, 2011 at 6:15 AM, Razvan Cojocaru <pub@razie.com> wrote:
-- Jim
P.S. On "heat", I didn't see any.
On Fri, Jan 21, 2011 at 6:15 AM, Razvan Cojocaru <pub@razie.com> wrote:
Now see why my impression and then surprise? In my mind at the time, there was no difference between 4mkdir and >mkdir.
Thanks,Razvan
On 2011-01-21, at 7:28 AM, John Ky <newhoggy@gmail.com> wrote:And also stuff like this:
val x_: Int = 1
sucking in operators into the identifier stopped me trailing my variable names with underscore real quick.
Cheers,
-John
On 21 January 2011 17:53, Jim Balter <Jim@balter.nameJim@balter.name> wrote:
On Thu, Jan 20, 2011 at 10:47 PM, Jim Balter <Jim@balter.nameJim@balter.name> wrote:
Identifiers in Scala are either a sequence of operator characters or a letter followed by a sequence of letters, digits, underscores, or dollar signs.
Sorry, I misstated this. It's actually a letter followed by a sequence of letters or digits, where underscore and dollar sign are considered to be letters. The difference is that my previous formulation doesn't include identifiers starting with an underscore or dollar sign.
-- Jim
Sat, 2011-01-22, 18:37
#12
Re: >mkdir
On Fri, Jan 21, 2011 at 7:30 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:
In almost all languages, >mkdir is two tokens, as it is in Scala. It would be surprising for it to be one token, and that would make things like 2>1 (or chdir>mkdir) misparse. Note that this sort of thing is determined by the lexer in virtually every language -- the parser has nothing to do with it. e.g., in the case of "Hi"length or 4toLong, the parser sees either two tokens, if the lexer separates them (as Scala and most other languages do for the former), or none at all if the lexer flags them as an error (as Scala and most other languages do for the latter).
The neat side-corner of Scala is not that it separates operator characters from identifier characters, as most languages do, but that it allows strings of operator characters to be identifiers.
Let's be careful about misrepresenting what has been written and inferring mental states and attitudes -- best to omit such comments that verge into the territory of ad hominem.
-- Jim
On Fri, Jan 21, 2011 at 9:15 AM, Razvan Cojocaru <pub@razie.com> wrote:
Yes, I can understand that surprise coming from other languages.
In almost all languages, >mkdir is two tokens, as it is in Scala. It would be surprising for it to be one token, and that would make things like 2>1 (or chdir>mkdir) misparse. Note that this sort of thing is determined by the lexer in virtually every language -- the parser has nothing to do with it. e.g., in the case of "Hi"length or 4toLong, the parser sees either two tokens, if the lexer separates them (as Scala and most other languages do for the former), or none at all if the lexer flags them as an error (as Scala and most other languages do for the latter).
It's a neat side-corner of scala.
The neat side-corner of Scala is not that it separates operator characters from identifier characters, as most languages do, but that it allows strings of operator characters to be identifiers.
I still recommend (in my personal style-guide at least) that you put separation before and after 'operator-notation' methods.
As an aside, I'm not sure why this argument became so heated but I hope it is not a trend that continues on the mailing list. Someone expressed surprise at something someone unfamiliar with Scala's formal definition would surprised about, especially coming from other languages. Let's be careful with how we word our responses.
Let's be careful about misrepresenting what has been written and inferring mental states and attitudes -- best to omit such comments that verge into the territory of ad hominem.
-- Jim
On Fri, Jan 21, 2011 at 9:15 AM, Razvan Cojocaru <pub@razie.com> wrote:
Now see why my impression and then surprise? In my mind at the time, there was no difference between 4mkdir and >mkdir.
Thanks,Razvan
On 2011-01-21, at 7:28 AM, John Ky <newhoggy@gmail.com> wrote:And also stuff like this:
val x_: Int = 1
sucking in operators into the identifier stopped me trailing my variable names with underscore real quick.
Cheers,
-John
On 21 January 2011 17:53, Jim Balter <Jim@balter.nameJim@balter.name> wrote:
On Thu, Jan 20, 2011 at 10:47 PM, Jim Balter <Jim@balter.nameJim@balter.name> wrote:
Identifiers in Scala are either a sequence of operator characters or a letter followed by a sequence of letters, digits, underscores, or dollar signs.
Sorry, I misstated this. It's actually a letter followed by a sequence of letters or digits, where underscore and dollar sign are considered to be letters. The difference is that my previous formulation doesn't include identifiers starting with an underscore or dollar sign.
-- Jim
Sat, 2011-01-22, 18:47
#13
Re: >mkdir
On Saturday January 22 2011, Jim Balter wrote:
> On Fri, Jan 21, 2011 at 7:30 AM, Josh Suereth
wrote:
> > Yes, I can understand that surprise coming from other languages.
>
> In almost all languages, >mkdir is two tokens, as it is in Scala. ...
The Lisp family of languages deserves representation here, and it would
not treat this as two tokens.
> ...
>
Sat, 2011-01-22, 19:17
#14
Re: >mkdir
yes, but people are also used to separating methods using '.' in C-style languages, hence the surprise. Not everyone thinks from a language design perspective, or makes the connection that operator-notation would parse like normal operators do in other languages. They fit into the 'method call' mental bucket for me, and hence assuming there needs to be something separating the two tokens (be it '.' or ' ').
Why must you tell me I'm wrong when I say 'this surprised me'. It's a notion of emotion on my own person.
The argument of whether or not this tokenizing/parsing is common on other languages is a different one which I was never arguing. The statement I made was whether or not an average developer would be surprised about method calls not requiring some kind of separator character, and I believe this to be true statement.
On Sat, Jan 22, 2011 at 12:32 PM, Jim Balter <Jim@balter.name> wrote:
Why must you tell me I'm wrong when I say 'this surprised me'. It's a notion of emotion on my own person.
The argument of whether or not this tokenizing/parsing is common on other languages is a different one which I was never arguing. The statement I made was whether or not an average developer would be surprised about method calls not requiring some kind of separator character, and I believe this to be true statement.
On Sat, Jan 22, 2011 at 12:32 PM, Jim Balter <Jim@balter.name> wrote:
On Fri, Jan 21, 2011 at 7:30 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:
Yes, I can understand that surprise coming from other languages.
In almost all languages, >mkdir is two tokens, as it is in Scala. It would be surprising for it to be one token, and that would make things like 2>1 (or chdir>mkdir) misparse. Note that this sort of thing is determined by the lexer in virtually every language -- the parser has nothing to do with it. e.g., in the case of "Hi"length or 4toLong, the parser sees either two tokens, if the lexer separates them (as Scala and most other languages do for the former), or none at all if the lexer flags them as an error (as Scala and most other languages do for the latter).
It's a neat side-corner of scala.
The neat side-corner of Scala is not that it separates operator characters from identifier characters, as most languages do, but that it allows strings of operator characters to be identifiers.
I still recommend (in my personal style-guide at least) that you put separation before and after 'operator-notation' methods.
As an aside, I'm not sure why this argument became so heated but I hope it is not a trend that continues on the mailing list. Someone expressed surprise at something someone unfamiliar with Scala's formal definition would surprised about, especially coming from other languages. Let's be careful with how we word our responses.
Let's be careful about misrepresenting what has been written and inferring mental states and attitudes -- best to omit such comments that verge into the territory of ad hominem.
-- Jim
On Fri, Jan 21, 2011 at 9:15 AM, Razvan Cojocaru <pub@razie.com> wrote:
Now see why my impression and then surprise? In my mind at the time, there was no difference between 4mkdir and >mkdir.
Thanks,Razvan
On 2011-01-21, at 7:28 AM, John Ky <newhoggy@gmail.com> wrote:And also stuff like this:
val x_: Int = 1
sucking in operators into the identifier stopped me trailing my variable names with underscore real quick.
Cheers,
-John
On 21 January 2011 17:53, Jim Balter <Jim@balter.nameJim@balter.name> wrote:
On Thu, Jan 20, 2011 at 10:47 PM, Jim Balter <Jim@balter.nameJim@balter.name> wrote:
Identifiers in Scala are either a sequence of operator characters or a letter followed by a sequence of letters, digits, underscores, or dollar signs.
Sorry, I misstated this. It's actually a letter followed by a sequence of letters or digits, where underscore and dollar sign are considered to be letters. The difference is that my previous formulation doesn't include identifiers starting with an underscore or dollar sign.
-- Jim
Sat, 2011-01-22, 19:37
#15
Re: >mkdir
On Sat, Jan 22, 2011 at 9:57 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:
Why must you tell me I'm wrong when I say 'this surprised me'. It's a notion of emotion on my own person.
Again, I urge you not to take this route. I told you no such thing, but there are technical points that argue that one should not be surprised that >mkdir is parsed as two tokens. Of course, one is free to be surprised about all sorts of things even though they are to be expected if one thinks about them a little bit.
-- Jim
Sat, 2011-01-22, 23:17
#16
Re: >mkdir
Well, if the idea is provide examples to the contrary, >R is one of
Forth's standard words.
On Sat, Jan 22, 2011 at 15:40, Randall R Schulz wrote:
> On Saturday January 22 2011, Jim Balter wrote:
>> On Fri, Jan 21, 2011 at 7:30 AM, Josh Suereth
> wrote:
>> > Yes, I can understand that surprise coming from other languages.
>>
>> In almost all languages, >mkdir is two tokens, as it is in Scala. ...
>
> The Lisp family of languages deserves representation here, and it would
> not treat this as two tokens.
>
>
>> ...
>>
Sat, 2011-01-22, 23:27
#17
Re: >mkdir
I agree that from a parsing/lexing perspective I think the idea that no space is required between operator tokens is valid. However, the fact that there is no space required between an identifier and a method call would be surprising if you didn't see the concrete identifier as an operator (which I'd argue is a stretch). There's also the fact that some of the things I've read on scala imply that method names can be 'anything' whereas this is not true. I believe this helps propogate the myth that spaces are needed, because of the assumption that this would be the only way to split up identifiers.
In any case, if one does not know the identifier rules from the SLS (which I'd argue is quite a few people on this list) then the argument that these things should be intuitive with a little thinking is just absurd.
On Sat, Jan 22, 2011 at 1:23 PM, Jim Balter <Jim@balter.name> wrote:
On Sat, Jan 22, 2011 at 9:57 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:Why must you tell me I'm wrong when I say 'this surprised me'. It's a notion of emotion on my own person.
Again, I urge you not to take this route. I told you no such thing, but there are technical points that argue that one should not be surprised that >mkdir is parsed as two tokens. Of course, one is free to be surprised about all sorts of things even though they are to be expected if one thinks about them a little bit.
-- Jim
Sat, 2011-01-22, 23:37
#18
Re: >mkdir
I'll go back to my original point: How is 2>1 different? In both Lisp and Forth, that's a single token; in Scala and virtually every other "syntaxy" language, it's three tokens. One can pretty much bet that >mkdir is a single token iff 2>1 is a single token. Of course, one could always invent a language just to invalidate any such general assertion, or one can simply refer to one's mental states as if they trump all reason.
-- Jim
On Sat, Jan 22, 2011 at 2:09 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
-- Jim
On Sat, Jan 22, 2011 at 2:09 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
Well, if the idea is provide examples to the contrary, >R is one of
Forth's standard words.
On Sat, Jan 22, 2011 at 15:40, Randall R Schulz <rschulz@sonic.net> wrote:
> On Saturday January 22 2011, Jim Balter wrote:
>> On Fri, Jan 21, 2011 at 7:30 AM, Josh Suereth
> <joshua.suereth@gmail.com>wrote:
>> > Yes, I can understand that surprise coming from other languages.
>>
>> In almost all languages, >mkdir is two tokens, as it is in Scala. ...
>
> The Lisp family of languages deserves representation here, and it would
> not treat this as two tokens.
>
>
>> ...
>>
>> -- Jim
>
>
> Randall Schulz
>
--
Daniel C. Sobral
I travel to the future all the time.
Sat, 2011-01-22, 23:47
#19
Re: >mkdir
On Sat, Jan 22, 2011 at 2:23 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
I agree that from a parsing/lexing perspective I think the idea that no space is required between operator tokens is valid. However, the fact that there is no space required between an identifier and a method call would be surprising if you didn't see the concrete identifier as an operator (which I'd argue is a stretch).
Well, no space is required around the '.' Obviously a space is required next to the method call in amaxb, but that's not because it's a method call. We are used to not needing spaces next to parentheses, semicolons, or other non-alphanumerics, and none of that has anything to do with method calls. I certainly believe that some people are are surprised that spaces aren't needed between alphanumerics and non-alphanumerics in this case, but I do not believe that such surprise is well-founded -- that's *my* mental state.
There's also the fact that some of the things I've read on scala imply that method names can be 'anything' whereas this is not true.
I noted quite a while ago that that *can't* be the case because, e.g., 2>1 is not a valid method name in Scala -- no one seems surprised about that when it is pointed out. Perhaps it wasn't an implication, but rather an unwarranted inference.
I believe this helps propogate the myth that spaces are needed, because of the assumption that this would be the only way to split up identifiers.
I don't think there is such a "myth", but apparently some people do suffer from this clearly mistaken assumption.
In any case, if one does not know the identifier rules from the SLS (which I'd argue is quite a few people on this list) then the argument that these things should be intuitive with a little thinking is just absurd.
What is not absurd is that it pretty much follows from the fact that 2>1 is parsed as multiple tokens that >mkdir will also be parsed as multiple tokens and that Scala is just like other "syntaxy" languages, which is most of them, in that respect; one need not consult the SLS to recognize that.
-- Jim
On Sat, Jan 22, 2011 at 1:23 PM, Jim Balter <Jim@balter.name> wrote:
On Sat, Jan 22, 2011 at 9:57 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:Why must you tell me I'm wrong when I say 'this surprised me'. It's a notion of emotion on my own person.
Again, I urge you not to take this route. I told you no such thing, but there are technical points that argue that one should not be surprised that >mkdir is parsed as two tokens. Of course, one is free to be surprised about all sorts of things even though they are to be expected if one thinks about them a little bit.
-- Jim
Sun, 2011-01-23, 00:17
#20
Re: >mkdir
Jim, I don't think you understood my previous point at all.
lexer goes: "2>1" -> number(2) symbol(>) number(1)
parser goes: lessthan( number(2) , number(1) )
lexer goes: ">mkdir" -> symbol(>) string(mkdir)
now the grammar _might_ think:
identifier(symbol+string)
or it _might_ think:
methodcall( identifier(symbol), methodname(mkstring) )
or it _might_ think:
Error: no ' ' or '.' following class identifier
if the grammar for method calls looks like
methodcall := identifier ~ separation ~ methodname
separation := whitespace | '.'
Given that it doesn't think the third of three, I don't think it's incredibly obvious that the second of three is the right way to go. In particular, you can find languages that are not dramatically less popular than Scala in which each of the three is the case.
For example, if one has noticed
val a_ = 5
List(1,3,2).sortWith(_>_)
List(1,3,2).filter(a_>_)
then I'm not sure how you ought to update your mental model of what exactly Scala is doing without spending a considerable amount of time (or having had enough experience so that in this case you can be rapidly thinking about lexing, parsing, lookahead, and so on.
Especially since situation with method calls is often taught as "you can use a space instead of a dot", not "the two identifiers need to be lexically separable".
--Rex
P.S. I really ought to argue that your disbelief that people can find this confusing is an error in your mental state. I don't know whether you have had too little experience with programming languages to see both those where >x would fail to parse and where >x would be an identifier, and to place Scala in that context, and thus see how those who were in the know could find Scala's exact behavior non-obvious (though easy to understand once one knows the correct rules); or whether (as seems somewhat more likely) you have had too much experience with certain classes of programming languages so that you have a well-formed expectation of what happens when you violate "you absolutely must use a dot to call a method", and no longer realize that the less experienced may be legitimately lost as to what is or is not allowed unless they are particularly familiar with the distinction between lexing and parsing (which many people are not).
P.P.S. Whether or not one is surprised that people don't automatically get ">mkdir" or not, the important thing is not the level of surprise that they register--unless this surprise leads them to make mistakes that results in a large amount of incorrect code--but that they figure out what is actually going on and learn to take advantage of the features of the language. So there isn't much point arguing about whether or not someone should have been surprised as long as they get over their surprise and use the language correctly. (And if you apply that one more level, it's not very useful to make meta-comments about surprise about surprise, so I should shut up now and finish fixing the hashing code.)
On Sat, Jan 22, 2011 at 5:28 PM, Jim Balter <Jim@balter.name> wrote:
lexer goes: "2>1" -> number(2) symbol(>) number(1)
parser goes: lessthan( number(2) , number(1) )
lexer goes: ">mkdir" -> symbol(>) string(mkdir)
now the grammar _might_ think:
identifier(symbol+string)
or it _might_ think:
methodcall( identifier(symbol), methodname(mkstring) )
or it _might_ think:
Error: no ' ' or '.' following class identifier
if the grammar for method calls looks like
methodcall := identifier ~ separation ~ methodname
separation := whitespace | '.'
Given that it doesn't think the third of three, I don't think it's incredibly obvious that the second of three is the right way to go. In particular, you can find languages that are not dramatically less popular than Scala in which each of the three is the case.
For example, if one has noticed
val a_ = 5
List(1,3,2).sortWith(_>_)
List(1,3,2).filter(a_>_)
then I'm not sure how you ought to update your mental model of what exactly Scala is doing without spending a considerable amount of time (or having had enough experience so that in this case you can be rapidly thinking about lexing, parsing, lookahead, and so on.
Especially since situation with method calls is often taught as "you can use a space instead of a dot", not "the two identifiers need to be lexically separable".
--Rex
P.S. I really ought to argue that your disbelief that people can find this confusing is an error in your mental state. I don't know whether you have had too little experience with programming languages to see both those where >x would fail to parse and where >x would be an identifier, and to place Scala in that context, and thus see how those who were in the know could find Scala's exact behavior non-obvious (though easy to understand once one knows the correct rules); or whether (as seems somewhat more likely) you have had too much experience with certain classes of programming languages so that you have a well-formed expectation of what happens when you violate "you absolutely must use a dot to call a method", and no longer realize that the less experienced may be legitimately lost as to what is or is not allowed unless they are particularly familiar with the distinction between lexing and parsing (which many people are not).
P.P.S. Whether or not one is surprised that people don't automatically get ">mkdir" or not, the important thing is not the level of surprise that they register--unless this surprise leads them to make mistakes that results in a large amount of incorrect code--but that they figure out what is actually going on and learn to take advantage of the features of the language. So there isn't much point arguing about whether or not someone should have been surprised as long as they get over their surprise and use the language correctly. (And if you apply that one more level, it's not very useful to make meta-comments about surprise about surprise, so I should shut up now and finish fixing the hashing code.)
On Sat, Jan 22, 2011 at 5:28 PM, Jim Balter <Jim@balter.name> wrote:
I'll go back to my original point: How is 2>1 different? In both Lisp and Forth, that's a single token; in Scala and virtually every other "syntaxy" language, it's three tokens. One can pretty much bet that >mkdir is a single token iff 2>1 is a single token. Of course, one could always invent a language just to invalidate any such general assertion, or one can simply refer to one's mental states as if they trump all reason.
-- Jim
Sun, 2011-01-23, 00:37
#21
Re: >mkdir
On Sat, Jan 22, 2011 at 3:11 PM, Rex Kerr <ichoran@gmail.com> wrote:
I understood it and, as I noted in a couple of posts, I found it almost entirely mistaken. Parsers are notoriously oblivious to white space, which is a major factor in the separation between lex and parse phases (although that separation is/can be eliminated wiith PEG parsers). e.g., whether "a"b is different from "a" b and 4toLong is different from 4 toLong is entirely up to the lexer -- most lexers pass "a"b to the parser as two tokens and treat 4toLong as an error (although a strict adherence to the grammar would make them two tokens, so a language spec like the C standard states that strings of alphanumerics always belong to a single token; the SLS neglects to make such a statement).
Again, I have no such disbelief and never made any such claim.
-- Jim
Jim, I don't think you understood my previous point at all.
I understood it and, as I noted in a couple of posts, I found it almost entirely mistaken. Parsers are notoriously oblivious to white space, which is a major factor in the separation between lex and parse phases (although that separation is/can be eliminated wiith PEG parsers). e.g., whether "a"b is different from "a" b and 4toLong is different from 4 toLong is entirely up to the lexer -- most lexers pass "a"b to the parser as two tokens and treat 4toLong as an error (although a strict adherence to the grammar would make them two tokens, so a language spec like the C standard states that strings of alphanumerics always belong to a single token; the SLS neglects to make such a statement).
P.S. I really ought to argue that your disbelief that people can find this confusing
Again, I have no such disbelief and never made any such claim.
-- Jim
Sun, 2011-01-23, 04:27
#22
Re: >mkdir
On Sat, Jan 22, 2011 at 21:11, Rex Kerr <ichoran@gmail.com> wrote:
Jim, I don't think you understood my previous point at all.
lexer goes: "2>1" -> number(2) symbol(>) number(1)
parser goes: lessthan( number(2) , number(1) )
lexer goes: ">mkdir" -> symbol(>) string(mkdir)
now the grammar _might_ think:
identifier(symbol+string)
or it _might_ think:
methodcall( identifier(symbol), methodname(mkstring) )
or it _might_ think:
Error: no ' ' or '.' following class identifier
if the grammar for method calls looks like
methodcall := identifier ~ separation ~ methodname
separation := whitespace | '.'
Given that it doesn't think the third of three, I don't think it's incredibly obvious that the second of three is the right way to go. In particular, you can find languages that are not dramatically less popular than Scala in which each of the three is the case.
I think "2>1" was a bad example. Let's use "a>b" instead. If we want "a>b" to work, then I don't see how anything but the method call might work here, unless we mandated that only methods can be symbols. Unfortunately, "identifiers" are methods too, so that wouldn't work.
There are some objects in Scala that are, in fact, symbols: ::, !, =:=, <:<, ~. Maybe others, I haven't searched too hard.
Now, I'm not saying people shouldn't be surprised, but I do think it is important that we stress to anyone falling into one of these traps that symbols can be methods, objects and classes.
For example, if one has noticed
val a_ = 5
List(1,3,2).sortWith(_>_)
List(1,3,2).filter(a_>_)
I don't think the [\w_]+_[^\s\w] rule was a good one. As it happens, I just tell people to avoid using _ as part of an identifier in Scala, at all times. It is tricky, and it makes reading code harder, because of the other underscore usages.
then I'm not sure how you ought to update your mental model of what exactly Scala is doing without spending a considerable amount of time (or having had enough experience so that in this case you can be rapidly thinking about lexing, parsing, lookahead, and so on.
Especially since situation with method calls is often taught as "you can use a space instead of a dot", not "the two identifiers need to be lexically separable".
I haven't thought about that, but now that I did, I'm happy I always call them "infix notation" and "dot notation".
--
Daniel C. Sobral
I travel to the future all the time.
Sun, 2011-01-23, 09:07
#23
Re: >mkdir
On Sat, Jan 22, 2011 at 7:17 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
I grabbed it because it's the most recognizable example, and is recognizably three tokens in languages with infix syntax (as opposed to, say, Lisp and Forth). Of course there are examples that illustrate one point or another better, such as a>mkdir or -mkdir ... but I think it's rather moot when addressing the, um, interesting analysis above that has the lexer parsing > as a symbol and mkdir as a string (?), but then has the "grammar" (parser, presumably) pasting them together again to form an identifier. What's the point of the lexer then? The analysis also has the "grammar" (again, parser presumably) deciding that something is an error because there's no white space (token?) between an identifier (no literals or other expressions allowed, apparently; maybe that's why 2>1 is a "bad" example) and a methodname (which is something other than an identifier?) ... which would require spaces where we already know they can be omitted. Of course it's *possible* to design a language with such unusual features, but we're told that there are not-much-less-popular-than-Scala languages like that. Some examples might be in order.
This seems backwards. It's because we know that a>b doesn't require spaces that only the method interpretation is viable. If only alphanumeric method names were allowed, then of course spaces would be required in, say, a max b ... but not because of the above sort of arcane grammar rule, simply because there's no way for a string of letters to be two different tokens. The arcane grammar rule would mean that (a)max(b) is not allowed -- which again is *possible* in some language, but such restrictions would be surprising and rather pointless.
a_ and _ are valid identifiers in C and Java, and _>_ and a_>_ are valid expressions in those languages, so what's the problem here? Scala assigns special *semantics* to _, but that's not about "lexing, parsing, lookahead, and so on".
Even if it is "often" taught that way, it's not a good presentation for at least the obvious reason that the paradigmatic example of 1.+(2), used in Programming in Scala to illustrate the syntax of method calls and how they can be written like infix expressions and how this *justifies* their interchangability in Scala and the ability to use operators as identifiers ... that example can be written with or without spaces on either side of the +. Even if one were to absurdly take that "teaching" literally, we would have 1 +(2), and we could drop the parens and have 1 +2. Now how is that different from, say, 1 >mkdir ?
-- Jim
On Sat, Jan 22, 2011 at 21:11, Rex Kerr <ichoran@gmail.com> wrote:Jim, I don't think you understood my previous point at all.
lexer goes: "2>1" -> number(2) symbol(>) number(1)
parser goes: lessthan( number(2) , number(1) )
lexer goes: ">mkdir" -> symbol(>) string(mkdir)
now the grammar _might_ think:
identifier(symbol+string)
or it _might_ think:
methodcall( identifier(symbol), methodname(mkstring) )
or it _might_ think:
Error: no ' ' or '.' following class identifier
if the grammar for method calls looks like
methodcall := identifier ~ separation ~ methodname
separation := whitespace | '.'
Given that it doesn't think the third of three, I don't think it's incredibly obvious that the second of three is the right way to go. In particular, you can find languages that are not dramatically less popular than Scala in which each of the three is the case.
I think "2>1" was a bad example.
I grabbed it because it's the most recognizable example, and is recognizably three tokens in languages with infix syntax (as opposed to, say, Lisp and Forth). Of course there are examples that illustrate one point or another better, such as a>mkdir or -mkdir ... but I think it's rather moot when addressing the, um, interesting analysis above that has the lexer parsing > as a symbol and mkdir as a string (?), but then has the "grammar" (parser, presumably) pasting them together again to form an identifier. What's the point of the lexer then? The analysis also has the "grammar" (again, parser presumably) deciding that something is an error because there's no white space (token?) between an identifier (no literals or other expressions allowed, apparently; maybe that's why 2>1 is a "bad" example) and a methodname (which is something other than an identifier?) ... which would require spaces where we already know they can be omitted. Of course it's *possible* to design a language with such unusual features, but we're told that there are not-much-less-popular-than-Scala languages like that. Some examples might be in order.
Let's use "a>b" instead. If we want "a>b" to work, then I don't see how anything but the method call might work here, unless we mandated that only methods can be symbols. Unfortunately, "identifiers" are methods too, so that wouldn't work.
This seems backwards. It's because we know that a>b doesn't require spaces that only the method interpretation is viable. If only alphanumeric method names were allowed, then of course spaces would be required in, say, a max b ... but not because of the above sort of arcane grammar rule, simply because there's no way for a string of letters to be two different tokens. The arcane grammar rule would mean that (a)max(b) is not allowed -- which again is *possible* in some language, but such restrictions would be surprising and rather pointless.
There are some objects in Scala that are, in fact, symbols: ::, !, =:=, <:<, ~. Maybe others, I haven't searched too hard.
Now, I'm not saying people shouldn't be surprised, but I do think it is important that we stress to anyone falling into one of these traps that symbols can be methods, objects and classes.
For example, if one has noticed
val a_ = 5
List(1,3,2).sortWith(_>_)
List(1,3,2).filter(a_>_)
I don't think the [\w_]+_[^\s\w] rule was a good one. As it happens, I just tell people to avoid using _ as part of an identifier in Scala, at all times. It is tricky, and it makes reading code harder, because of the other underscore usages.then I'm not sure how you ought to update your mental model of what exactly Scala is doing
without spending a considerable amount of time (or having had enough experience so that in this case you can be rapidly thinking about lexing, parsing, lookahead, and so on.
a_ and _ are valid identifiers in C and Java, and _>_ and a_>_ are valid expressions in those languages, so what's the problem here? Scala assigns special *semantics* to _, but that's not about "lexing, parsing, lookahead, and so on".
Especially since situation with method calls is often taught as "you can use a space instead of a dot", not "the two identifiers need to be lexically separable".
I haven't thought about that, but now that I did, I'm happy I always call them "infix notation" and "dot notation".
Even if it is "often" taught that way, it's not a good presentation for at least the obvious reason that the paradigmatic example of 1.+(2), used in Programming in Scala to illustrate the syntax of method calls and how they can be written like infix expressions and how this *justifies* their interchangability in Scala and the ability to use operators as identifiers ... that example can be written with or without spaces on either side of the +. Even if one were to absurdly take that "teaching" literally, we would have 1 +(2), and we could drop the parens and have 1 +2. Now how is that different from, say, 1 >mkdir ?
-- Jim
Sun, 2011-01-23, 09:17
#24
Re: >mkdir
On Sun, Jan 23, 2011 at 12:00 AM, Jim Balter <Jim@balter.name> wrote:
Sorry, I missed the point here, despite Daniel explicitly mentioning it, silly me. But all that is required for one's "mental model" is to be aware that, as I mentioned earlier, identifiers can be of the form letter{letter or digit}*_{opchar}*, which "a_>" is. There are plenty of other, and far more challenging, instances where one must actually *know facts* about the language they are writing in order to figure out "what exactly Scala is doing".
-- Jim
On Sat, Jan 22, 2011 at 7:17 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
On Sat, Jan 22, 2011 at 21:11, Rex Kerr <ichoran@gmail.com> wrote:For example, if one has noticed
val a_ = 5
List(1,3,2).sortWith(_>_)
List(1,3,2).filter(a_>_)
I don't think the [\w_]+_[^\s\w] rule was a good one. As it happens, I just tell people to avoid using _ as part of an identifier in Scala, at all times. It is tricky, and it makes reading code harder, because of the other underscore usages.then I'm not sure how you ought to update your mental model of what exactly Scala is doingwithout spending a considerable amount of time (or having had enough experience so that in this case you can be rapidly thinking about lexing, parsing, lookahead, and so on.
a_ and _ are valid identifiers in C and Java, and _>_ and a_>_ are valid expressions in those languages, so what's the problem here? Scala assigns special *semantics* to _, but that's not about "lexing, parsing, lookahead, and so on".
Sorry, I missed the point here, despite Daniel explicitly mentioning it, silly me. But all that is required for one's "mental model" is to be aware that, as I mentioned earlier, identifiers can be of the form letter{letter or digit}*_{opchar}*, which "a_>" is. There are plenty of other, and far more challenging, instances where one must actually *know facts* about the language they are writing in order to figure out "what exactly Scala is doing".
-- Jim
Sun, 2011-01-23, 15:07
#25
Re: >mkdir
On Sun, Jan 23, 2011 at 3:00 AM, Jim Balter <Jim@balter.name> wrote:
Indeed, and I checked the one I had in mind and found that I was mistaken.
And I'm not sure how I started using "grammar" instead of "parser". That was strange.
Anyway, let's give this a rest. I accept that using standard lexer/parser divisions, and given that > mkdir is read as >.mkdir, one should not be surprised by >mkdir. But I maintain that for anyone not familiar with standard lexer/parser divisions, there is no particularly straightforward way to deduce this.
--Rex
Of course it's *possible* to design a language with such unusual features, but we're told that there are not-much-less-popular-than-Scala languages like that. Some examples might be in order.
Indeed, and I checked the one I had in mind and found that I was mistaken.
And I'm not sure how I started using "grammar" instead of "parser". That was strange.
Anyway, let's give this a rest. I accept that using standard lexer/parser divisions, and given that > mkdir is read as >.mkdir, one should not be surprised by >mkdir. But I maintain that for anyone not familiar with standard lexer/parser divisions, there is no particularly straightforward way to deduce this.
--Rex
Sun, 2011-01-23, 18:57
#26
Re: >mkdir
On Sun, Jan 23, 2011 at 5:59 AM, Rex Kerr <ichoran@gmail.com> wrote:
Sincere thanks for checking and reporting back and acknowledging the mistake.
It's not. There are contexts in which > mkdir and >.mkdir are interchangeable (e.g., Razvan's original usage), but that's saying something quite different. I just gave the example of 1 >mkdir (e.g., given val mkdir = 0, this yields true); 1 >.mkdir is illegal syntax. And if "> mkdir" were read as ">.mkdir", I don't see that *that* would imply an equivalence to ">mkdir".
I have repeatedly noted the straightforward basis for the deduction: since 2>1 (or x>mkdir) undoubtedly is a legal expression yielding true in Scala, the language clearly makes some sort of distinction between "operator" characters like >, =, <, +, -, etc. and alphanumerics; one doesn't need to know exactly which operator characters, just that > is included, and one need not know anything about standard lexer/parser divisions, to grasp this. A good place to "drop this" would have been when I posted "How is that different from 2>1 and 2 > 1 working same?". Instead, based on *that* post, I was accused of telling people they were "wrong" to say they were surprised (and then sent threatening private email), that I have "disbelief that people can find this confusing" and a bunch of other ridiculous and ad hominem nonsense. Believe me, I have no disbelief about the degree of mistakes and confusion to which we human beings are prone; all I did was offer facts from which one might reason if one were so inclined.
-- Jim
On Sun, Jan 23, 2011 at 3:00 AM, Jim Balter <Jim@balter.name> wrote:Of course it's *possible* to design a language with such unusual features, but we're told that there are not-much-less-popular-than-Scala languages like that. Some examples might be in order.
Indeed, and I checked the one I had in mind and found that I was mistaken.
Sincere thanks for checking and reporting back and acknowledging the mistake.
And I'm not sure how I started using "grammar" instead of "parser". That was strange.
Anyway, let's give this a rest. I accept that using standard lexer/parser divisions, and given that > mkdir is read as >.mkdir, one should not be surprised by >mkdir.
It's not. There are contexts in which > mkdir and >.mkdir are interchangeable (e.g., Razvan's original usage), but that's saying something quite different. I just gave the example of 1 >mkdir (e.g., given val mkdir = 0, this yields true); 1 >.mkdir is illegal syntax. And if "> mkdir" were read as ">.mkdir", I don't see that *that* would imply an equivalence to ">mkdir".
But I maintain that for anyone not familiar with standard lexer/parser divisions, there is no particularly straightforward way to deduce this.
--Rex
I have repeatedly noted the straightforward basis for the deduction: since 2>1 (or x>mkdir) undoubtedly is a legal expression yielding true in Scala, the language clearly makes some sort of distinction between "operator" characters like >, =, <, +, -, etc. and alphanumerics; one doesn't need to know exactly which operator characters, just that > is included, and one need not know anything about standard lexer/parser divisions, to grasp this. A good place to "drop this" would have been when I posted "How is that different from 2>1 and 2 > 1 working same?". Instead, based on *that* post, I was accused of telling people they were "wrong" to say they were surprised (and then sent threatening private email), that I have "disbelief that people can find this confusing" and a bunch of other ridiculous and ad hominem nonsense. Believe me, I have no disbelief about the degree of mistakes and confusion to which we human beings are prone; all I did was offer facts from which one might reason if one were so inclined.
-- Jim
Sun, 2011-01-23, 20:07
#27
Re: >mkdir
In general, I don't think most 1-liner responses, especially in the form of concise questions, are very edifying or helpful.
One can ask "How is this different than 1<2?" which is similar to "Don't you see how the expression 1<2 implies that the language distinguishes operators from other identifiers and so no space is required to distinguish these tokens?".
One could also just state: "Look at the expression 1<2. The compiler needs to distinguish this as three separate things: '1', '<' and '2'. The example >mkdir follows the same principle, but uses the operator notation of methods."
or even:
"How is this different from 1<2. With the expression 1<2, the tokens '1', '<' and '2' are all distinguished without spaces, similarly to >mkdir."
Those answers would help provide understanding. "How is this different than 1<2?" is not a particularly helpful answer and leads to longer threads that are not particularly helpful or on-topic.
This is what I was implying. You can take the advise of including more context in responses or ignore it.
I'm not the only one to express that the signal-to-noise ratio of these mailing lists has dropped. I'm just one of the ones voicing that opinion on the mailing list.
- Josh
On Sun, Jan 23, 2011 at 12:34 PM, Jim Balter <Jim@balter.name> wrote:
One can ask "How is this different than 1<2?" which is similar to "Don't you see how the expression 1<2 implies that the language distinguishes operators from other identifiers and so no space is required to distinguish these tokens?".
One could also just state: "Look at the expression 1<2. The compiler needs to distinguish this as three separate things: '1', '<' and '2'. The example >mkdir follows the same principle, but uses the operator notation of methods."
or even:
"How is this different from 1<2. With the expression 1<2, the tokens '1', '<' and '2' are all distinguished without spaces, similarly to >mkdir."
Those answers would help provide understanding. "How is this different than 1<2?" is not a particularly helpful answer and leads to longer threads that are not particularly helpful or on-topic.
This is what I was implying. You can take the advise of including more context in responses or ignore it.
I'm not the only one to express that the signal-to-noise ratio of these mailing lists has dropped. I'm just one of the ones voicing that opinion on the mailing list.
- Josh
On Sun, Jan 23, 2011 at 12:34 PM, Jim Balter <Jim@balter.name> wrote:
On Sun, Jan 23, 2011 at 5:59 AM, Rex Kerr <ichoran@gmail.com> wrote:On Sun, Jan 23, 2011 at 3:00 AM, Jim Balter <Jim@balter.name> wrote:Of course it's *possible* to design a language with such unusual features, but we're told that there are not-much-less-popular-than-Scala languages like that. Some examples might be in order.
Indeed, and I checked the one I had in mind and found that I was mistaken.
Sincere thanks for checking and reporting back and acknowledging the mistake.
And I'm not sure how I started using "grammar" instead of "parser". That was strange.
Anyway, let's give this a rest. I accept that using standard lexer/parser divisions, and given that > mkdir is read as >.mkdir, one should not be surprised by >mkdir.
It's not. There are contexts in which > mkdir and >.mkdir are interchangeable (e.g., Razvan's original usage), but that's saying something quite different. I just gave the example of 1 >mkdir (e.g., given val mkdir = 0, this yields true); 1 >.mkdir is illegal syntax. And if "> mkdir" were read as ">.mkdir", I don't see that *that* would imply an equivalence to ">mkdir".
But I maintain that for anyone not familiar with standard lexer/parser divisions, there is no particularly straightforward way to deduce this.
--Rex
I have repeatedly noted the straightforward basis for the deduction: since 2>1 (or x>mkdir) undoubtedly is a legal expression yielding true in Scala, the language clearly makes some sort of distinction between "operator" characters like >, =, <, +, -, etc. and alphanumerics; one doesn't need to know exactly which operator characters, just that > is included, and one need not know anything about standard lexer/parser divisions, to grasp this. A good place to "drop this" would have been when I posted "How is that different from 2>1 and 2 > 1 working same?". Instead, based on *that* post, I was accused of telling people they were "wrong" to say they were surprised (and then sent threatening private email), that I have "disbelief that people can find this confusing" and a bunch of other ridiculous and ad hominem nonsense. Believe me, I have no disbelief about the degree of mistakes and confusion to which we human beings are prone; all I did was offer facts from which one might reason if one were so inclined.
-- Jim
Sun, 2011-01-23, 20:17
#28
Re: >mkdir
On Sun, Jan 23, 2011 at 10:58 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:
I think mine was edifying and helpful. In any case, your interpretation of my question as "you're wrong to say you're surprised" was certainly not helpful, and added a lot of noise to the signal, as does your continued veiled ad hominems.
-- Jim
In general, I don't think most 1-liner responses, especially in the form of concise questions, are very edifying or helpful.
I think mine was edifying and helpful. In any case, your interpretation of my question as "you're wrong to say you're surprised" was certainly not helpful, and added a lot of noise to the signal, as does your continued veiled ad hominems.
-- Jim
Sun, 2011-01-23, 20:37
#29
Re: >mkdir
P.S.
On Sun, Jan 23, 2011 at 10:58 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:
I posted a detailed technical response to Razvan, in which I noted that " val p q = System.out" produces the same error message as "val >p = System.out", and why, and in which I spelled out the syntax of identifiers, before you posted in this thread with your noisy aside about being "careful" in how we word our responses and then wrongly accused me of telling you you're wrong to be surprised. So kindly do not lecture me on providing understanding.
-- Jim
On Sun, Jan 23, 2011 at 10:58 AM, Josh Suereth <joshua.suereth@gmail.com> wrote:
Those answers would help provide understanding.
I posted a detailed technical response to Razvan, in which I noted that " val p q = System.out" produces the same error message as "val >p = System.out", and why, and in which I spelled out the syntax of identifiers, before you posted in this thread with your noisy aside about being "careful" in how we word our responses and then wrongly accused me of telling you you're wrong to be surprised. So kindly do not lecture me on providing understanding.
-- Jim
Mon, 2011-01-24, 04:47
#30
Re: >mkdir
On Sun, Jan 23, 2011 at 15:34, Jim Balter <Jim@balter.name> wrote:
Well, 1 > mkdir is 1.>(mkdir). If you put the dot where the parenthesis ought to be, it won't work, obviously. And _there_ I claim obviousness -- if you teach people that "o.m(p)" can be written as "o m p" (and vice versa), I don't see how anyone could expect "o m.p" to be equivalent to "o m p". So I guess I don't understand where do you want to go here, because I mostly agree with everything else.
--
Daniel C. Sobral
I travel to the future all the time.
It's not. There are contexts in which > mkdir and >.mkdir are interchangeable (e.g., Razvan's original usage), but that's saying something quite different. I just gave the example of 1 >mkdir (e.g., given val mkdir = 0, this yields true); 1 >.mkdir is illegal syntax. And if "> mkdir" were read as ">.mkdir", I don't see that *that* would imply an equivalence to ">mkdir".
Well, 1 > mkdir is 1.>(mkdir). If you put the dot where the parenthesis ought to be, it won't work, obviously. And _there_ I claim obviousness -- if you teach people that "o.m(p)" can be written as "o m p" (and vice versa), I don't see how anyone could expect "o m.p" to be equivalent to "o m p". So I guess I don't understand where do you want to go here, because I mostly agree with everything else.
--
Daniel C. Sobral
I travel to the future all the time.
Mon, 2011-01-24, 05:07
#31
Re: >mkdir
On Sun, Jan 23, 2011 at 7:42 PM, Daniel Sobral <dcsobral@gmail.com> wrote:
I simply responded to what someone else wrote. I don't want to go anywhere from here, as I think the subject has been beaten to death.
-- Jim
On Sun, Jan 23, 2011 at 15:34, Jim Balter <Jim@balter.name> wrote:
It's not. There are contexts in which > mkdir and >.mkdir are interchangeable (e.g., Razvan's original usage), but that's saying something quite different. I just gave the example of 1 >mkdir (e.g., given val mkdir = 0, this yields true); 1 >.mkdir is illegal syntax. And if "> mkdir" were read as ">.mkdir", I don't see that *that* would imply an equivalence to ">mkdir".
Well, 1 > mkdir is 1.>(mkdir). If you put the dot where the parenthesis ought to be, it won't work, obviously. And _there_ I claim obviousness -- if you teach people that "o.m(p)" can be written as "o m p" (and vice versa), I don't see how anyone could expect "o m.p" to be equivalent to "o m p". So I guess I don't understand where do you want to go here, because I mostly agree with everything else.
I simply responded to what someone else wrote. I don't want to go anywhere from here, as I think the subject has been beaten to death.
-- Jim
-- Jim
On Thu, Jan 20, 2011 at 2:40 PM, Razvan Cojocaru <pub@razie.com> wrote: