Feature request: Ruby-style heredocs about onyx-lang HOT 16 CLOSED

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.