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
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 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.


 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...


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:


 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.


I'd say that the keyword shows the intent more clearly than this subtly 
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
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.


 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...


 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.


 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...


 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 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
parent reply 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:


=20
 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
parent reply 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.



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
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


=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=


ote a value assignment (function signature can't use :=3D ).

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


f" uses {} then the () around the test can be omitted:

=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 reply bearophile <bearophileHUGS lycos.com> writes:
Adam Ruppe:


 bearophile wrote:

 writing "immutable" often is boring and makes code longer.


 
 im<tab>   ->  immutable


That doesn't shorten the code.



 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.


I prefer something like "val", it's shorter to write, uses less space, it's
clear enough, it's used in another language (Scala). (Is "immutable" just a
preference on your part?). I agree that "immutable" is a bit more clear, but
immutable is not a rare keyword, probably it's present every 3-10 lines of my
code, so your eye doesn't need to read "val" every time, it becomes a gestalt.
The high usage frequency of "immutable" suggests its shortening according to
Zipf law (http://en.wikipedia.org/wiki/Zipf%27s_law )...

Lot of time ago I have even suggested to replace "string" with "str" as in
Python, I find it better and good enough :-)



 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!)


In D there's no "var", so this isn't a problem for D, it's a Scala problem.



 cause length problems, your
 line is likely too long to begin with.


Very recently I have people saying me that using qualified import is bad
because it makes lines longer :-) The difference is that "immutable" => "val"
is not a semantic change, it's just a name change, while changing how default
import work changes semantic a little.
In my opinion replacing "immutable" with something shorter will encourage some
lazy typists in using that keyword more often :-)



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


I agree that special cases are not good. Go designers seem to value code
succinctness much more than you and me and Walter :-)

----------------------

Spir:


 (see also http://spir.wikidot.com/create-vs-change -- I would enjoy having
Bearophile's critics on this article ;-)


I am able to accept to tell apart update from creation, but the :: syntax
doesn't look natural enough to me, I am too much used in seeing an equal sign
somewhere there.

Bye,
bearophile
Dec 30 2010
next sibling parent reply Adam Ruppe <destructionator gmail.com> writes:
bearophile wrote:

 That doesn't shorten the code.


Completely irrelevant. We're not playing code golf. What matters
is: a) Is it easy to change? and b) Is it clear to read?

immutable is easy to change. It's just one word. immutable is clear
to read, it says what it means.


 [val is] clear enough, it's used in another language (Scala).


How many times have you had to explain to someone "val means
immutable"? It'd go back to the same situation Walter gave
when he introduced immutable: he so often had to explain
"invariant means immutable" that he just renamed it. You'd be
reintroducing that.


 (Is "immutable" just a preference on your part?).


I usually stick to the status quo; I'm pretty conservative. You've
gotta give a big, objective benefit to justify a change.

Now, sometimes I end up liking a change after its enacted. I was
against dropping parens from to!(int) for example, but now I
like it a lot. But it isn't because it saves two characters.


 The high usage frequency of "immutable" suggests its shortening
 according to Zipf law (http://en.wikipedia.org/wiki/Zipf%27s_law )


I don't see anything in that article relating to number of letters
in a word.


 Very recently I have people saying me that using qualified import
 is bad because it makes lines longer :-)


There is one difference there: a function name happens more often
than a storage class.

immutable int a; // immutable only happened once

std.string.tolower(std.string.replace("abc", "def"));
  /* happened twice, and quite a bit more than 6 letters!
       (Importantly, it is 4 additional tokens. Tokens matter
        much more in shortness than characters because tokens
        are distinctive elements, both to brains and to
        autocompleters.)
  */


However, you might notice my arguments in that thread weren't about
length either, but rather focused on ease of changes and clarity.
On those issues, we have neutral and small minus. To justify a
change like this, one or both should be a big plus.



 In my opinion replacing "immutable" with something shorter will
 encourage some lazy typists in using that keyword more often :-)


It's possible, but to justify a change based on these grounds, you'd
need more than just an opinion.

Perhaps you should make a D preprocessor to try it for a while and
see if it actually makes a difference with you and anyone who joins
your test. (Alternatively you could patch a private copy of the
compiler, but a preprocessor might be easier to write and deploy.)
Then show some results and perhaps submit the necessary patches along
with it so others can confirm and implementing it is simple.
Dec 30 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Adam Ruppe:


 The high usage frequency of "immutable" suggests its shortening
 according to Zipf law (http://en.wikipedia.org/wiki/Zipf%27s_law )


 
 I don't see anything in that article relating to number of letters
 in a word.


You are right, Zipf's law is about something related but different. I was
thinking about data compression laws then :-)

Bye,
bearophile
Dec 31 2010
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
bearophile wrote:

 Adam Ruppe:
 

 bearophile wrote:

 writing "immutable" often is boring and makes code longer.


 im<tab>   ->  immutable


 
 That doesn't shorten the code.


You did say "writing" implying the act of typing it was the problem.



 I prefer something like "val", it's shorter to write, uses less space, it's
 clear enough, it's used in another language (Scala).


It isn't clear enough, as "value" doesn't have a clear meaning when the type is 
a data structure. And remember that Scala does not have immutable types.

Immutable was picked because every other method xxx required an explanation of 
the form "xxx means it's immutable". Calling it "immutable" solved that problem.

You could as well call it "const" or "enum", too.



 Very recently I have people saying me that using qualified import is bad
 because it makes lines longer :-)


There were several other major reasons given.



 I agree that special cases are not good. Go designers seem to value code
 succinctness much more than you and me and Walter :-)


May I suggest APL for you? APL is the reigning champ of succinctness.
Dec 30 2010