On Fri, Feb 17, 2012 at 08:44:48AM +0100, F i L wrote:
> On Friday, 17 February 2012 at 06:25:49 UTC, H. S. Teoh wrote:
> >On Fri, Feb 17, 2012 at 06:47:20AM +0100, F i L wrote:
> >>I would use them over '||' and '&&' for the reasons bearophile
> >>gave.
> >>Highlighted as keywords, they're easily set appart, easier to
> >>type,
> >>and more distinguished... then again if I had my way I'd remove
> >>the
> >>'('/')' brackets, ending marks, and auto keyword; switched the
> >>definition name-type placement and change
> >>if/else/return/contract
> >>syntax...
> >
> >Well, if you're going to reinvent the language syntax, I'd like to replace:
> >
> >	=	with	:=
> >	==	with	=
> 
> I would agree with this, only there should be a distinction between assignment and declaration. Which in my syntax is ':'. Maybe the keyword 'is' could apply to runtime conditions.. might go nicely with the 'not' statement.

Are you referring to:

	int x = 10;

vs.

	x = 10;

?

In that case I would still prefer :=, since the first can be thought of as shorthand for "int x; x := 10".


[...]
> Agreed. Though '|' is used to accumulate bit flags, but I guess "flag1 || flag2 || etc" isn't so bad. Especially since, as you said, these situations aren't uses nearly as much as conditional OR.  Still, I think the best would be to simply use keyword and/or and leave &/| as bitwise operations.

I've always been of the opinion that common things should be shorter to type, and less common things is OK to be harder to type. So I still sorta lean towards & and | for logical and/or.


[...]
> >As for bitwise NOT, '~' is about the most counterintuitive symbol for such a thing. My presumptuous guess is that Kernighan ran out of symbols on the keyboard for operators, so he resorted to ~. The symbol '~' should've been reserved for an "approximately equal" operator, useful in comparing floating-point numbers (which as we know usually shouldn't be compared with equality due to roundoff errors), like this:
> >
> >	if (a ~ b) { ... }
> >
> >rather than today's baroque dance of:
> >
> >	if (fabs(b-a) < EPSILON) { ... }
> 
> Yep! Though, I like D's '~' as append operator for arrays. Though I i'm not sure this wouldn't work better:
> 
>     a, b: [1, 2, 3, 4, 5]
> 
>     a += b[2] // appends b[0] to a
>     a[] += b[2] // adds b[0]'s value to all of a
> 
> Seeing as how your right, '~' means "about" in math.

Well, using + for array append leads to all sorts of problems, as you can see in Javascript:

	[] + [] = ""
	[] + {} = {}
	{} + [] = NaN

OK, this craziness is also the responsibility of JS's implicit conversion rules, which D doesn't have (fortunately), but overloading + for both numerical addition and array append is not a good thing.


> >And what about:
> >
> >	.	with	: or ;
> >
> >OK. The symbol '.' is supposed to be used for the end of a sentence. At least, so we were told in grade school. In the case of programming, it should denote the end of a statement. So why is it that ';' is used to end statements, and '.' to access struct/class members? It seems so bass-ackwards. A semicolon (or a colon) is much more suitable for what amounts to a name composed of parts (module:object:property), because they signify partial stop, implying there's more to come. The period (or full-stop for you brits) '.' should be used to *end* statements, not to *continue* a multi-part name.
> 
> I don't think lines need ending marks at all.

This leads to ambiguity problems if it's unclear whether two adjacent lines are a single statement or two. It also makes the grammar much harder to implement in a parser, because it can't easily tell between the end of a statement and a wrapped line.  Having a statement separator is a good thing.


[...]
> >But who am I to speak out against more than four decades of historical accidents, right? I think I'll shut up now.
> 
> Nothing wrong with being creative ;-) Even if we know these changes will most likely never be used.

More like, they will obviously never be used. :-) We have 4 decades of historical accidents weighing against us. Still, it's nice to dream about the ideal language sometimes. :-)

Having said that though, I have to admit that I'm *still* most comfortable with C-like syntax (and by extension, current D syntax). It's not perfect, but it's nice and concise and to-the-point, and also I've grown accustomed to its quirks, so what I wrote was more a nitpick and a what-my-ideals-are rather than real complaints about the current syntax.


> I've been experimenting with LLVM to write a proof-of-concept for Tuple syntax, language State-objects, and a modularized compiler designed to be also be an IDE parser.  Just a simple test obviously, but I'm using these syntax concepts.  Thanks for the input.
[...]

Wait, you're trying to reimplement D syntax??


T

-- 
Любишь кататься - люби и саночки возить.

H. S. Teoh wrote:
> Are you referring to:
>
> 	int x = 10;
>
> vs.
>
> 	x = 10;
>
> ?
>
> In that case I would still prefer :=, since the first can be thought of
> as shorthand for "int x; x := 10".

I'm not sure what you're asking/saying here. What I mean is that there needs to be some distinction between variable declarations and variable assignment.

    Foo: class
    {
        x: int

        // lots of code

        bar: void()
        {
            x := 0 // set Foo.x or create a local 'x' variable?
        }
    }


>> I don't think lines need ending marks at all.
>
> This leads to ambiguity problems if it's unclear whether two adjacent
> lines are a single statement or two. It also makes the grammar much
> harder to implement in a parser, because it can't easily tell between
> the end of a statement and a wrapped line.  Having a statement separator
> is a good thing.

I don't think this leads to ambiguity problems, I've thought about this before and can't come up with any that aren't easily addressed. Also, I don't think is much harder to parse at all, just when the statement is determined to stop needs to be slightly more intelligent. If we can understand the code without ending-marks, a compiler should be able to understand it as well. This is something I'm experimenting with at the moment with LLVM.


> Wait, you're trying to reimplement D syntax??

Nothing so robust. Mostly I'm playing around with compiler design while refreshing my C++ abilities (which it's been awhile). My main focus is to try and build a simplistic compiler around the concept of having an AST designed to stay in memory and be dynamically submitted changes and on-demand compilation (like NRefactory, or MS Roslyn). Kinda like and interrupter only designed with the goal of 1) Non-text forms of manipulation and logic construction, and 2) modularized AST libraries as development reflection tools (think objects overview, code-completion, etc).

I'm thinking of textual syntax as more of "commands" to submit AST nodes, so there's no real "syntax" beyond what's saved in a file, which isn't really suppose to be humanly read/written though a traditional text editor. I think "standard tools" (+ modularized to used by other tools) are as important as standard libraries.

Just a hobby :)

On Friday, 17 February 2012 at 20:52:56 UTC, F i L wrote:
> H. S. Teoh wrote:
>> Are you referring to:
>>
>> 	int x = 10;
>>
>> vs.
>>
>> 	x = 10;
>>
>> ?
>>
>> In that case I would still prefer :=, since the first can be thought of
>> as shorthand for "int x; x := 10".
>
> I'm not sure what you're asking/saying here. What I mean is that there needs to be some distinction between variable declarations and variable assignment.
>
>     Foo: class
>     {
>         x: int
>
>         // lots of code
>
>         bar: void()
>         {
>             x := 0 // set Foo.x or create a local 'x' variable?
>         }
>     }
>
>
>>> I don't think lines need ending marks at all.
>>
>> This leads to ambiguity problems if it's unclear whether two adjacent
>> lines are a single statement or two. It also makes the grammar much
>> harder to implement in a parser, because it can't easily tell between
>> the end of a statement and a wrapped line.  Having a statement separator
>> is a good thing.
>
> I don't think this leads to ambiguity problems, I've thought about this before and can't come up with any that aren't easily addressed. Also, I don't think is much harder to parse at all, just when the statement is determined to stop needs to be slightly more intelligent. If we can understand the code without ending-marks, a compiler should be able to understand it as well. This is something I'm experimenting with at the moment with LLVM.
>
>
>> Wait, you're trying to reimplement D syntax??
>
> Nothing so robust. Mostly I'm playing around with compiler design while refreshing my C++ abilities (which it's been awhile). My main focus is to try and build a simplistic compiler around the concept of having an AST designed to stay in memory and be dynamically submitted changes and on-demand compilation (like NRefactory, or MS Roslyn). Kinda like and interrupter only designed with the goal of 1) Non-text forms of manipulation and logic construction, and 2) modularized AST libraries as development reflection tools (think objects overview, code-completion, etc).
>
> I'm thinking of textual syntax as more of "commands" to submit AST nodes, so there's no real "syntax" beyond what's saved in a file, which isn't really suppose to be humanly read/written though a traditional text editor. I think "standard tools" (+ modularized to used by other tools) are as important as standard libraries.
>
> Just a hobby :)

http://en.wikipedia.org/wiki/Forth_%28programming_language%29