www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Thoughts on function names containing arbitrary symbols

reply Jacob Carlborg <doob me.com> writes:
What are the thoughts around here on function names containing arbitrary 
symbols, like in Scala. Example:

void ::: (int a) {}

-- 
/Jacob Carlborg
Oct 04 2011
next sibling parent deadalnix <deadalnix gmail.com> writes:
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
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
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
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-10-04 12:37, Kagamin wrote:
 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.

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 Carlborg
Oct 04 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-10-05 04:40, Andrew Wiley wrote:
 On Tue, Oct 4, 2011 at 9:08 AM, Jacob Carlborg<doob me.com>  wrote:
 On 2011-10-04 12:37, Kagamin wrote:
 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.

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.

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.

As I said, "at least in theory". -- /Jacob Carlborg
Oct 04 2011
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Tue, Oct 4, 2011 at 9:08 AM, Jacob Carlborg <doob me.com> wrote:
 On 2011-10-04 12:37, Kagamin wrote:
 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.

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.

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.
Oct 04 2011
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
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:
 On 2011-10-04 12:37, Kagamin wrote:
 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.

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.

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.

Wait... they had to defer parsing to the file save action, because it was to slow to do on the fly? (lol)
Oct 04 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-10-05 09:54, Walter Bright wrote:
 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.

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 Carlborg
Oct 05 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 06.10.2011 15:28, Derek wrote:
 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:
 Does Scala have the same problem?

I don't know enough about Scala to answer.

Forth does.

-- Dmitry Olshansky
Oct 06 2011
prev sibling next sibling parent Derek <ddparnell bigpond.com> writes:
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:
 Does Scala have the same problem?

I don't know enough about Scala to answer.

Forth does. -- Derek Parnell Melbourne, Australia
Oct 06 2011
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 05/10/2011 08:54, Walter Bright wrote:
 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.

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.
Nov 29 2011