digitalmars.D - Thoughts on function names containing arbitrary symbols
- Jacob Carlborg (5/5) Oct 04 2011 What are the thoughts around here on function names containing arbitrary...
- deadalnix (4/7) Oct 04 2011 That would only promote unreadable code and complexify the parsing
- Kagamin (2/6) Oct 04 2011 If D wants to be FP-style, it definitely must adopt cryptic FP naming co...
- Jacob Carlborg (7/13) Oct 04 2011 Hehe. I think it looks quite nice how it works in Scala, at least in
- Andrew Wiley (4/19) Oct 04 2011 And as a direct result, it's parsing is so slow that last time I tried
- Marco Leise (3/25) Oct 04 2011 Wait... they had to defer parsing to the file save action, because it wa...
- Jacob Carlborg (4/24) Oct 04 2011 As I said, "at least in theory".
- Walter Bright (5/8) Oct 05 2011 This, in effect, means "user defined tokens". The lexing pass will then ...
- Jacob Carlborg (16/25) Oct 05 2011 Yes, exactly. I suspected that would be the answer because of how D
- Walter Bright (2/3) Oct 05 2011 I don't know enough about Scala to answer.
- Derek (6/9) Oct 06 2011 Forth does.
- Dmitry Olshansky (4/11) Oct 06 2011 AFAIK Forth doesn't have any problems with parsing, everything is a word...
- Stewart Gordon (14/22) Nov 29 2011 Actually, it can be done while keeping the grammar context-free.
What are the thoughts around here on function names containing arbitrary
symbols, like in Scala. Example:
void ::: (int a) {}
--
/Jacob Carlborg
Oct 04 2011
deadalnix <deadalnix gmail.com>
Le 04/10/2011 11:46, Jacob Carlborg a écrit :
What are the thoughts around here on function names containing arbitrary
symbols, like in Scala. Example:
void ::: (int a) {}
That would only promote unreadable code and complexify the parsing
(actually, you see that as complexification of the parsing for both
humans and computers).
Oct 04 2011
Jacob Carlborg Wrote:
What are the thoughts around here on function names containing arbitrary
symbols, like in Scala. Example:
void ::: (int a) {}
If D wants to be FP-style, it definitely must adopt cryptic FP naming
conventions or it would be not true FP.
Oct 04 2011
On 2011-10-04 12:37, Kagamin wrote:Jacob Carlborg Wrote:Hehe. I think it looks quite nice how it works in Scala, at least in theory. But on the other hand Scala makes this really usable by having infix operators and that all operators are just methods. That's how operator overloading works in Scala. -- /Jacob CarlborgWhat are the thoughts around here on function names containing arbitrary symbols, like in Scala. Example: void ::: (int a) {}If D wants to be FP-style, it definitely must adopt cryptic FP naming conventions or it would be not true FP.
Oct 04 2011
On Tue, Oct 4, 2011 at 9:08 AM, Jacob Carlborg <doob me.com> wrote:On 2011-10-04 12:37, Kagamin wrote:And as a direct result, it's parsing is so slow that last time I tried to use the Scala IDE for Eclipse, it would lock on save as it tried to parse the source.Jacob Carlborg Wrote:Hehe. I think it looks quite nice how it works in Scala, at least in theory. But on the other hand Scala makes this really usable by having infix operators and that all operators are just methods. That's how operator overloading works in Scala.What are the thoughts around here on function names containing arbitrary symbols, like in Scala. Example: void ::: (int a) {}If D wants to be FP-style, it definitely must adopt cryptic FP naming conventions or it would be not true FP.
Oct 04 2011
Am 05.10.2011, 04:40 Uhr, schrieb Andrew Wiley <wiley.andrew.j gmail.com>:On Tue, Oct 4, 2011 at 9:08 AM, Jacob Carlborg <doob me.com> wrote:Wait... they had to defer parsing to the file save action, because it was to slow to do on the fly? (lol)On 2011-10-04 12:37, Kagamin wrote:And as a direct result, it's parsing is so slow that last time I tried to use the Scala IDE for Eclipse, it would lock on save as it tried to parse the source.Jacob Carlborg Wrote:Hehe. I think it looks quite nice how it works in Scala, at least in theory. But on the other hand Scala makes this really usable by having infix operators and that all operators are just methods. That's how operator overloading works in Scala.What are the thoughts around here on function names containing arbitrary symbols, like in Scala. Example: void ::: (int a) {}If D wants to be FP-style, it definitely must adopt cryptic FP naming conventions or it would be not true FP.
Oct 04 2011
On 2011-10-05 04:40, Andrew Wiley wrote:On Tue, Oct 4, 2011 at 9:08 AM, Jacob Carlborg<doob me.com> wrote:As I said, "at least in theory". -- /Jacob CarlborgOn 2011-10-04 12:37, Kagamin wrote:And as a direct result, it's parsing is so slow that last time I tried to use the Scala IDE for Eclipse, it would lock on save as it tried to parse the source.Jacob Carlborg Wrote:Hehe. I think it looks quite nice how it works in Scala, at least in theory. But on the other hand Scala makes this really usable by having infix operators and that all operators are just methods. That's how operator overloading works in Scala.What are the thoughts around here on function names containing arbitrary symbols, like in Scala. Example: void ::: (int a) {}If D wants to be FP-style, it definitely must adopt cryptic FP naming conventions or it would be not true FP.
Oct 04 2011
On 10/4/2011 2:46 AM, Jacob Carlborg wrote:
What are the thoughts around here on function names containing arbitrary
symbols, like in Scala. Example:
void ::: (int a) {}
This, in effect, means "user defined tokens". The lexing pass will then become
intertwined with semantic analysis. While possible, this will make the compiler
slow, buggy, impossible to run the passes concurrently, hard to write 3rd party
parsing tools, etc.
Oct 05 2011
On 2011-10-05 09:54, Walter Bright wrote:On 10/4/2011 2:46 AM, Jacob Carlborg wrote:Yes, exactly. I suspected that would be the answer because of how D works. If we instead look on Scala, where everything is a an object and every operation is a method call. 3 + 4 Is interpreted as 3.+(4) It's the same with "regular" methods instance bar 4 Is interpreted as instance.bar(4) Does Scala have the same problem? To me looks as at least lexing could be completely separated. Then it's up to the parser to figure out that "3 + 4" is syntax sugar for "3.+(4)" which is a regular method call. -- /Jacob CarlborgWhat are the thoughts around here on function names containing arbitrary symbols, like in Scala. Example: void ::: (int a) {}This, in effect, means "user defined tokens". The lexing pass will then become intertwined with semantic analysis. While possible, this will make the compiler slow, buggy, impossible to run the passes concurrently, hard to write 3rd party parsing tools, etc.
Oct 05 2011
On 10/5/2011 12:54 PM, Jacob Carlborg wrote:Does Scala have the same problem?I don't know enough about Scala to answer.
Oct 05 2011
On Thu, 06 Oct 2011 07:46:44 +1100, Walter Bright <newshound2 digitalmars.com> wrote:On 10/5/2011 12:54 PM, Jacob Carlborg wrote:Forth does. -- Derek Parnell Melbourne, AustraliaDoes Scala have the same problem?I don't know enough about Scala to answer.
Oct 06 2011
On 06.10.2011 15:28, Derek wrote:On Thu, 06 Oct 2011 07:46:44 +1100, Walter Bright <newshound2 digitalmars.com> wrote:AFAIK Forth doesn't have any problems with parsing, everything is a word. -- Dmitry OlshanskyOn 10/5/2011 12:54 PM, Jacob Carlborg wrote:Forth does.Does Scala have the same problem?I don't know enough about Scala to answer.
Oct 06 2011
On 05/10/2011 08:54, Walter Bright wrote:On 10/4/2011 2:46 AM, Jacob Carlborg wrote:Actually, it can be done while keeping the grammar context-free. One way is to allow certain non-alphanumeric characters to be used to create identifiers. There would be two sets of identifier characters - the current IdentifierStart/IdentifierChar and this new set, and each identifier would contain characters only from one of the sets, not a mixture of both. I believe Prolog does something like this. Essentially, those tokens made from these characters that are currently defined would be reserved words just like we already have in relation to alphanumeric identifiers. The disadvantage is that doing this would break existing code that juxtaposes certain symbols, such as int** qwert; --*yuiop; Stewart.What are the thoughts around here on function names containing arbitrary symbols, like in Scala. Example: void ::: (int a) {}This, in effect, means "user defined tokens". The lexing pass will then become intertwined with semantic analysis. While possible, this will make the compiler slow, buggy, impossible to run the passes concurrently, hard to write 3rd party parsing tools, etc.
Nov 29 2011