Comments (5)
I see no problem with the first alternative. Further, I think it's important to be able to designate one or more function parameters that must be keyword-invoked. I suggest #
be used in the definition for this purpose:
the-function(a, #b, #c = nil) ->
the-function -- error, no value for #b
the-function 1, 2 -- error, #b must be assigned by name
the-function 1, #b=2 -- no problem
the-function 1, #b=2, #c=3 -- no problem
I assume a ?
suffix on function parameter types is implemented?
the-function(a Int?, #b Int?) ->
the-function -- a is nil, #b is nil
the-function 1 -- a is 1, #b is nil
the-function #b=2 -- a is nil, #b is 2
the-function 1, 2 -- error, #b must be assigned by name
from onyx-lang.
-
I totally agree on the ability to force named parameters per need - in "very high" safety situations this is a very strong guarantee.
-
Yes, the "maybe-nil-sugar" is a given.
-
Just because param
a
isInt|Nil
doesn't mean you're allowed to omit that arg. If you want it to benil
by default and thereby allow omission, you have to state itthe-function(a Int? = nil, #b Int? = nil) ->
(assuming the proposed syntax)
from onyx-lang.
- Awesome.
- Good.
- Agreed.
from onyx-lang.
After some months of using, I'm not satisfied with the named-arg syntax. The tag literal is... disturbing. Tags should stick to be values and not double as arg-identifiers - it was a bad call plain and simple!
Number (3) in the issue-OP - same as Crystal, is clearly to prefer.
The colon shaves one space (in "natural lang style syntax"), and one further by ditching the Tag-prefix, thereby also making the arg-name cleaner (primary importance). Two spaces sounds micro-optish, but given 4 args, that's 8 chars, and that's 10% of avail width if sticking to 80 col (which is good still to this day!)
The reason for trying to find an alternative is that :
is a control character - it signifies the beginning of an expression-block (python-style). The reason was however moot. Just because you can write unclear code with that doesn't mean we should make all other code unclear (with the "Tag signifies named arg"-syntax).
Example:
foo(x = 47, y = 42, color = 0xffaa00) ->
say "x = {x}, y = {y}, color = {color}"
x is 47
-- let's get warmed up
foo 100, color: 0xff0000
foo x: 1, y: 2, color: tmp = 0x00ff00 -- Set a named arg, and assign a variable
-- the following line was the culprit leading to the sorry decision:
if foo x: 47, y: 13: say "looks confusing, but of course it's parseable!"
-- and some better ways of writing it, take your pick:
if foo(x: 47, y: 13) : say "better way of putting it!"
if foo x: 47, y: 13
say "better way too"
if foo x: 47, y: 13 => say "also better choice"
if foo x: 47, y: 13 then say "actually, anything's better!"
This is already implemented as of today (breaking change).
Important Note
Space after the name:
is mandatory!
my-call name: value
If you omit the space - it's a different construct: shorthand-subscript with string as key:
name:value == name["value"]
name:value? == name["value"]?
-- also, as a kind little reminder:
name#value == name[#value]
name#value? == name[#value]?
-- and:
name.1 == name[1]
name.1? == name[1]?
A small price to pay, and a big fat deluxe shorthand notation to gain.
The name:key
syntax is up to debate too - and if changed, colon doesn't have to be mandatory - but having a space after the name:
is much better style anyway imo.
from onyx-lang.
Personally I don't see the problem with #
, but the new way looks alright.
from onyx-lang.
Related Issues (20)
- Is this still being maintained? HOT 1
- Idea: replacing `+=` etc. with the canonical "self-call-assign" HOT 4
- Feature: terse array literals HOT 1
- Taking a look at how to effectively further the project HOT 5
- Request: Tagged unions HOT 3
- GUI in ONYX ? HOT 2
- [Question] Does this language has reader macros implemented and supports template programming? HOT 2
- Ditch Global Variables from the Language (Use Type Scoped Vars for Those Cases) HOT 4
- `Self` and `this` vs Other Namings HOT 3
- Feature: spread operator HOT 4
- Dead? HOT 4
- So it's dead then? HOT 3
- `in` operator HOT 1
- Tool: Stylizer / Formatter
- Type Reasoning Keywords HOT 20
- Allow Prime (Apostrophe in Reality) Signs at End of Identifiers HOT 10
- Anon function self-reference syntax HOT 1
- "Route '66 Style"* Syntax For Code Blocks (Braces) HOT 18
- Syntax Flow, Unresolved Ideas - Suggestions Welcome HOT 2
- Write Documentation for Onyx Lang HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from onyx-lang.