Clarify the syntax of Solidity is not Python inspired

[axic]

No description provided.

[axic]

Alt: "Solidity is part of the curly-bracket language family."

[chriseth]

do we need the word "syntax-wise"?

[chriseth]

Since it came up that people want to know more about which aspects of Solidity came from where, maybe we should add a section in the documentation about it?

[axic]

Since it came up that people want to know more about which aspects of Solidity came from where, maybe we should add a section in the documentation about it?

Sure, but do we have a good list of examples for each of these languages? Actually I think most of the JavaScript influence is gone, so maybe this would be a good place to explain that prior to version 0.4.0, features like scoping and the var construct were influenced by Javasrcipt.

[chriseth]

We can create a new global item "influence", listing roughly:

Solidity used to be much more influenced by JavaScript in the beginning due to function-level scoping of variables and the use of the keyword var. This influence was more and more reduced starting with version 0.4.0. Now, the main similarity to JavaScript is that functions are defined using the keyword function and Solidity looks like most of the curly-braces languages.

Other influences were Python: Solidity's modifiers were added trying to model Python's decorators with a much more restricted functionality. Furthermore, multiple inheritance and the super keyword are taken from Python as well as the general lvalue semantics of value and reference types.

[chriseth]

Oh, we could also list that payable was taken from an unnamed (?) language by Jack Pettersson and Robert Edström - https://publications.lib.chalmers.se/records/fulltext/234939/234939.pdf

[axic]

Oh, we could also list that payable was taken from an unnamed (?) language by Jack Pettersson and Robert Edström - https://publications.lib.chalmers.se/records/fulltext/234939/234939.pdf

Really? Trying to decipher when, but the only record we have is #500 (comment) (and seemingly we discussed stuff like acceptValue). The discussions started April 2016 or before.

[chriseth]

Maybe I'm mistaken, but I thought I first considered such things after a talk I saw at devcon1 or devcon2.

[mhanco]

By the way, using 'require' for preconditions appears to be from Eiffel's Design by Contract. Any references on that?

[axic]

One of the first discussions was #1130 (and apparently here Design by Contract was mentioned, but I don't recall it being discussed beyond that stray comment). There was a very long argument about ensure/expect/require/assume/assert, but it seems we mostly discussed that through calls. We knew we wanted to separate input validation (preconditions) from unexpected behaviour (postconditions/invariants), hence the two keywords. One reference I could find though: #1762 (comment)

[mhanco]

Interesting, so it may have been a decision based on thesaurus results. Love it ;)

This link has examples in Eiffel in case you're interested, https://www.eiffel.com/values/design-by-contract/introduction/

[cameel]

I just found one more thing borrowed from JavaScript: import syntax and semantics.

Solidity supports import statements to help modularise your code that are similar to those available in JavaScript (from ES6 on). However, Solidity does not support the concept of a default export.

Imports in JavaScript for comparison.

[bshastry]

Looks fine to me if the syntax-wise comment is addressed