www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Something Go and Scala syntax

reply bearophile <bearophileHUGS lycos.com> writes:
Time ago with other people I have asked to replace the keyword "invariant" with
"immutable" to create a run-time constant. But that wasn't the best choice
because now in my functions I am using many immutable values; writing
"immutable" often is boring and makes code longer. This is normal D2 code:

void foo(immutable int y) {
    immutable x = 5;
    if (i > x) {
        writeln(x);
    }
    if (i > x)
        writeln(x);
}



So using "val" (abbreviation for "value") as in Scala seems better to me:

void foo(val int y) {
    val x = 5;
    if (i > x) {
        writeln(x);
    }
    if (i > x)
        writeln(x);
}


An alternative is to use Go syntax, and use the Pascal-like ":=" to denote a
value assignment (function signature can't use := ).
Here there is another idea from Go syntax: if the "then" clause of the "if"
uses {} then the () around the test can be omitted:

void foo(immutable int y) {
    x := 5;
    if i > x {
        writeln(x);
    }
    if (i > x)
        writeln(x);    
    if i > x { // {} become necessary if you remove ()
        writeln(x);
    }
}

Bye,
bearophile
Dec 30 2010
next sibling parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 30/12/10 10:55 AM, bearophile wrote:
 So using "val" (abbreviation for "value") as in Scala seems better to me:

I agree that writing immutable all the time is tedious, but val is far too vague. It does not suggest that the value is immutable at all.
 An alternative is to use Go syntax, and use the Pascal-like ":=" to denote a
value assignment (function signature can't use := ).
 Here there is another idea from Go syntax: if the "then" clause of the "if"
uses {} then the () around the test can be omitted:

Maybe I'm missing something, but what problem is this solving?
Dec 30 2010
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Peter Alexander:

 but val is far too vague. It does not suggest that the value is immutable at
all.

In Scala you tag assignments with "val" or "var". "var" means variable, and "val" means value, it's not mutable. I agree that "immutable" is a bit more explicit than "val", but I think "val" is acceptable...
 An alternative is to use Go syntax, and use the Pascal-like ":=" to denote a
value assignment (function signature can't use := ).
 Here there is another idea from Go syntax: if the "then" clause of the "if"
uses {} then the () around the test can be omitted:

Maybe I'm missing something, but what problem is this solving?

The same as "val". Instead of writing "immutable" you use ":=" (as in Go). I agree all this post is just about three bits of syntax sugar, it's not Earth shaking stuff :-) But while writing D2 code I have felt a bit of resistance in writing "immutable" all the time, and this is bad, because D has to *encourage* the programmer to use immutable values where mutables are not necessary. This is why I have suggested possible ways to shorten the syntax. Bye, bearophile
Dec 30 2010
parent reply KennyTM~ <kennytm gmail.com> writes:
On Dec 30, 10 20:23, Stanislav Blinov wrote:
 30.12.2010 15:05, bearophile пишет:
 Peter Alexander:

 but val is far too vague. It does not suggest that the value is
 immutable at all.

variable, and "val" means value, it's not mutable. I agree that "immutable" is a bit more explicit than "val", but I think "val" is acceptable...

What's wrong with "in"? It's even one character shorter.

'in' means 'const scope', not 'immutable'.
Dec 30 2010
parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
On 12/30/2010 11:10 PM, KennyTM~ wrote:
 On Dec 30, 10 20:23, Stanislav Blinov wrote:
 30.12.2010 15:05, bearophile пишет:
 Peter Alexander:

 but val is far too vague. It does not suggest that the value is
 immutable at all.

variable, and "val" means value, it's not mutable. I agree that "immutable" is a bit more explicit than "val", but I think "val" is acceptable...

What's wrong with "in"? It's even one character shorter.

'in' means 'const scope', not 'immutable'.

Oh, yeah, forgot that.
Dec 30 2010
prev sibling parent Stanislav Blinov <blinov loniir.ru> writes:
30.12.2010 15:05, bearophile :
 Peter Alexander:

 but val is far too vague. It does not suggest that the value is immutable at
all.


What's wrong with "in"? It's even one character shorter.
 An alternative is to use Go syntax, and use the Pascal-like ":=" to denote a
value assignment (function signature can't use := ).
 Here there is another idea from Go syntax: if the "then" clause of the "if"
uses {} then the () around the test can be omitted:


I agree all this post is just about three bits of syntax sugar, it's not Earth shaking stuff :-) But while writing D2 code I have felt a bit of resistance in writing "immutable" all the time, and this is bad, because D has to *encourage* the programmer to use immutable values where mutables are not necessary. This is why I have suggested possible ways to shorten the syntax.

different assignment operator. It's easier to spot and comprehend "immutable x = 5" than "x := 5". Besides, moving the role of type modifier from keyword to operator doesn't seem a very good idea, especially if the intent is only one special case. Though I agree that frequent typing of "immutable" can be tedious, I often find it kind of fun, because I simply like the word :) Then again, "immutable" in only 3 chars longer than "double" or "string".
Dec 30 2010
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2010-12-30 05:55:13 -0500, bearophile <bearophileHUGS lycos.com> said:

 void foo(immutable int y) {
     immutable x = 5;
     if (i > x) {
         writeln(x);
     }
     if (i > x)
         writeln(x);
 }

In this example, 'x' is a compile-time constant so you can use 'enum' if you want it to be shorter. :-) -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Dec 30 2010
prev sibling next sibling parent sybrandy <sybrandy gmail.com> writes:
Sigils may be another solution.  I've been a fan of them in Perl/PHP for 
various reasons and I think that they should be considered here, though 
maybe not in the same way.  Here are a couple possible examples using 
bearophile's first example:

void foo(int $y) {
     $x = 5;
     if (i > $x) {
         writeln($x);
     }
     if (i > $x)
         writeln($x);
}

In this example, the sigil is on the variable to mark that it is 
immutable.  This has the advantage of making it clear that the variable 
is immutable, however it also means that we have to apply the sigil 
everywhere the variable is used.  Also, if for some reason the variable 
should not be immutable anymore, then we have to change every instance.

void foo($int y) {
     $int x = 5;
     if (i > x) {
         writeln(x);
     }
     if (i > x)
         writeln(x);
}

Here the sigil is on the type and indicates that x and y are of the type 
"immutable int".  It's short and it's clear that the type is different 
here, however it isn't as self explanatory as using "immutable int". 
However, it is the shortest possible solution I can think of.

Casey
Dec 30 2010
prev sibling next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
bearophile wrote:
 writing "immutable" often is boring and makes code longer.

im<tab> -> immutable Really, I think you *desperately* need to get a better editor. Once you get one with a decent auto-complete, you'll never care about typing out 'boring' words again. === recommendation and sermon here === I personally use Vim for most my D work. http://vim.org The "supertab" extension script maps autocomplete from the relatively awkward control-n and control-p to the much easier to reach tab, without breaking tab in whitespace (so the One True Indentation Character still Just Works while reaping the benefits of convenient autocomplete!) It is heaven and I use it. Best of all it works in regular English just as well as *any* code. You'll ditch jQuery as a waste of time - typing document.getElementById will take less time than shifting to hit $. (d<tab>.g<tab> = win) You'll use more descriptive variable and function names. No more cryptic letters to save typing time. You can even hammer out something like 'Alexandrescu' in an email in no time flat! You don't even need to remember names. Type the first letter and ask for completion. It will automatically fill in the first possibility and give you a list of other possibilities. The first one is often the right one if it is something you use a lot (the list's ordering is based on proximity to the cursor). Once you go automatic, you'll feel naked without it, and you'll pity the fools who don't use it, worrying over such trivial issues that you've long since slain. === back to the main point === Of course, I'm sure there's dozens of editors with a similar feature. There might also be an existing option or plugin in your current editor of choice. It's worth investigating. You may also be able to set up abbreviations in your editor. Vim can be set to automatically replace "val" with "immutable", so you type the former yet see the latter. You could use a similar replace feature in your editor to custom-tailor your environment to your typing preferences. Personally though, I don't bother with that. Auto-completition renders it moot. btw you might say "an editor is no excuse for bad language design" but this isn't bad language design, it's just a preference on your part. So it should be fixed on your end. And if those 6 extra characters when reading (which are significantly easier to spot than the difference between a 'r' and a 'l' in the middle of an otherwise identical line!) cause length problems, your line is likely too long to begin with. Try using whitespace to break it up into groups or refactoring the initialization into a function.
 if the "then" clause of the "if" uses {} then the () around the
 test can be omitted:

That looks awful. It seems Go programmers don't care about tidy code. Languages should avoid such special cases.
Dec 30 2010
next sibling parent Adam Ruppe <destructionator gmail.com> writes:
spir wrote:
 Actually, do you know any editor _without_ this feature?

Notepad! I don't think elvis or gedit do either, all three of which I've used for code in the past.
 But the actual issue is not about time at all, instead plain
 human laziness

There is more to it than laziness - it is frustrating to be stuck on a stupid issue or have to do a lame activity, even if it takes very little time. When writing PHP, I find reaching for the $ every few characters to be really annoying, and that puts me in a state of mind where everything is annoying, and eventually I just want to quit. (The worst thing is every other time, I hit # instead of $. Aaargh!) I find templates in C++ to be similarly annoying. template Mtypename T> DRAT! template ,typename T> SON OF A BITCH! Then it's just visually ugly. But series of regular letters are very different than special shifted characters. There's cases where less resistant typing, less verbosity, etc. is a bonus, even independently of reducing mental load, or needless redundancy, (all benefits orthogonal to the typing issue) despite the objective time spent being very small. But shortening regular words into shorter (and made-up)words really isn't one of them, especially since it is a non-issue with so many simple and common editors.
 My guess is programmers spend ~ half of their time thinking, a
 quarter of their time controlling & another quarter fixing;
 the rest, typing.

I don't know about that! If my personal vices are any indication, it is more like half watching television, a quarter doing pointless bike-shed flamewars on usenet, a quarter discussing Star Trek on forums, and the rest doing real work :-P
Dec 30 2010
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
For what it's worth invariant still works. It's a nice keyword, but we
already use it for class invariants. I prefer immutable over "val",
it's much more explicit and noticable in code and you'll never mistake
it for anything else since it's not a made up word. Plus you don't
have to do a "translation" in your brain when you read it - "this
variable is a val, so its immutable." vs "this variable is immutable,
period."

As for typing, how is that a problem in this day and age with
autocomplete or simple macro expansion? Heck you don't even need a
capable editor, you can have keyboard automation software in the
background that expands "im" to immutable or use whatever shortcut you
want to (Autohotkey is perfectly capable of this, and I'm sure Linux
has its own solutions).
Dec 30 2010
prev sibling parent spir <denis.spir gmail.com> writes:
On Thu, 30 Dec 2010 15:15:32 +0000 (UTC)
Adam Ruppe <destructionator gmail.com> wrote:

 My guess is programmers spend ~ half of their time thinking, a
 quarter of their time controlling & another quarter fixing;
 the rest, typing. =20

I don't know about that! If my personal vices are any indication, it is more like half watching television, a quarter doing pointless bike-shed flamewars on usenet, a quarter discussing Star Trek on forums, and the rest doing real work :-P

I was decomposing the "real work" part ;-) Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Dec 30 2010
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On Thu, 30 Dec 2010 05:55:13 -0500
bearophile <bearophileHUGS lycos.com> wrote:

 An alternative is to use Go syntax, and use the Pascal-like ":=3D" to den=

 Here there is another idea from Go syntax: if the "then" clause of the "i=

=20
 void foo(immutable int y) {
     x :=3D 5;
     if i > x {
         writeln(x);
     }
     if (i > x)
         writeln(x);   =20
     if i > x { // {} become necessary if you remove ()
         writeln(x);
     }
 }

1. I dislike optional () around conditions. I find better either always omi= tted or compulsary. 2. The alternative ':=3D' operator reminds me of a related past idea. In ma= instream language, there is no difference between creating (definition) a n= ew symbol and changing it (redefinition). I personly prefere ':' and ':=3D'= or ':' and '::' (so that '=3D' means equality as expected). But '=3D' and = ':=3D' would do the job. In a local scope, value symbols could be considered immutable by default, s= o that using twice '=3D' on them would be an error. To change a symbol's va= lue, one would have to use ':=3D' instead. This is a kind of explicite forc= ed redefinition. Anyway, this is only needed for loop accumulators. (see also http://spir.wikidot.com/create-vs-change -- I would enjoy having = Bearophile's critics on this article ;-) Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Dec 30 2010
prev sibling parent spir <denis.spir gmail.com> writes:
On Thu, 30 Dec 2010 13:19:52 +0000 (UTC)
Adam Ruppe <destructionator gmail.com> wrote:


 =3D=3D=3D back to the main point =3D=3D=3D
=20
 Of course, I'm sure there's dozens of editors with a similar feature.
 There might also be an existing option or plugin in your current
 editor of choice. It's worth investigating.

Actually, do you know any editor _without_ this feature?
 btw you might say "an editor is no excuse for bad language design"
 but this isn't bad language design, it's just a preference on your
 part. So it should be fixed on your end.

But the actual issue is not about time at all, instead plain human laziness= ;-) Numerous studies have shown production programmers write about one dozen (y= es, you read well) actually useful lines of code per day. Let us triple tha= t for edition and refactoring. How much time does one need to type 3 dozen = lines of code? My guess is programmers spend ~ half of their time thinking, a quarter of t= heir time controlling & another quarter fixing; the rest, typing.
 And if those 6 extra characters when reading (which are significantly
 easier to spot than the difference between a 'r' and a 'l' in the
 middle of an otherwise identical line!) cause length problems, your
 line is likely too long to begin with. Try using whitespace to
 break it up into groups or refactoring the initialization into a
 function.

Agreed.
 if the "then" clause of the "if" uses {} then the () around the
 test can be omitted:

That looks awful. It seems Go programmers don't care about tidy code. Languages should avoid such special cases.

Ditto. Denis -- -- -- -- -- -- -- vit esse estrany =E2=98=A3 spir.wikidot.com
Dec 30 2010