On 3/10/2012 2:21 AM, Wesley Smith wrote:
most notable thing I did recently (besides some fiddling with getting a new
JIT written), was adding a syntax for block-strings. I used<[[ ... ]]>
rather than triple-quotes (like in Python), mostly as this syntax is more
friendly to nesting, and is also fairly unlikely to appear by accident, and
couldn't come up with much "obviously better" at the moment, "<{{ ... }}>"
was another considered option (but is IIRC already used for something), as
was the option of just using triple-quote (would work, but isn't readily
nestable).
You should have a look at Lua's long string syntax if you haven't already:
[[ my
long
string]]
this was briefly considered, but would have a much higher risk of clashes.
consider someone wants to type a nested array:
[[1, 2, 3], [4, 5, 6], [7, 8, 9]]
which is not so good if this array is (randomly) parsed as a string.
preferable is to try to avoid syntax which is likely to appear by
chance, as then programmers have to use extra caution to avoid any
"magic sigils" which might have unintended behaviors, but can pop up
randomly as a result of typing code using only more basic constructions
(I try to avoid this much as I do ambiguities in general, and is partly
also why, IMO, the common "A<S, T>" syntax for templates/generics is a
bit nasty).
the syntax:
<[[ ... ]]>
was chosen as it had little chance of clashing with other valid syntax
(apart from, potentially, the CDATA end marker for XML, which at present
would need to be escaped if using this syntax for globs of XML).
it is possible, as the language does include unary "<" and ">"
operators, which could, conceivably, be applied to a nested array. this
is, however, rather unlikely, and could be fixed easily enough with a space.
as-is, they have an even-nesting rule.
WRT uneven-nesting, they can be escaped via '\' (don't really like, as
it leaves the character as magic...).
<[[
this string has an embedded \]]>...
but this is ok.
]]>
OTOH (other remote possibilities):
<{ ... }>
was already used for "insert-here" expressions in XML literals:
<foo><{generateSomeNode()}></foo>
<(...)> or <((...))> just wouldn't work (high chance of collision).
#(...), #[...], and #{...} are already in use (tuple, float vector or
matrix, and list).
example:
vector: #[0, 0, 0]
quaternion: #[0, 0, 0, 1]Q
matrix: #[[1, 0, 0] [0, 1, 0] [0, 0, 1]]
list: #{#foo, 2, 3; #v}
note: (...) parens, [...] array, {...} dictionary/object (example: "{a:
3, y: 4}").
@(...), @[...], and @{...} are still technically available.
also possible:
/[...]/ , /[[...]]/
would be "passable" mostly only as /.../ is already used for regex
syntax (inherited from JS...).
hmm:
<? ... ?>
<<? ... ?>>
(available, currently syntactically invalid).
likewise:
<\ ... \>, ...
<| ... |>
...
so, the issue is mostly lacking sufficient numbers of available (good)
brace types.
in a few other cases, this lack has been addressed via the use of
keywords and type-suffixes.
but, a keyword would be lame for a string, and a suffix wouldn't work.
You can nest by matching the number of '=' between the brackets:
[===[
a
long
string [=[ with a long string inside it ]=]
xx
]===]
this would be possible, as otherwise this syntax would not be
syntactically valid in the language.
[=[...]=]
would be at least possible.
not that I particularly like this syntax though...
(inlined):
On 3/10/2012 2:43 AM, Ondřej Bílka wrote:
On Sat, Mar 10, 2012 at 01:21:42AM -0800, Wesley Smith wrote:
You should have a look at Lua's long string syntax if you haven't
already:
Better to be consistent with rest of scripting languages(bash,ruby,perl,python)
and use heredocs.
blarg...
heredoc syntax is nasty IMO...
I deliberately didn't use heredocs.
if I did, I would probably use the syntax:
#<<END; ... END
or similar...
Python uses triple-quotes, which I had also considered (just, they
couldn't nest):
"""
lots of stuff...
over multiple lines...
"""
this would mean:
<[[
lots of stuff...
over multiple lines...
]]>
possibly also with the Python syntax:
"""
...
"""
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
