Comments (16)
What's the benefit of that syntax over regular string syntax and regular method call on that?
say "
...
".downcase
-- or any chosen delimiter with the below style
say %<
...
>.downcase
from onyx-lang.
That way simply doesn't work in Crystal:
say <<-END
...
END.downcase # doesn't end the heredoc!
You'd have to wrap the heredoc in parens.
Perhaps Onyx does not suffer from this problem?
from onyx-lang.
Come to think of it....the %< >
syntax isn't a heredoc. It's simply a multi-line string. So Onyx doesn't have heredocs?
from onyx-lang.
No exactly, that's what I meant: is it really needed provided the already available string literals?
It would be pretty simple to get going, but as always: there's got to be a reason :-)
from onyx-lang.
I think the purpose of heredocs in Ruby was to allow for unescaped brackets in the string. Suppose I need to write a string that contains all types of bracket.
from onyx-lang.
Yeah, of course, this is a must.
It might be good to try and make it go with the style of strings, just that the "delimiter" is now a string.
from onyx-lang.
As for syntax.
String-literals begin with either the common one: double quote and otherwise with "%" KIND_CHAR? DELIMITER ACTUAL_STRING MIRROR_DELIMITER
This is also a string literal, but with named delimiters. So perhaps:
"%:" DELIMITER_IDFR NEWLINE ACTUAL_STRING DELIMITER_IDFR
The key is which char to use as "code word" for named delimiter, that's it. In above example just a colon:
foo = %:DA_SHIT
stuff
and
stuff
DA_SHIT
This doesn't address the method-calling, but provided dots are forbidden as part of the named delimiter (very reasonable), it will work out of the box after the closing delimiter, because it follows Onyx simple syntax rules. It wouldn't be hard to add to the start either, even if it would be a diversion from syntactic logic. To stay with a clean, no exceptions for no good reason, kind of way, UFCS would solve it, since downcase could be prefixed as a function call then.
foo = downcase %:DA_SHIT
stuff
and
stuff
DA_SHIT
from onyx-lang.
I must admit, I do like downcase thing
. However, there are still some cases where UFCS makes no sense whatsoever:
type http-client
make-request ->
connect ->
make-request connect http-client.new -- total nonsense
Some methods, such as downcase
, operate on their argument to change it in some way, and therefore make sense grammatically as free functions: "do [this thing] on [that thing]". But other methods don't work that way. Nobody says "do connect on that http client".
downcase
is kinda like a free function anyway, conceptually. It's more a case of "downcase this string" rather than "you, string, go downcase yourself". Whereas a connect
method is a definite instruction to the object to perform some task.
Let's use an analogy. If you fire an employee, you are performing the function fire
on the employee
. "Firing" is not a task the employee performs on himself. On the other hand, if an employee is unwashed and smelly, you may instruct him to go get a shower. That is something the employee does himself.
I guess what I mean is, downcase
looks good in UFCS because it's almost a free function anyway; whilst some other methods would be ridiculous being written as such. Hence my disapproval of UFCS.
from onyx-lang.
Yes, agreed: not all methods are better of called as functions - and vice versa.
Just because you can doesn't mean you should. Now of course, this specific discussion is better of in #20.
from onyx-lang.
Any ideas for the syntax before I implement it?
foo = %:DA_SHIT
...
DA_SHIT
-- or
foo = %=DA_SHIT
...
DA_SHIT
-- or
-- ? ? ?
from onyx-lang.
foo = %=~DA_SHIT
- also viably descriptive.
Double equal signs on the line makes it look messy though.
from onyx-lang.
Since we implemented hash:key
sugar, :
carries string connotations. Makes sense to use it here.
from onyx-lang.
Yeah, I think the :
works.
In respect to hash:key
, I do of course only associate it with string-KEY, because of hash = {key: 47}
, and not strings per se, but that is a moot point in any event :-)
In this case it felt more like "string follows here, using delimiter: THIS".
I'll add it, probably tonight if I get done with "onyxify" tool. It can be changed later if something better would come up.
Hmm, also: straight-string = %s:DA_SHIT
for non interpolated.
from onyx-lang.
Doesn't Ruby use "
and '
for this?
I propose therefore:
interpolated = %:END
END
non-interpolated = %'END
END
from onyx-lang.
Added. But used the %s for consistency. a = %(foo bar)
, straight string: a = %s(foo bar)
, so same for self chosen delimiter.
foo = %: MY_DELIM
fadsf asdf
sdf sdf
MY_DELIM
As seen in this example, spaces are allowed before the delimiter in the start.
No, as for the next step. How loosely to handle the final MY_DELIM. Right now it requires newlines on both sides of finishing delim (think that's the same for Ruby etc. ?)
But this could be made much more lenient, to allow using methods immediately upon the ending-delimiter. Just need to choose a stable enough trade off between faux matches and intended end.
from onyx-lang.
Well, why make it complicated?
Now it's possible to call methods immediately on the end-delimiter.
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.